问题描述 闲话少叙，先上代码。
public function main() { Util util = new Util(); util.print(); } public class Util { public static provider = new Provider(); public Util() { # do sth } public void print() { # print sth } } public function Provider() { public Provider() { loadData(); } private void loadData() { # load data } } 大概使用逻辑是这样，在调用入口，实例化Util对象并调用他的print方法。 这个时候，获取到了一个runtime exception：class Util not defined。
类明明就摆在那里，为什么会报异常呢？ 大家如果了解了类静态成员变量的初始化过程，就一眼看出来问题。
首先，provider是在Util类被加载的时候初始化的，要早于Util的实例化。
其次，如果provider初始化失败，会导致Util类加载失败，在实例化的时候就会抛异常。
问题的直接原因是在Provider的构造过程，由于构造函数执行了loadData的动作，这里就存在一些不确定因素，会导致错误的发生，从而影响到了Util的加载。
改进思路 精简类初始化的过程，优先保证对象能实例化成功，从而再执行数据加载的逻辑。可以利用Spring的PostConstruct注解来实现实例化和数据加载动作的分离。
In Kubernetes, you can use labels to assign key-value pairs to any resources.
Labels are ubiquitous and necessary to everyday operations such as creating services.
However, how should you name and use those labels?
Let’s start with the basics
Any resource in Kubernetes can have labels
Some labels are vital (e.g. service’s selector, operators, etc.), and others are useful to tag resources (e.g. labelling a deployment)
Kubectl offers a --show-labels flag to help you list resources and their labels
In this video I talk about a super important topic, which is security in Kubernetes and what are some of the best practices for securing your Kubernetes cluster.
The big challenge that we see in terms of Kubernetes security is that it’s already so challenging to set up a Kubernetes cluster and to configure it to deploy the applications in it, that security often becomes the afterthought, adding on top of that already complex configuration.
集群均衡器的必要性
从 kube-scheduler 的角度来看，它通过各种算法计算出最佳节点去运行 Pod 是非常完美的，当出现新的 Pod 进行调度时，调度程序会根据其当时对 Kubernetes 集群的资源描述做出最佳调度决定。但是 Kubernetes 集群是动态的，集群在一段时间内就会出现不均衡的状态，例如新节点上线与故障节点下线，或者节点维护，需要先执行节点排水，但是维护完成后，之前的 Pod 并不会自动回到该节点上来，因为 Pod 一旦被绑定了节点是不会触发重新调度的；又或者例如节点上 pod 利用率的变化导致某些节点利用率过低或者过高；节点标签变化导致 pod 的亲和策略不满足要求等等，kubernetes 集群在一段时间内就出现了不均衡的状态，所以需要均衡器来重新平衡集群。
Descheduler 组件简介
Kubernetes Descheduler 组件是一个可选的 Kubernetes 插件，用于自动化 Kubernetes 集群中节点的调度和优化。它的主要目的是解决 Kubernetes 集群中节点资源利用率不高的问题，通过在集群中调度和剔除空闲或低负载节点来优化集群的资源利用率。
具体来说，Descheduler 通过周期性检查 Kubernetes 集群中的节点负载情况，然后根据用户定义的策略来判断哪些节点需要剔除或迁移。它可以识别那些负载较低的节点，并将其与其他节点进行合并，从而使节点的资源利用率更高。
此外，Descheduler 还可以帮助用户预防节点故障。当一个节点出现问题时，Descheduler 可以自动将该节点上的 Pod 迁移到其他节点上，以确保 Kubernetes 集群的高可用性和稳定性。
Mixer是Istio另一个非常重要的组件，主要职责就是负责提供策略控制和遥测统计。
1. Mixer整体架构详解
Mixer整体架构：
在服务间进行请求转发时，Envoy对Mixer发起Check、Report这两次请求，即在转发请求前请求Mixer执行访问策略的管理配额，并在请求转发后上报要遥测数据。
为什么需要Networkpolicy
Networkpolicy可以控制进出pod的网络流量。默认情况下，每个pod都可以相互通信。当你想要阻止某些微服务相互通信时，网络策略就会派上用场，特别是当你与其他团队在共享集群中工作时。这使您的微服务在多租户环境中更具有隔离性。
关于Networkpolicy的一些基础知识，可以参照文章：Kubernetes NetworkPolicy实践指南
