myIddddd的博客

正如图所示，kubelet控制循环中有很多其他的子控制循环（图中的小圈圈）这些控制循环的责任，就是通过控制器模式，完成 kubelet 的某项具体职责。再比如 CPU Manager，就负责维护 该 Node 的 CPU 核的信息，以便在 Pod 通过 cpuset 的方式请求 CPU 核的时候，能够正 确地管理 CPU 核的使用量和可用量。所以根我们自定义控制器类似，kubelet 启动的时候，要做的第一件事情，就是设置 Listers， 也就是注册它所关心的各种事件的 Informer。

从上篇文章我们知道Service用于对所选的pod的访问和负载均衡。而今天要学习的Ingress则是作为K8S中为所有Service内置的Ingress。所以，Ingress 的功能其实很容易理解:所谓 Ingress，就是 Service 的“Service”。

首先我们来了解一下，在Kubernetes中，Service是一种抽象，用于定义一组Pod的访问方式。它可以提供负载均衡、服务发现等功能，使得应用程序可以通过一个固定的地址和端口来访问这组Pod，而不需要关心Pod的具体IP地址和端口号。Service通常用于前台服务、中台服务等场景。API Server是Kubernetes集群中的核心组件之一，它提供了Kubernetes API的访问接口。

本章节我们学习K8S中纯三层网络方案。前面章节未学习的小伙伴建议先阅读前面章节打好基础本章节我们学习Flannel 的 host-gw 模式和Calico项目。

在本篇文章中，我为你详细讲解了 Flannel UDP 和 VXLAN 模式的工作原理。

nginx-1 容器的 eth0 网卡将包发往docker0网桥上，docker0根据数据包的mac地址，在它的CAM表中查到对应的端口后把数据包发向这个端口。在默认情况下，被限制在 Network Namespace 里的容器进程，实际上是通过 Veth Pair 设备 + 宿主机网桥的方式，实现了跟同其他容器的数据交换。3，同样连接在 docker0 上的 nginx-2 容器的网络协议栈就会收到这个 ARP 请求，从而将 172.17.0.3 所对应的 MAC 地 址回复给 nginx-1 容器。

在实际应用中，除了控制循环之外的所有代码，实际上都是Kubernetes为你自动生成的，即：pkg/client/{informers, listers, clientset}里的内容。更具体地说，Informer通过一种叫作ListAndWatch的方法，把APIServer中的API对象缓存在了本地，并负责更新和维护这个缓存。所以，接下来，作为开发者，你就只需要关注如何拿到“实际状态”，然后如何拿它去跟“期望状态”做对比，从而决定接下来要做的业务逻辑即可。具体的，注册更新，删除等等业务逻辑的函数。

深入理解,deployment和stateful

DaemonSet其实是一个非常简单的控制器。在它的控制循环中，只需要遍历所有节点，然后根据节点上是否有被管理Pod的情况，来决定是否要创建或者删除一个Pod。只不过，在创建每个Pod的时候，DaemonSet会自动给这个Pod加上一个nodeAffinity，从而保证这个Pod只会在指定节点上启动。同时，它还会自动给这个Pod加上一个Toleration，从而忽略节点的unschedulable“污点”。

今天，分享了离线任务job和job 控制器以及其中一种控制器CronJob。

我们知道pod中可以定义volume用于挂载在容器中。目前，K8S有4种比较特殊的volume。1，Secret ;2 ConfigMap; 3,DownwardAPI;4, ServiceAccountToken今天我们来学习这4种特殊的挂载卷，和来看 Pod 的另一个重要的配置:容器健康检查和恢复机制两种探针。

pod的好处我们读懂，但是有什么坏处呢