k8s之Pod控制器

一、Pod控制器

• Pod控制器，又称之为工作负载（workload），是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试进行重启，当根据重启策略无效，则会重新新建pod的资源。

1、pod控制器类型

1.1 ReplicaSet

• 代用户创建指定数量的pod副本，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能。

ReplicaSet主要三个组件组成

• 用户期望的pod副本数量
• 标签选择器，判断哪个pod归自己管理
• 当现存的pod数量不足，会根据pod资源模板进行新建

帮助用户管理无状态的pod资源，精确反应用户定义的目标数量，但是RelicaSet不是直接使用的控制器，而是使用Deployment。

1.2 Deployment

• Deployment是最常用的Pod控制器之一，建立在ReplicaSet之上，它用于部署无状态应用程序。Deployment定义了Pod的期望副本数，并通过滚动更新和回滚机制来管理Pod的升级和降级。
• 工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。

1.3 DaemonSet

• 用于确保集群中的每一个节点运行一个pod副本，通常用于实现系统级后台任务。比如ELK服务。

1.4 StatefulSet

• 部署有状态的应用，每个pod的名称是唯一不变的，每个pod拥有自己专属的持久化的存储（pv/pvc）。

1.5 Job

• Job用于运行一次性任务，如批处理作业或短生命周期的应用程序。Job会创建Pod来执行任务，并在任务完成后删除Pod。
• 只要完成就立即退出，不需要重启或重建。

1.6 Cronjob

• 周期性任务控制，不需要持续后台运行

2、Pod与控制器之间的关系

• controllers：在集群上管理和运行容器的 pod 对象， pod 通过 label-selector 相关联。
• Pod 通过控制器实现应用的运维，如伸缩，升级等。

二、使用POD控制器

1、Deployment

• 部署无状态应用
• 管理Pod和ReplicaSet
• 具有上线部署、副本设定、滚动升级、回滚等
• 提供声明式更新，例如只更新一个新的image
• 应用场景：Web服务、微服务

1.1 创建控制器

kubectl create deployment deploy --image=nginx:1.18 --port=80 --replicas=1 --dry-run=client -oyaml > deploy.yaml
#生成yaml配置文件模板

#修改yaml配置文件
vim deploy.yaml
apiVersion: apps/v1
#指定API版本
kind: Deployment
#指定创建资源类型为Deployment
metadata:
#定义资源的元数据信息
  name: nginx-deploy
  #指定资源的名称
  labels:
  #设置标签
    app: nginx
    #标签以键值表示，标签键为app,标签值为nginx
spec:
#定义资源的规格
  replicas: 1
  #指定创建pod数量为1个
  selector:
  #选择由Deployment管理的Pod的标签选择器
    matchLabels:
    #指定用于匹配的标签
      app: nginx
      #设置标签需要与模板标签一致
  template:
  #创建pod的模板，deployment管理的pod实例，都由此模板定义
    metadata:
    #模板的元数据信息
      labels:
      #定义pod的标签
        app: nginx
        #此处需要与deployment管理pod的标签选择器一致
    spec:
    #pod的规格信息
      containers:
      #定义pod中运行的容器列表
      - name: nginx
      #指定容器名称
        image: nginx:1.18.0
        #指定镜像版本
        ports:
        #定义端口
        - containerPort: 80
        #定义容器内部的监听端口

kubectl apply -f deploy.yaml
#创建资源

kubectl get pods,deploy,rs
#查看pod资源信息

1.2 更新版本

curl 10.244.2.116 -I
#查看版本信息（nginx版本信息是1.80版本）

#修改yaml配置文件
vim deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.20
      #修改版本号
        name: nginx
        ports:
        - containerPort: 80

kubectl apply -f deploy.yaml
#重新创建资源

1.3 查看更新的版本号

kubectl get pod -w
#另开一个终端，追踪查看pod更新过程

curl -I 10.244.1.104
#查看版本信息（nginx版本更新为1.20版本）

2、SatefulSet

StatefulSet 是 Kubernetes 中的一个资源控制器，它用于管理有状态的应用。与 Deployment 和 ReplicaSet 这样的无状态工作负载不同，StatefulSet 为每个 Pod 提供了一个稳定的、唯一的标识符，并且能够保证 Pod 的部署顺序和终止顺序。

• 稳定的标识符：每个Pod都有一个唯一的、持久的标识符，这个标识符在 Pod 的整个生命周期中都是不变的。这使得即使 Pod 被重新调度，其标识符也会保持不变。这一功能常常基于Headless(无头模式，即没有Cluster IP的Service)实现
• 有序的部署和扩展：Pod 是按照特定的顺序进行创建和扩展（0到N-1）的。这允许应用程序在部署时按照特定的顺序进行初始化。
• 有序的终止和缩容：当缩容或删除 StatefulSet 时，Pod 会按照相反的顺序（N-1到0）进行终止。这允许应用程序在关闭时按照特定的顺序进行清理。
• 稳定的持久化存储：StatefulSet 常常与 PersistentVolumeClaims（PVCs）一起使用，以提供稳定的存储。即使 Pod 被重新调度，其存储卷也会被保留并重新附加到新的 Pod 上。
• 常见的应用场景：数据库

https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
#官方文档

2.1 StatefulSet的三个关键组成部分以及其作用

StatefulSet 的设计是为了满足有状态应用的需求，这些应用通常需要持久化存储和稳定的网络标识。

2.1.1 Headless Service（无头服务）

• 目的：Headless Service 用于为 StatefulSet 中的每个 Pod 提供一个稳定的 DNS 名称。这样，即使 Pod 被重新调度到其他节点，它的 DNS 名称也不会改变，从而保证了网络标识的稳定性。
• 实现：Headless Service 不分配 Cluster IP，而是直接将 DNS 请求解析到对应的 Pod IP。这样，每个 Pod 都有一个基于 StatefulSet 名称和 Pod 序号的 DNS 子域，例如 web-0.nginx.default.svc.cluster.local。

2.1.2 VolumeClaimTemplates

• 目的：VolumeClaimTemplates 用于为每个 Pod 提供独立的持久化存储。这样，每个 Pod 都有自己的存储空间，即使在 Pod 重新调度后，也能保持数据的连续性和一致性。
• 实现：在 StatefulSet 的定义中，可以包含一个或多个 VolumeClaimTemplates。当 StatefulSet 创建 Pod 时，会为每个 Pod 创建相应的 PersistentVolumeClaim (PVC)。这些 PVC 会请求与 StatefulSet 关联的 PersistentVolume (PV)，从而为每个 Pod 提供专用的存储卷。

2.1.3 StatefulSet 控制器

• 目的：StatefulSet 控制器负责管理 Pod 的生命周期，确保 Pod 的数量符合用户的期望，并且按照顺序进行部署、扩展和收缩。
• 实现：StatefulSet 控制器会监控 Pod 的状态，确保每个 Pod 都按照定义的顺序运行。在进行滚动更新时，它会按照顺序逐个更新 Pod，确保在更新下一个 Pod 之前，所有先前的 Pod 都已经就绪。同样，在删除 Pod 时，也会按照相反的顺序进行，以确保服务的平滑过渡。

总结

Headless Service（无头服务）：用于为Pod资源标识符生成可解析的DNS记录

VolumeClaimTemplates（存储卷申请模板）：基于静态或动态PV供给方式为Pod资源提供专有的固定存储

StatefulSet：用于管控Pod资源

这三个组件共同工作，使得 StatefulSet 能够为有状态应用提供所需的稳定性和可靠性。Headless Service 解决了网络标识的稳定性问题，VolumeClaimTemplates 解决了持久化存储的需求，而 StatefulSet 控制器则确保了 Pod 的有序管理和更新。这种设计使得 StatefulSet 成为部署和管理有状态应用的理想选择，如数据库、消息队列等。

为什么要有headless？

• 在deployment中，每一个pod是没有名称，是随机字符串，是无序的。而statefulset中是要求有序的，每一个pod的名称必须是固定的。当节点挂了，重建之后的标识符是不变的，每一个节点的节点名称是不能改变的。pod名称是作为pod识别的唯一标识符，必须保证其标识符的稳定并且唯一。
• 为了实现标识符的稳定，这时候就需要一个headless service 解析直达到pod，还需要给pod配置一个唯一的名称。

为什么要有volumeClainTemplate？

• 大部分有状态副本集都会用到持久存储，比如分布式系统来说，由于数据是不一样的，每个节点都需要自己专用的存储节点。而在 deployment中pod模板中创建的存储卷是一个共享的存储卷，多个pod使用同一个存储卷，而statefulset定义中的每一个pod都不能使用同一个存储卷，由此基于pod模板创建pod是不适应的，这就需要引入volumeClainTemplate，当在使用statefulset创建pod时，会自动生成一个PVC，从而请求绑定一个PV，从而有自己专用的存储卷。

服务发现：就是应用服务之间相互定位的过程。

应用场景：

• 动态性强：Pod会飘到别的node节点
• 更新发布频繁：互联网思维小步快跑，先实现再优化，老板永远是先上线再慢慢优化，先把idea变成产品挣到钱然后再慢慢一点一点优化
• 支持自动伸缩：一来大促，肯定是要扩容多个副本

K8S里服务发现的方式—DNS，使K8S集群能够自动关联Service资源的“名称”和“CLUSTER-IP”，从而达到服务被集群自动发现的目的。

实现K8S里DNS功能的插件

• skyDNS：Kubernetes 1.3之前的版本
• kubeDNS：Kubernetes 1.3至Kubernetes 1.11
• CoreDNS：Kubernetes 1.11开始至今

2.2 创建控制器

• 先清空之前创建的pod资源

• 验证dns是否可以使用

kubectl run busybox --image=busybox:1.28 -- sleep 36000
#创建一个busybox的pod，该容器提供一些基本的命令，主要用于测试环境

kubectl get pod busybox
#查看pod资源

kubectl exec -it busybox sh
#进入容器

/ # nslookup kubernetes
#测试svc能否正常解析，可以使用kubectl get svc查看有哪些svc（解析正常，解析kubernetes的地址为10.96.0.1）

kubectl get svc
#查看svc资源信息

2.2.1 创建svc资源

#编辑yaml配置文件
vim service.yaml
apiVersion: v1
#指定API版本
kind: Service
#创建资源类型为Service
metadata:
  name: headless-svc
  #指定service名称
  labels:
    app: headless-svc
    #设置service标签
spec:
  ports:
  - port: 80
  #service端口
    name: web
    #端口名称
    targetPort: 80
    #指定流量转发的目标端口，与pod暴露的端口一致
  clusterIP: None
  #将clusterIP地址的值设置为None，表示无IP地址，即无头模式
  selector:
  #选择管理的标签
    app: state
    #此标签需要与StatefulSet控制器管理的pod模板中定义的标签一致
  type: ClusterIP
  #设置类型为ClusterIP，此为默认设置，可以省略

kubectl apply -f service.yaml
#创建资源

kubectl get svc headless-svc
#查看资源信息

2.2.2 创建StatefulSet

#编辑yaml配置文件
vim statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
#创建资源类型为StatefulSet
metadata:
  name: state
  #指定资源名称
spec:
  serviceName: headless-svc
  #指定需要绑定的service名称
  replicas: 3
  #创建pod数量为三个
  selector:
  #标签选择器，指定StatefulSet要管理哪些pod
    matchLabels:
    #指定标签名称
      app: state
      #必须与service中selector定义的标签一致。pod含有此标签的，都会去管理
  template:
  #指定pod创建模板
    metadata:
      labels:
        app: state
        #设置pod标签，与上面标签选择器相同，StatefulSet才会管理
    spec:
      containers:
      #定义pod中运行的容器
      - name: nginx-pod
      #应当设置有状态的服务，在此以nginx为例，官方文档有MySQL示例
        image: nginx:1.18.0
        #定义镜像
        ports:
        - containerPort: 80
        #定义容器监听端口
          name: web
          #端口名称
        volumeMounts:
        #定义将存储卷卷挂载到指定目录
        - name: html
        #指定存储卷名称
          mountPath: /usr/share/nginx/html
          #挂载到此目录，此目录为nginx服务的站点目录
  volumeClaimTemplates:
  #PVC的请求模板
  - metadata:
      name: html
      #定义PVC的名称
      annotations:
        volume.beta.kubernetes.io/storage-class: nfs-client-storageclass
        #用于指定存储类的注解。该存储类定义了用于动态卷供应的后端存储类型
    spec:
      accessModes: ["ReadWriteOnce"]
      #指定访问模式为RWO
      resources:
        requests:
          storage: 2Gi
          #指定存储卷的使用大小

kubectl apply -f statefulset.yaml 
#创建资源
长度、
kubectl get statefulsets.apps state
#查看资源信息

kubectl get pod -owide -w
#查看pod资源信息
#它会按照0到N-1的顺序去指定pod名称，一定建立，指定pod生命周期结束，否则IP地址改变，它的名称也不会改变

kubectl get pv,pvc
#查看pv/pvc资源信息

• 在nfs服务器上自定义web页面
• nfs服务器

cd /nfs/k8s
#切换目录

echo "this is state-0" > default-html-state-0-pvc-5d4f3a8c-f5da-4aae-a244-1cfef9f328ec/index.html
#编辑state-0访问页面

echo "this is state-1" > default-html-state-1-pvc-23363402-a920-471e-9a1b-da43af18620d/index.html
#编辑state-1访问页面

echo "this is state-2" > default-html-state-2-pvc-754e992e-4573-408d-b78d-687f5dfd285f/index.html
#编辑state-2访问页面

• 访问验证
  • 由于没有ClusterIP地址，想要通过IP地址访问，只能在k8s集群中直接访问podIP

curl 10.244.2.120
curl 10.244.2.121
curl 10.244.1.109
#访问验证

2.2.3 使用service访问

• 创建的svc是可以进行解析的

kubectl exec -it busybox sh
#进入容器

/ # nslookup headless-svc
#查看dns解析
#service会通过endpoint关联到后端的pod

• 访问验证
  • 由于pod的IP地址是k8s集群内部的IP地址，且并没有clusterIP去绑定podIP，只有域名管理，宿主机的DNS解析，无法解析k8s集群内部的域名与地址，所以使用宿主机无法访问pod。只能通过创建pod，在pod中进行访问

kubectl run centos --image=centos:7 -- sleep 36000
#创建一个centos容器，访问service

kubectl exec -it centos sh
#进入容器

curl headless-svc
#访问验证

2.3 删除与创建

• 当pod删除时，会按照N-1到0的顺序，倒序删除

kubectl delete -f statefulset.yaml
#删除pod资源

kubectl get pod -w
#另开一个终端，跟踪查看pod资源信息

• 重新创建的时候，数据会持久化 ，而且创建的顺序还是按照0到N-1的顺序创建

kubectl apply -f statefulset.yaml 
#重新创建资源

kubectl exec -it centos sh
#进入容器

curl headless-svc
#访问验证（重新创建之后再次访问，数据不会丢失）

• 重新创建之后再次访问，数据不会丢失

kubectl exec -it busybox sh
#进入测试容器

/ # nslookup headless-svc
#测试svc解析，后端ip地址发生变化
#不论后端的IP地址如何变化，只通过DNS来解析service，从而绑定后端的IP地址，得到数据

2.4 deployment与statefulset的区别

2.4.1 应用场景

• Deployment：主要用于部署无状态服务，即服务实例之间可以相互替换且不需要保留特定的网络标识或存储数据。它适用于那些不需要关心Pod具体身份且可任意替换的弹性服务。

• StatefulSet：适用于部署有状态的服务，比如数据库集群、消息队列等。这些服务需要稳定的持久化存储和唯一、有序的网络标识。StatefulSet为Pod分配的网络标识符和存储都是稳定的，使得应用能够维持跨重启或再调度的持久状态。

2.4.2 Pod管理

• Deployment：通过ReplicaSet确保指定数量的Pod副本始终运行，提供水平扩展和滚动更新能力。Pod由Deployment创建时，虽然可以自定义名称，但通常由系统生成，并在重建或扩展时可能会发生变化。

• StatefulSet：Pods在创建、更新和删除时按照顺序进行，以满足那些依赖于严格顺序启动或停止的应用场景需求。每个Pod都有一个固定的、唯一的网络标识符，并且其持久卷声明(PVC)会绑定到持久化的存储，即使Pod被删除后重新创建，存储的数据也会保留。

2.4.3 存储与网络

• Deployment：通常不直接管理Pod的存储和网络，而是依赖于其他Kubernetes资源（如PersistentVolume和Service）来实现这些功能。

• StatefulSet：为Pod提供稳定的存储和网络标识，确保有状态应用能够正常运行。StatefulSet通常与Headless Service和volumeClaimTemplate一起使用，以提供可解析的DNS资源记录和专有且固定的存储。

2.4.4 升级与回滚

• Deployment：支持多种升级策略，如滚动更新和回滚，确保服务在整个升级过程中具有高可用性。通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态，并逐步替换旧的Pod。

• StatefulSet：也支持有序而自动的滚动更新，但由于涉及到有状态应用，更新过程可能更加复杂和严格。同时，StatefulSet也支持回滚到之前的版本。

2.4.5 扩展性

• Deployment：可以根据系统负载进行水平扩展和缩容，通过调整ReplicaSet的副本数来实现。

• StatefulSet：虽然也支持扩展和缩容操作，但由于涉及到有状态应用和数据一致性等问题，扩展性可能相对较弱。

3、DaemonSet

• DaemonSet 是 Kubernetes 中的一种工作负载控制器，它确保在集群中的所有（或指定的）节点上运行一个 Pod 的副本。这使得 DaemonSet 成为运行集群级服务的理想选择，如日志收集、监控代理、存储守护进程等。

3.1 关键特性

• 节点覆盖：DaemonSet 确保在集群中的每个节点上都有一个 Pod 副本运行，或者根据需要在特定节点上运行。
• 自动管理：当新节点加入集群时，DaemonSet 会自动在这些节点上创建 Pod。当节点被移除时，相应的 Pod 也会被清理。
• 删除行为：删除 DaemonSet 会删除它创建的所有 Pod，这有助于维护集群的整洁。

3.2 应用场景

• 集群存储守护进程：在每个节点上运行如 GlusterFS 的 glusterd 或 Ceph 的守护进程，以提供分布式存储服务。
• 日志收集：部署如 Fluentd、Logstash 等日志收集代理，以便在每个节点上收集日志并将其发送到中央日志存储。
• 监控代理：在每个节点上运行监控代理，如 Prometheus 的 Node Exporter、Collectd、Datadog 代理、New Relic 代理或 Ganglia 的 gmond，以收集节点的监控数据。
• 网络插件：在每个节点上运行如Calico、Cilium或Flannel等

https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
#官方案例（监控）

3.3 创建控制器

#编辑yaml配置文件
vim daemonset.yaml  
apiVersion: apps/v1
kind: DaemonSet
#创建资源类型为DaemonSet
metadata:
  name: nginx-daemonset
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.18.0
        ports:
        - containerPort: 80

kubectl apply -f daemonset.yaml
#创建资源

kubectl get pod -owide
#查看详细信息（DaemonSet会在每个node节点都创建一个Pod）

4、Job

• Job控制器是Kubernetes中的一个核心组件，主要用于在集群中运行一次性或批处理任务。Job确保在集群中运行独立的任务，并在任务成功完成后自动终止，不会重启。

4.1 主要特点

• 任务执行：Job控制器主要负责批量处理短暂的一次性任务。当任务执行完毕后，Job会自动将Pod的可用数设置为0，并将Pod的状态置为Complete。
• 任务记录：当Job创建的Pod成功执行完任务后，Job会记录成功结束的Pod数量。当成功结束的Pod数量达到指定的数量时，Job完成执行。
• 任务重试：Job支持定义任务的重试策略，通过backoffLimit字段指定Job失败后进行重试的次数。
• 并行任务：Job允许定义多个并行执行的任务，通过parallelism字段指定在任一时刻应该并发运行的Pod数量

4.2 应用场景

• Job常用于运行那些仅需要执行一次的任务

批处理作业

• Kubernetes Job主要被用于执行一次性批处理作业，如每日数据分析、事务处理等。

数据迁移和清理

• Job可以用来定时迁移大量数据，以及维护数据库

后台任务

• Job可以用来执行后台任务，如计算任务、日志采集等

日志打包和压缩

• 例如按时间段打包日志文件、将多个日志文件压缩成一个文件等。

备份和恢复操作

• 例如备份数据库、配置文件等，并将其存储到云存储服务中以便后续恢复

其它应用场景

• kube-bench扫描、离线数据处理，视频解码等业务

4.3 创建控制器

#编辑yaml配置文件
vim job.yaml
apiVersion: batch/v1
#Batch API的第一个稳定版
kind: Job
#指定创建的资源类型是Job
metadata:
  name: job
  #资源名称
spec:
  template:
    spec:
    #spec.template.spec 定义了 Pod 的规格，包括容器的名称、镜像和执行的命令
      containers:
      - name: busybox
      #容器名称
        image: busybox:1.28
        #镜像名称
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
        #perl解释器，-Mbignum=bpi模块中的子进程，使用计算功能，计算结果输出圆周率2000位的结果
      restartPolicy: Never
      #表示 Pod 失败后不会重启。
  backoffLimit: 4
  #表示 Job 在失败后最多重试 4 次

kubectl apply -f job.yaml 
#创建资源

kubectl get job
#查看job资源信息

kubectl get pod -w
#追踪查看pod资源信息

4.4 清除job资源

kubectl get job
#查看job资源信息

kubectl delete -f job.yaml 
#删除job资源

kubectl get job
#查看job资源信息

#编辑yaml配置文件
vim job-limit.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: busybox
spec:
  template:
    spec:
      containers:
        - name: busybox
          image: busybox
          imagePullPolicy: IfNotPresent
          command: ["/bin/sh", "-c", "sleep 10;date;exit 1"]
      restartPolicy: Never
  backoffLimit: 2
  
kubectl apply -f job-limit.yaml
#创建资源
 
kubectl get job,pods
#查看资源信息
 
kubectl get pod -w
#追踪查看资源信息

5、CronJob

• 在Kubernetes中，CronJob控制器用于运行定时任务，例如备份、生成报告等。这些任务在指定的时间周期上自动执行。一个 CronJob 对象就像 linux 系统上的 crontab（cron table）文件中的一行，使用Cron格式进行编写， 并周期性地在给定的调度时间执行Job。它在Kubernetes集群上运行的，可以管理多个Pod。

5.1 创建控制器

• 创建 CronJob 配置文件 (cronjob.yaml) 每分钟打印hello

#编辑yaml配置文件
vim cronjob.yaml
apiVersion: batch/v1beta1
#指定 Kubernetes API 的版本
kind: CronJob
#指定资源类型为 CronJob
metadata:
#包含 CronJob 的名称
  name: hello
spec:
#包含 CronJob 的规格
  schedule: "*/1 * * * *"
  #使用 Cron 表达式定义任务的执行时间表。在这个例子中，"*/1 * * * *" 表示每分钟执行一次。
  jobTemplate:
  #定义了 Job 模板，它包含了执行任务的 Pod 规格
    spec:
      template:
        spec:
          containers:
          #定义了容器的名称、镜像和其他参数
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent
            args:
            #执行的命令，这里使用 /bin/sh 打印当前日期和 "Hello" 消息
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure
          #设置为 OnFailure，表示只在容器失败时重启
 
 
kubectl apply -f cronjob.yaml 
#创建资源
 
kubectl get cronjob
#查看cronjob资源
 
kubectl get pods
#查看pod资源
 
kubectl logs hello-1717340820-s8n4j
#我们查看了 hello-1717225740-8nlx7 Pod 的日志，可以看到打印的日期和 "Hello" 消息。

--------------------------------------------------------------------------------------------
#解决日志查看权限问题
kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous

#如果在查看日志时遇到权限问题，可以通过创建一个 clusterrolebinding 来授予 system:anonymous 用户 cluster-admin 权限。这通常不推荐，因为它会降低集群的安全性。在生产环境中，应该使用更细粒度的权限控制。
-------------------------------------------------------------------------------------------

Pod控制器

• Deployment：部署无状态应用的管理RS和Pod，创建Pod，主要是维护Pod副本数量与期望状态相同，创建和删除Pod时并行执行，升级时想创建一部分，再删除一部分
• StatefulSet：部署有状态的应用，每个Pod的唯一（名称）且不变的，每个Pod拥有自己专属的持久化的存储（PVC和PV）在K8S集群内部可以通过（Pod_name）.（Service_name）.{namespace}.svc.cluster.local 解析出Pod的IP（基于headless service 和CoreDNS）
• ​ 创建和删除Pod时有顺序的（串行执行的），升级时串行执行的，会删除旧的Pod，再创建和新Pod删除和升级时逆序执行的（先从标识符最大的n-1开始，一直到最小的0）
• Daemonset：理论上在K8S集群的所有Node节点上创建相同的Pod（无论Node节点什么时候加入到K8S集群），但是会受到Node节点上污点影响
• Job：部署一次性任务，正常完成后容器立即退出并且不重启容器（RestartPolicy不设置Always），也不会重建异常完成后重试任务，重建次数根据backofflimit 配置指定（默认为6次）
  用户 cluster-admin 权限。这通常不推荐，因为它会降低集群的安全性。在生产环境中，应该使用更细粒度的权限控制。