云原生俱乐部-k8s知识点归纳（3）

wdxylb

于 2025-08-15 12:49:26 发布

阅读量531

点赞数 23

CC 4.0 BY-SA版权

文章标签：云原生 kubernetes 容器

这一章主要讲讲k8s中的controller控制器，原谅我没有将内容大概放在标题上，进来看的人往往不知道讲的是什么。

虽然这样子编排后面可能我也不知道该章标题对应讲的内容是什么了，但是为了标题的尽可能简短，如果在标题中加上controller控制器这几个字，那么就显得不那么美观了，太冗长了。

而且最重要的是，固定的格式就变了，所以我大概不会修改标题。

控制器被用来监控集群中的pod的状态，保证pod处于预期的状态，不同的控制器有着不同的功能与作用。

控制器本身是作为pod来管理其他pod的，前面说过pod是一组容器的逻辑抽象，所以核心区别在于控制器的pod中的容器是用来管理的，而其他pod中的容器则是运行业务的。

并且通过后面要讲的访问控制，能够授予控制器的pod管理其他pod的权限。

复制集控制器，虽然平时不会直接使用它，但是它很重要。复制集算是deployment的基础，主要确保集群中指定数量的pod始终运行，如果由pod出现故障，则会自动创建新的pod来代替。

deployment在复制集的基础上，提供了滚动更新、回退、扩缩等功能。当然，核心依然是确保有指定数量或者说是预期状态的pod运行。

deployment是定义pod的预期的状态，可以通过修改deployment来修改pod的运行状态（否则直接修改pod是无效的，包括删除）。但是可以通过kubectl set deployment/name来修改，修改的过程值得注意。

每次更改都会使用不同的replicaset复制集，复制集定义了pod的预期状态。并根据新的复制集创建pod，新 ReplicaSet 的名称包含唯一哈希（如 nginx-deployment-5d64d5d8f6），以区分不同版本。

但是需要等待新的pod创建完成后并处于ready状态，才会将原来复制集的pod进行替换（部分就绪也会开始替换，行为取决于配置），最多可用的pod是不超过预期的25%，不可用的pod不能超过25%

首先deployment会记录replicationset的历史版本（默认10个），也就是每次修改deployment实际上都会改变replicationset的版本，通过--record记录，否则不记录到历史中。

可以通过kubectl rollout history来查看历史记录，并通过kubectl rollout undo --to-revistion=来指定回滚的。

使用kubectl scale deployment/name --replicas=5可以进行扩缩。这并不会改变repilcaset复制集的版本，除非修改了镜像等内容，需要重新创建所有的pod。

这个配置集的作用是让每个节点都运行一个pod，即使是后面加入的节点，也会在该节点上创建对应的pod。

calico插件使用daemonset让每个节点都会运行一个pod（用于管理网络），并且配置pod能够容忍污点，所以master上也有。

注意：Calico 的核心组件是 calico-node和 calico-kube-controllers，calico-kube-controllers是标准的控制器（通过 Deployment 管理），calico-node是节点代理（通过 DaemonSet 确保每节点运行一个实例）

状态集除了定义pod的预期状态之外，还会让pod有规律按顺序的创建，从0-N，并且创建的pod的名称是固定的，如web-0、web-1等。

当然，删除pod的时候也是按顺序的，这样就可以满足特定的需求。更重要的是通过固定名称的pod，配合headless service，可以提供固定的DNS记录。详情请看后面介绍service。

注意：无独立 DNS 名称，除非配置Service 访问。而且service中headless service和其他类型对DNS的解析过程有点不一样。详情请看后面介绍service。

主要提一下cronJob，job管理或定义的pod会在任务完成退出后自动终止。但默认不会自动删除，而是处于completed状态（这时还可以使用kubectl logs来查看日志），但是可以指定在多少秒之后自动删除pod和job。

cronJob就是周期性的执行Job，通过和crontab一样的格式定义周期，实质其实就是通过编写crontab来周期性执行或触发Job。cronJob也默认保留，但通过配置可以保留多少个Job和pod。