Kubernetes的资源控制器和Service(四)
正文
一、定义和分类
1，定义
k8s 中内建了很多控制器（controller ），这些相当于一个状态机，用来控制 Pod 的具体状态和行为。
2，类型
ReplicationController、ReplicaSet、DaemonSet、StatefulSet、Job/CronJob和Horizontal Pod Autoscaling
二、资源控制器的定义和示例
1，ReplicationController 和 ReplicaSet
ReplicationController（RC）用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代，而如果异常多出来的容器也会被自动回收。
在新版本的k8s中建议使用ReplicaSet(RS)来取代RC，RS与RC没有本质的不同，只是名字不一样，并且RS支持集合式的selector，即通过标签(labels)来管理多个Pod。
RS示例：(rs.yaml)
apiVersion: extensions/v1beta1 kind: ReplicaSet #类型为RS metadata: name: rs-1 #RS的名称 spec: replicas: 3 #Pod的副本数 selector: #选择器 matchLabels: tier: frontend #需要匹配的Pod标签 template: #定义Pod metadata: labels: tier: frontend #当前Pod的标签 spec: containers: - name: nginx-container image: hub.xcc.com/my/mynginx:v1 ports: - containerPort: 80
执行如下命令:
kubectl create -f rs.yaml #获取rs kubectl get rs #列出指定标签 kubectl get pod --show-labels -l tier=frontend #修改标签为frontend1 kubectl label pod rs-1-abc tier=frontend1 --overwrite=true #查看pod kubectl get pod --show-labels #删除控制器rs-1 kubectl delete rs rs-1 kubectl get pod --show-labels
2，Deployment
Deployment为Pod和RS提供了一个声明式定义方法，用来替换以前的RC来方便的管理应用。
Deployment示例:(deployment.yaml)
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: deployment-1 #名称 spec: replicas: 3 #Pod副本 template: metadata: labels: app: nginx-app #Pod标签 spec: containers: - name: nginx-container image: hub.xcc.com/my/mynginx:v1 ports: - containerPort: 80
创建查看命令
#创建并保存记录 kubectl apply -f demployment.yaml --record #查看Deployment kubectl get deployment #查看rs kubectl get rs #查看Pod 显示标签 kubectl get pod --show-labels
扩容
# 将Pod的期望副本数扩容到5个 kubectl scale deployment deployment-1 --replicas 5 kubectl get pod --show-labels
滚动更新
[root@master01 ~]# kubectl set image deployment/deployment-1 nginx-container=hub.xcc.com/library/mynginx:v2 deployment.extensions/deployment-1 image updated # 查看 deployment，发现没什么变化 [root@master01 ~]# kubectl get deployment NAME READY UP-TO-DATE AVAILABLE AGE deployment-1 5/5 5 5 24m # 查看 rs，出现了一个新的rs，pod数量维持在5个，并且原先的rs的pod数量变为0了 # deployment-1-6fd64dcb5 就是deployment升级后新创建的rs，并且Pod里的容器使用的是新的镜像 [root@master01 ~]# kubectl get rs NAME DESIRED CURRENT READY AGE deployment-1-6fd64dcb5 5 5 5 22s deployment-1-7796b9c74d 0 0 0 22m
#查看更新状态 [root@master01 ~]# kubectl rollout status deployment/deployment-1 deployment "deployment-1" successfully rolled out
#查看升级记录 [root@k8s-master01 ~]# kubectl rollout history deployment/deployment-1 deployment.extensions/deployment-1 REVISION CHANGE-CAUSE 1 kubectl apply --filename=demployment.yaml --record=true 2 kubectl apply --filename=demployment.yaml --record=true
#查看单个revision 的详细信息 kubectl rollout history deployment/deployment-1 --revision=2
清理 Policy
设置 Deployment 中的 .spec.revisionHistoryLimit 项来指定保留多少旧的 ReplicaSet。 余下的将在后台被当作垃圾收集。默认的，所有的 revision 历史就都会被保留。
注意： 将该值设置为0，将导致所有的 Deployment 历史记录都会被清除，该 Deployment 就无法再回退了。
回滚更新
#回退到上一个版本 kubectl rollout undo deployment/deployment-1 #回退到指定版本 首先查看版本记录 kubectl rollout history deployment/deployment-1 #再回退到指定版本为2 kubectl rollout undo deployment/deployment-1 --to-revision=2
更新策略
Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的，它会确保至少有比期望的Pod数量少一个是up状态（最多一个不可用）。
Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的，它会确保最多比期望的Pod数量多一个的 Pod 是 up 的（最多1个 surge ）。
在未来的 Kuberentes 版本中，将从1-1变成25%-25%。
Rollover（多个rollout并行）
假如您创建了一个有5个 niginx:1.7.9 replica 的 Deployment，但是当还只有3个 nginx:1.7.9 的 replica 创建出来的时候您就开始更新含有5个 nginx:1.9.1 replica 的 Deployment。在这种情况下，Deployment 会立即杀掉已创建的3个 nginx:1.7.9 的 Pod，并开始创建 nginx:1.9.1 的 Pod。它不会等到所有的5个 nginx:1.7.9 的 Pod 都创建完成后才开始改变航道。
3，DaemonSet
DaemonSet确保全部（或者一些）node 上运行一个 Pod 的副本。当有新的 node 加入集群时，会自动为他们添加一个这样的 Pod。当有集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它所创建的所有 Pod。
使用场景
- 运行集群存储 daemon，例如在每个 node 上运行 glusterd、ceph。
- 在每个 node 上运行日期收集 daemon，例如 fluentd、logstash。
- 在每个 node 上运行监控 daemon，例如 Prometheus node Exporter、collectd、Datadog 代理或New Relic 代理。
DaemonSet 示例：(daemonset.yaml)
apiVersion: extensions/v1beta1 kind: DaemonSet metadata: name: daemonset-1 #名称 labels: app: daemonset-app #daemonSet标签 spec: selector: matchLabels: name: daemonset-label #选择指定的Pod template: metadata: labels: name: daemonset-label #定义Pod的标签 spec: containers: - name: nginx-container image: hub.xcc.com/my/mynginx:v1 ports: - containerPort: 80
执行命令
kubectl create -f daemonset.yaml #查看daemonSet kubectl get ds #查看Pod标签 kubectl get pod --show-labels #查看Pod运行的节点 kubectl get pod -o wide
DaemonSet 确保了集群中每一个节点都会运行一个 Pod（master 节点没有运行是因为污点的设置）。就算我们删除某个节点的 Pod，DaemonSet 也会马上为这个节点重新创建一个 Pod。当然此时如果有新的节点加入到集群中，那么 DaemonSet 也会为这个新节点自动创建一个这样的 Pod。
4，Job
Job 负责批处理任务，即仅执行一次的任务，它能够确保批处理任务的一个或多个 Pod 运行成功。意思就是，运行一个 Job 来创建 Pod，让里面的容器成功运行了指定的次数，才认为这个 Job 是成功的，那么这个 Job 才算执行完成。
特殊说明
- spec.template 格式同 Pod
- restartPolicy 策略仅支持 Never 或 OnFailure。
- 单个 Pod 时，默认 Pod 成功运行后 Job 即结束。
- .spec.completions 标志 Job 结束需要成功运行的 Pod 个数，默认为 1。
- .spec.parallelism 标志并行运行的 Pod 个数，默认为 1。
- spec.activeDeadlineSeconds 标志失败的重试最大时间，超过这个时间不会继续重试。
Job示例:(job.yaml)
apiVersion: batch/v1 kind: Job metadata: name: job-1 #job名称 spec: template: metadata: name: job-app spec: containers: - name: busybox-container image: hub.xcc.com/my/mybusybox:v1 command: ['sh', '-c', 'echo hello world'] restartPolicy: Never
执行命令
kubectl create -f job.yaml kubectl get job kubectl get pod #查看日志 kubectl log job-1-abcd1
5，CronJob
CronJob 管理基于时间的 Job，即：
- 在给定的时间点运行一次
- 周期性的在给定时间点运行
- 其本质就是在特定的时间循环创建 Job 来执行任务
- 其表达式为：分、时、日、月、周
常用场景：
- 在给定的时间点调度 Job 运行
- 创建周期性的运行的 Job，例如：数据库备份，发送邮件。
CronJob 的示例：(cronjob.yaml)
apiVersion: batch/v1beta1 kind: CronJob metadata: name: cronjob-1 spec: schedule: "*/1 * * * *" #spec.schedule：调度，必须字段，指定任务运行周期，格式为分、时、日、月、周。 jobTemplate: #spec.jobTemplate：Job 模板，必须字段，指定需要运行的任务，格式同 Job。 spec: template: metadata: name: cronjob-app spec: containers: - name: busybox-container image: hub.xcc.com/my-xcc/my-busybox:v1 command: ['sh', '-c', 'date && echo hello world'] restartPolicy: Never #spec.startingDeadlineSeconds：启动 Job 的期限（秒级别），该字段是可选的，如果因为任何原因而错过了被调度的时间，那么错过指定时间的 Job 将被认为的失败的。默认无期限。
执行命令
kubectl apply -f cronjob.yaml kubectl get cj #查看job，每分钟执行一个job kubectl get job kubectl get pod #查看pod日志 kubectl log cronjob-1-15123460-acdf6
6，StatefulSet
StatefulSet 为 Pod 提供唯一的标识，它可以保证部署和 scale 的顺序。StatefulSet 是为了解决有状态服努的问题，对应 Deployment 和 ReplicaSet 是为无状态服务而设计。
StatefulSet 有以下特点：
- 稳定的持久化存储，即 Pod 重新调度后还是能访问到相同的持久化数据，基于PVC来实现。
- 稳定的网络标志，即 Pod 重新调度后，其 PodName 和 HostName 不变，基于 Headless Service（即没有Cluster IP的 Service）来实现。
- 有序部署，有序扩展。即 Pod 是有顺序的，在部署或扩展的时候要依据定义的顺序依次进行（即从 0 到 N-1，在下一个 Pod 运行之前，之前所有的 Pod 必须都是 Running 和 Ready 状态），基于 init containers 来实现。
- 有序收缩，有序删除（即从 N- 1 到 0）。
7，HPA(Horizontal Pod Autoscaling)
应用的资源使用率通常都有高峰和低谷的时候，如何削峰埋谷，提高集群的整体资源利用率，让 service 中的 Pod 个数自动调整昵？这就有赖于 Horizontal Pod Autoscaling 了，顾名思义，使 Pod 水平自动缩放。
三、Service
1，定义
k8s 定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。 这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector 实现的。Service是k8s中的一个重要概念，主要是提供负载均衡和服务自动发现。
2，Service的类型
-
ClusterIp：默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟 IP。普通Service：通过为Kubernetes的Service分配一个集群内部可访问的
固定虚拟IP（Cluster IP）；Headless Service：DNS会将headless service的后端直接解析为podIP列表。 -
NodePort：在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过 : NodePort 来访问该服务。
-
LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到: NodePort 。
- ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 kubernetes 1.7 或更高版本的 kube-dns 才支持
3，Service的创建
一个 Service 在 k8s 中是一个 Rest 对象，和 Pod 类似。 像所有的 Rest 对象一样， Service 定义可以基于 POST 方式，请求 apiserver 创建新的实例。 例如，假定有一组 Pod，它们对外暴露了 9376 端口，同时还被打上 "app=MyApp" 标签。
apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376 #将请求代理到使用 TCP 端口 9376，并且具有标签 "app=MyApp" 的 Pod 上
a)ClusterIP类型
clusterIP 主要在每个 node 节点使用 iptables 或 ipvs，将发向 clusterIP 对应端口的数据，转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 service 下对应 pod 的地址和端口，进而把数据转发给对应的 pod 的地址和端口。
主要需要以下几个组件的协同工作：
- apiserver：用户通过 kubectl 命令向 apiserver 发送创建 service 的命令，apiserver 接收到请求后将数据存储 到 etcd 中。
- kube-proxy：k8s 的每个节点中都有一个叫做 kube-porxy 的进程，这个进程负责感知 service，pod 的变化，并将变化的信息写入本地的 iptables 或 ipvs 规则中。
- iptables 或 ipvs：使用 NAT 等技术将 virtual IP 的流量转至 endpoints 中。
创建Deployment（cluster-deployment.yaml）
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment namespace: default spec: replicas: 3 selector: matchLabels: app: nginx-app template: metadata: labels: app: nginx-app spec: containers: - name: nginx-container image: hub.xcc.com/my-xcc/my-nginx:v1 imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80
创建一个 Service（cluster-svc.yaml）
apiVersion: v1 kind: Service metadata: name: cluster-svc namespace: default spec: type: ClusterIP selector: app: nginx-app ports: - name: http port: 80 targetPort: 80
执行命令
#先创建deployment kubectl apply -f cluster-deployment.yaml kubectl get deployment #查看pod及其对应的ip kubectl get pod -o wide #创建svc kubectl apply -f cluster-svc.yaml kubectl get svc # 查看 ipvs规则。可以看见 svc 所在的 ip 地址代理的是上面的三个 pod 的 ip ipvsadm -Ln
b)NodePort类型
如果设置 type 的值为 "NodePort"，Kubernetes master 将从给定的配置范围内（默认：30000-32767）分配端口，每个 Node 将从该端口（每个 Node 上的同一端口）代理到 Service。该端口将通过 Service 的 spec.ports[*].nodePort 字段被指定。
创建NodePort资源(nodeport-svc.yaml)
apiVersion: v1 kind: Service metadata: name: nodeport-svc namespace: default spec: type: NodePort selector: app: nginx-app ports: - name: http port: 80 targetPort: 80 # 绑定到宿主机的31234端口，如果不指定，将随机分配30000-32767 nodePort: 31234
执行命令
kubectl apply -f nodeport-svc.yaml kubectl get svc # 查看 ipvs 规则 ipvsadm -Ln
c)LoadBalancer 类型
使用支持外部负载均衡器的云提供商的服务，设置 type 的值为 "LoadBalancer"，将为 Service 提供负载均衡器。 负载均衡器是异步创建的，关于被提供的负载均衡器的信息将会通过 Service 的 status.loadBalancer 字段被发布出去。
示例：(loadbalancer-svc.yaml)
kind: Service apiVersion: v1 metadata: name: loadbalancer-svc spec: selector: app: nginx-App ports: - protocol: TCP port: 80 targetPort: 9376 nodePort: 30061 clusterIP: 10.0.124.225 loadBalancerIP: 79.41.36.129 type: LoadBalancer status: loadBalancer: ingress: - ip: 124.145.67.177
来自外部负载均衡器的流量将直接打到 backend Pod 上，不过实际它们是如何工作的，这要依赖于云提供商。 在这些情况下，将根据用户设置的 loadBalancerIP 来创建负载均衡器。 某些云提供商允许设置 loadBalancerIP。如果没有设置 loadBalancerIP，将会给负载均衡器指派一个临时 IP。 如果设置了 loadBalancerIP，但云提供商并不支持这种特性，那么设置的 loadBalancerIP 值将会被忽略掉。
d)ExternalName 类型
这种类型的 Service 通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容，例如 www.xcc.com。ExternalName Service 是 Service 的特例，它没有 selector，也没有定义任何的端口和Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务。
示例：(externelname-svc.yaml)
apiVersion: v1 kind: Service metadata: name: externalname-svc namespace: default spec: type: ExternalName externalName: www.xcc.com
当查询主机 externalname-svc.defalut.svc.cluster.local（svc-name.namespace.svc.cluster.local）时，集群的 DNS 服务将返回一个值 www.xcc.com 的 CNAME 记录。访问这个服务的工作方式和其他的相 同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发。
执行命令
[root@master01 ~]# kubectl apply -f externelname-svc.yaml service/externalname-svc created [root@master01 ~]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE externalname-svc ExternalName <none> www.xixihaha.com <none> 4s kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 10d [root@master01 ~]# dig -t A externalname-svc.default.svc.cluster.local. @10.244.0.7 ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> -t A externalname-svc.default.svc.cluster.local. @10.244.0.7 ...... ;; ANSWER SECTION: externalname-svc.default.svc.cluster.local. 30 IN CNAME www.xcc.com. ......
e)Headless Service
一种特殊的 ClusterIP SVC 类型。有时不需要或不想要负载均衡，以及单独的 Service IP。 遇到这种情况，可以通过指定 Cluster IP 的值为 "None" 来创建 Headless Service（spec.clusterIP: "None"）。这个选项允许开发人员自由寻找他们自己的方式，从而降低与 Kubernetes 系统的耦合性。 应用仍然可以使用一种自注册的模式和适配器，对其它需要发现机制的系统能够很容易地基于这个 API 来构建。对这类 Service 并不会分配 Cluster IP，kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由。 DNS 如何实现自动配置，依赖于 Service 是否定义了 selector。
示例:(headless-svc.yaml)
apiVersion: v1 kind: Service metadata: name: headless-svc namespace: default spec: selector: app: nginx-app clusterIP: "None" ports: - port: 80 targetPort: 80
执行命令
[root@master01 ~]# kubectl apply -f headless-svc.yaml service/headless-svc created # 查看 svc。可以看见 headless-svc 的 IP 是空的 [root@master01 ~]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE headless-svc ClusterIP None <none> 80/TCP 5s kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 10d # 查看 k8s 组件所在 IP 地址 [root@k8s-master01 ~]# kubectl get pod -n kube-system -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES coredns-5c98db65d4-4vjp4 1/1 Running 3 20h 10.244.0.7 master01 <none> <none> coredns-5c98db65d4-d2kxh 1/1 Running 4 20h 10.244.0.6 master01 <none> <none> ...... # 使用 dig 命令查看 svc 解析到的ip地址。yum install -y bind-utils 安装 dig 命令 [root@k8s-master01 ~]# dig -t A headless-svc.default.svc.cluster.local. @10.244.0.6 ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> -t A headless-svc.default.svc.cluster.local. @10.244.0.14 ...... ;; ANSWER SECTION: headless-svc.default.svc.cluster.local. 30 IN A 10.244.2.57 headless-svc.default.svc.cluster.local. 30 IN A 10.244.1.47 headless-svc.default.svc.cluster.local. 30 IN A 10.244.1.46
使用 dig 命令从 codedns 组件查看到了 headless-svc 所解析到的 IP 地址。有三个 10.244.2.57、10.244.1.47 和 10.244.1.46。
如果你现在创建一个不使用 spec.clusterIP: "None" 的 svc，使用 codedns 查看，会发现只解析到了一个 IP 上。
【推荐】国内首个AI IDE，深度理解中文开发场景，立即下载体验Trae
【推荐】编程新体验，更懂你的AI，立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包，你的智能百科全书，全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell：AI 加持，快人一步
· go语言实现终端里的倒计时
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语，封装的思维：从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热？
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· 分享一个免费、快速、无限量使用的满血 DeepSeek R1 模型，支持深度思考和联网搜索！
· 基于 Docker 搭建 FRP 内网穿透开源项目（很简单哒）
· ollama系列1：轻松3步本地部署deepseek，普通电脑可用
· 按钮权限的设计及实现
· 25岁的心里话