Kubernetes 101,第三部分:控制器和自愈
本系列的第二部分解释了Pod的工作原理,同时构建了一个包含两个容器的 Pod,这两个容器使用 FIFO 和共享卷相互通信。
在这篇文章中,我们将了解自愈系统,以及如何利用 Pod 管理来管理Kubernetes 工作负载资源,从而让它们代表我们管理 Pod。
🚂意外总会发生
假设我们有一个运行正常的节点,并且该节点上运行着多个 Pod。如果该节点遭遇严重的硬件故障,导致其运行状态变为不健康,该怎么办?请记住:Kubernetes 节点是由虚拟机表示的。
由于Pod 具有生命周期,因此不健康节点上的 Pod将开始出现故障。
⬇️ 应用停机时间
需要一个新的节点。但是配置硬件是一项成本高昂且耗时的操作。
与此同时, Pod在不健康的节点上仍然处于故障状态,应用程序正在遭受停机。
新节点加入并准备好接受新的 Pod 后,我们可以使用新创建的健康节点手动启动所有 Podkubectl,例如:
$ kubectl apply -f ./pod.yml

在 Pod准备就绪并运行之前,应用程序将保持停止服务状态,例如:
直接管理Pod 效率不高,而且操作繁琐,更不用说我们的应用程序会面临多次停机。
我们应该构建一个能够检测故障并自动重启组件或应用程序而无需人工干预的系统。
我们需要一个自我修复系统。
🤖 自愈和机器人技术
构建自愈系统对企业至关重要。每当我们的基础设施遭受中断、网络或硬件故障时,系统都应该能够“自我修复”。
自动化是关键。而机器人技术为自我修复提供了一种潜在的解决方案。
在机器人学中,我们通常会创建一个控制器,该控制器获取一个期望状态,并通过使用某种控制回路,不断检查当前状态是否与期望状态匹配,并尽可能地接近期望状态。
恒温器的工作原理正是如此:它不断检查当前温度是否与设定温度相符,并努力使其更接近设定温度。一旦达到设定温度,控制器就会关闭设备,然后这个过程会不断重复。
幸运的是,Kubernetes 引入了控制器模式,解决了我们的问题,这样我们就无需直接管理 Pod 了。
我们正在讨论Kubernetes 控制器。
控制器
Kubernetes 控制器是控制循环,它会监视集群状态,然后采取措施尽可能地使集群达到期望状态。
但是我们该如何使用控制器呢?Kubernetes 提供了多种工作负载资源,我们可以依靠它们来代表我们管理 Pod。
是时候探索保证自我修复能力的主要工作负载资源之一——副本集了。
副本集
使用ReplicaSet控制器,我们可以指定多个相同的 Pod。
### The kind of the Kubernetes object
kind: ReplicaSet
apiVersion: apps/v1
metadata:
name: nginx
spec:
### The number of replicas of nginx Pod
### The controller will manage the Pods on our behalf
### Anytime a Pod goes down, the controller will restart a new one to guarantee that at least 2 nginx Pods are running
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
replicaset应用 YAML 文件后,我们应该得到如下的对象表示:
$ kubectl get replicasets
NAME DESIRED CURRENT READY AGE
nginx 2 2 2 13m
另外,还要检查一下 Pods:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-r5kmn 1/1 Running 0 15m
nginx-k87fz 1/1 Running 0 15m
请注意,集群中的每个 Pod 都有一个随机标识符 <podLabelMatcher>-<uniqueID>作为后缀。
此外,我们可以用图示来描述副本集:
在上图中,需要注意的是,控制器可以决定将每个 Pod 放在不同的节点中。这正是我们想要的弹性和自愈能力!
无论何时某个节点出现故障,我们仍然会保留一个健康的节点,因此我们的应用程序不会轻易出现停机。
删除副本集的 Pod
如果我们删除由 ReplicaSet 创建的 Pod,控制器将自动启动一个新的 Pod:
$ kubectl delete pod nginx-r5kmn
pod nginx-r5kmn deleted
再次检查 Pods:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-k87fz 1/1 Running 0 29m
### The new Pod
nginx-mr2rd 1/1 Running 0 28s
删除副本集
但如果要删除 ReplicaSet 中的所有 Pod,我们应该删除的replicaset是:
$ kubectl delete replicaset nginx
replicaset.apps "nginx" deleted
而那些舱体终于消失了:
$ kubectl get pods
No resources found in default namespace.
总结
在这篇文章中,我们已经了解了网络或硬件故障如何影响我们的应用程序,因此自愈系统非常重要。
除此之外,我们还了解了Kubernetes 控制器以及它们如何通过引入 Kubernetes 中最重要的工作负载资源之一:ReplicaSet来解决自愈问题。
接下来的文章仍将重点关注工作负载资源,更准确地说,是关于如何执行滚动部署、定义有状态 Pod、单节点 Pod 以及运行单个任务然后停止的 Pod(作业)。
干杯!
文章来源:https://dev.to/leandronsp/kubernetes-101-part-iii-controllers-and-self-healing-4ki5



