层次设计¶
节点¶
- Kubernetes 通过将容器放入在节点（Node）上运行的 Pod 中来执行你的工作负载。
- 节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。
- 每个节点包含运行 Pod 所需的服务； 这些节点由控制面负责管理
通常集群中会有若干个节点；而在一个学习所用或者资源受限的环境中，你的集群中也可能只有一个节点。
节点上的组件包括 kubelet、 Container Runtime以及 kube-proxy
- kubelet
- 一个cluster中每个node上都会运行这个代理
- 它保证容器运行在Pod中
- Container Runtime
- 负责运行容器的软件
- kube-proxy
- cluster中每个节点上运行的网络代理
Basic Operations
- 列出节点
kubectl get nodes
- 隔离节点（将其标记为不可调度）
kubectl cordon <node-name>
- 排空节点（安全地逐出所有 pod）
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
- 解除隔离节点（将其标记为可调度）
kubectl uncordon <node-name>
查看节点信息：kubectl describe node
控制器¶
在 Kubernetes 中，控制器通过监控集群 的公共状态，并致力于将当前状态转变为期望的状态
控制器模式¶
一个控制器 至少追踪一种类型的 Kubernetes 资源。这些 对象 有一个代表期望状态的 spec 字段。 该资源的控制器负责确保其当前状态接近期望状态。
通过 API 服务器来控制
Job 控制器是一个 Kubernetes 内置控制器的例子。 内置控制器通过和集群 API 服务器交互来管理状态。
Job 是一种 Kubernetes 资源，它运行一个或者多个 Pod， 来执行一个任务然后停止。 （一旦被调度了，对 kubelet 来说 Pod 对象就会变成期望状态的一部分）。
- 在集群中，当 Job 控制器拿到新任务时，它会保证一组 Node 节点上的
kubelet可以运行正确数量的 Pod 来完成工作。 - Job 控制器不会自己运行任何的 Pod 或者容器。Job 控制器是 通知 API 服务器 来创建或者移除 Pod。
- 控制面中的其它组件 根据新的消息作出反应（调度并运行新 Pod）并且最终完成工作。
创建新 Job 后，所期望的状态就是完成这个 Job。Job 控制器会让 Job 的当前状态不断接近期望状态：创建为 Job 要完成工作所需要的 Pod，使 Job 的状态接近完成。
控制器也会更新配置对象。例如：一旦 Job 的工作完成了，Job 控制器会更新 Job 对象的状态为 Finished（这有点像温度自动调节器关闭了一个灯，以此来告诉你房间的温度现在到你设定的值了）。
名词解释：
- Job：需要完成的确定的/批量的工作
- 调度（scheduling）指的是确保 Pod 匹配到合适的节点， 以便 kubelet 能够运行它们。
- 抢占（Preemption）指的是终止低优先级的 Pod 以便高优先级的 Pod 可以调度运行的过程。
- 驱逐（Eviction）是在资源匮乏的节点上，主动让一个或多个 Pod 失效的过程。
直接控制
相比 Job 控制器，有些控制器需要对集群外的一些东西进行修改。
例如，如果你使用一个控制回路来保证集群中有足够的 节点，那么控制器就需要 当前集群外的一些服务 在需要时创建新节点。
Point:
- 和外部状态交互的控制器从 API 服务器获取到它想要的状态，然后 直接和外部系统进行通信 并使当前状态更接近期望状态
- 其他控制回路 可以 观测到所汇报的数据的这种变化 并 采取其各自的行动
期望状态与当前状态¶
Kubernetes 采用了系统的云原生视图，并且可以处理持续的变化。
在任务执行时，集群随时都可能被修改，并且控制回路会自动修复故障。 这意味着很可能集群永远不会达到稳定状态。
只要集群中的控制器在运行并且进行有效的修改，整体状态的稳定与否是无关紧要的。
设计 && 运行方式¶
作为设计原则之一，Kubernetes 使 用了很多控制器，每个控制器管理集群状态的一个特定方面 。
最常见的：一个特定的控制器使用一种类型的资源作为它的期望状态， 控制器管理控制另外一种类型的资源向它的期望状态演化。
例如，Job 的控制器跟踪 Job 对象（以发现新的任务）和 Pod 对象（以运行 Job，然后查看任务何时完成）。 在这种情况下，新任务会创建 Job，而 Job 控制器会创建 Pod
可以有多个控制器来创建或者更新相同类型的对象。 在后台，Kubernetes 控制器确保它们只关心与其控制资源相关联的资源。（可以通过标签等区分标志进行同名资源的区别）
例如，你可以创建 Deployment 和 Job；它们都可以创建 Pod。 Job 控制器不会删除 Deployment 所创建的 Pod，因为有信息 （标签）让控制器可以区分这些 Pod。
PS：
Kubernetes 内置一组控制器，运行在 kube-controller-manager 内。
Deployment 控制器和 Job 控制器是 Kubernetes 内置控制器的典型例子。
Kubernetes 允许你运行一个稳定的控制平面，这样即使某些内置控制器失败了， 控制平面的其他部分会接替它们的工作
容器运行时接口 (CRI)¶
Container Runtime 与 Kubelet 之间的API接口
CRI 是一个插件接口，它 使 kubelet 能够使用各种容器运行时 (Container Runtime)，无需重新编译集群组件。
你需要在集群中的每个节点上都有一个可以正常工作的容器运行时， 这样 kubelet 能启动 Pod 及其容器。
容器运行时接口（CRI）是 kubelet 和容器运行时之间通信的主要协议。
Kubernetes 容器运行时接口（Container Runtime Interface；CRI）定义了主要 gRPC 协议， 用于节点组件 kubelet 和容器运行时之间的通信