【Kubernetes】实践篇

系列综述：💞目的：本系列是个人整理为了云计算学习的，整理期间苛求每个知识点，平衡理解简易度与深入程度。🥰来源：材料主要源于––进行的，每个知识点的修正和深入主要参考各平台大佬的文章，其中也可能含有少量的个人实验自证。🤭结语：如果有帮到你的地方，就和！！！！，后续继续完善和扩充👍(●’◡’●)

逆羽飘扬

1123人浏览 · 2024-12-23 15:12:17

逆羽飘扬 · 2024-12-23 15:12:17 发布

系列综述：
💞目的：本系列是个人整理为了云计算学习的，整理期间苛求每个知识点，平衡理解简易度与深入程度。
🥰来源：材料主要源于–Kubernetes 官方文档–进行的，每个知识点的修正和深入主要参考各平台大佬的文章，其中也可能含有少量的个人实验自证。
🤭结语：如果有帮到你的地方，就点个赞和关注一下呗，谢谢🎈🎄🌷！！！

请先收藏！！！，后续继续完善和扩充👍(●’◡’●)

😊点此到文末惊喜↩︎

零、kubectl基础

基本命令

通用公式：kubectl + [Command] + [Type] + [ResourceName]+ [Flags]
- [Command]：指定要执行的基本的CRUD操作，如create、get、describe、delete等
- [Type]：指定资源类型，注意区分大小写，如pod（po）、node（no）、Service（svc）、Deployment（dep）、ReplicaSet（rs）等
- [ResourceName]：指定资源的名称。名称区分大小写，如 <pod-name>、 <service-name>
- [Flags]：指定可选的参数，用于进一步定制命令的行为
kubectl的增删改查
- 创建资源：kubectl create -f ResourceName.yaml/json
  - create仅用于创建新的资源对象，若对象已存在则报错
  - apply也可用于创建新资源对象时，若资源对象已存在会进行更新。
- 删除资源：kubectl delete [Type] [ResourceName]
- 更新资源配置：kubectl apply -f [ResourceName.yaml/json]
- 查看资源基本信息：kubectl get [Type]s
  - -w可以进行持续监听资源状态
  - --show-labels：显示lables标签
  - -l key1=value1, key2=value2：进行资源的匹配
  - -l 'key in (value1, value2, value3)'：在值集合中进行匹配
- 查看资源的事件：kubectl describe [Type] [ResourceName]
- 查看Pod的日志：kubectl logs [PodName]
- 持久修改配置文件：kubectl edit [Type] [ResourceName]，可以通过外部命令行形式进行临时加标签，但是临时标签可能因更新而失效
在Pod中执行命令：kubectl exec -it [PodName] -- [Command]
将本地端口和Pod端口进行映射
kubectl port-forward [PodName] <local-port>:<pod-port>
用于调整Deployment的副本数量：
kubectl scale deployment <deployment-name> --replicas=<replica-count>
资源对象内的容器执行命令：kubectl exec -it [ResourceName] -c [ContainerName] -- [Command]
滚动更新和回滚
- 查看滚动更新状态：kubectl rollout status [Type] [ResourceName]
- 回滚到先前的版本：kubectl rollout undo [Type] [ResourceName]
- 暂停滚动更新：kubectl rollout pause [Type] [ResourceName]
- 恢复滚动更新：kubectl rollout resume [Type] [ResourceName]
- 查看滚动更新历史：
  - 查看所有历史版本：kubectl rollout history [Type] [ResourceName]
  - 查看指定历史版本：kubectl rollout history [Type] [ResourceName] --revision=[1~100]
kubectl get svc的查询结果
- NAME：标识集群中服务实例的名称
- TYPE
  - ClusterIP: 最常见的类型，为服务分配一个只允许集群内部的Pod访问的虚拟IP
  - NodePort：客户端访问EXTERNAL-IP : nodePort，每个节点的kube-proxy会将请求转发到Service的targetPort实际进行处理
  - LoadBalancer：客户端访问EXTERNAL-IP : port，负载均衡器会将EXTERNAL-IP更新为负载均衡器的IP地址，所以可以使用内部的port去访问Service
  - ExternalName: 此类型将服务映射到外部DNS名称，不分配集群内部的IP地址，而是通过DNS解析来访问外部服务。
- CLUSTER-IP：用于在集群内部Pod之间进行通信的虚拟IP地址
- EXTERNAL-IP：允许外部访问集群内部服务的IP地址，外部主机需要通过VPN或绑定才能访问
- AGE：表示Service已经创建的时间
- 注意：集群外部访问外网IP : 外部代理端口，会通过LoadBalancer机制将外部请求负载均衡到集群内部的多个Pod上，每个节点的内部分发端口会接收LB代理转发过来的请求

NAME	TYPE	CLUSTER-IP	EXTERNAL-IP	PORT(S)	AGE
kube-node-service-lb	LoadBalancer	10.99.201.198	外网IP1, 外网IP2	port : nodePort/TCP	29d
kube-node-service	NodePort	10.97.114.36	外网IP1, 外网IP2	port : nodePort/TCP	29d

两种port的作用
- targetport：在多容器Pod中，可以将Pod内不同容器的服务端口统一为targetPort，但可以将流量路由到不同的容器端口
- port：指定服务在集群内部的监听端口

一、深入Pods

Pod探针

定义：根据不同的探针探测容器当前状态，如果Pod状态异常，会执行对应的修复策略，从而提高系统稳定性
探针类型
- StartupProbe（启动探针）：探测容器内是否已完成所有初始化操作，能够进行用户请求的处理
- ReadinessProbe（就绪探针）：检测Pod内的是否所有容器已就绪，如果都通过检查，则会将该Pod加入Endpoint服务列表中
- LivenessProbe（存活探针）：检测容器内部是否应用进程还存活，若探测到进程不存在或终止，则会执行相应的容器重启策略

探测方式

TCPSocketAction（TCP检查）：通过尝试与容器内的特定端口建立TCP连接来判断应用是否运行。
HTTPGetAction（HTTP请求）：向容器内的特定URL发送HTTP请求，根据HTTP响应状态码判断应用是否健康。
ExecAction（执行命令）：在容器内部执行一个命令，根据命令退出状态码判断应用状态
具体应用：根据不同的应用场景，灵活使用三种方式进行探测，yaml文件示例如下

apiVersion: v1
kind: Pod
metadata:
  name: startup-probe-example
spec:
  containers:
  - name: app-container
    image: my-app-image:latest
    # 1. StartupProbe + TCPSocketAction探测配置
    startupProbe: # 应用启动探针配置
      tcpSocket: # 基于TCP的测试方式，若无法访问80端口则失败
    	port:80 # 请求端口
    # 2. ReadinessProbe + HTTPGetAction探测配置
    livenessProbe: # 应用存活探针配置
      httpGet: # 基于 http 请求探测，若是无法访问Path的内容则失败
        path: /api/path # http 请求路径
        port: 80 # 请求端口
	# 3. ExecAction + ExecAction探测配置
	redinessProbe: # 应用就绪探针配置
	  exec: # 基于exec命令执行进行探测
		command :
		- sh
		- -C
		- "sleep 5; echo 'success' > /inited" # 输出success字符到inited文件中
      failureThreshold: 3 # 失败多少次才算真正失败
      periodSeconds: 10 # 间隔时间
      successThreshold: 1 # 多少次监测成功算成功
      timeoutSeconds: 3 # 请求的超时时间

创建Pod

创建并进入pods文件：mkdir pods && cd pods
创建yaml文件：vim [name]-pod.yaml
编写yaml文件，示例如下
根据yaml文件创建Pod：kubectl create -f [name]-pod.yaml

apiVersion: v1 # api文档版本
kind: Pod # 资源对象类型，如Pod、Deployment、StatuefulSet等
metadata: # 资源元数据描述
  name: nginx-po # 自定义的Pod名称
  labels: # Pod的描述信息，内容为自定义的多个键值对
    type: app # 自定义label标签，名字为type，值为app
    version: "1.0.0" # 自定义label标签，描述Pod版本号
  namespace: default # 命名空间的配置
spec: # 期望Pod按照这里面的描述进行创建
  terminationGracePeriodSeconds：#当pod执行delete操作时间，宽限的时间
  containers: # 对于Pod中的容器描述
  - name: nginx # 容器的名称
    image: nginx:1.7.9 # 指定容器的镜像
    imagePullPolicy: IfNotPresent # 镜像拉取策略:本地不存在就从镜像仓库拉取
    lifecycle: # 生命周期的配置
	  poststart: # 生命周期启动阶段做的事情，不一定在容器的command 之前运行
		exec:
			command :
			- sh
			- -c
			- "echo '<hl>prestop</h1>'> /usr/share/nginx/html/prestop.html"
	  preStop: # 在容器被终止之前执行的操作
	  	exec:
			command :
			- sh
			- -c
			- "echo '<hl>finished...</h1>'> /usr/share/nginx/html/prestop.html"
    command: # 指定容器启动时执行的命令
    - nginx
    - -g
    - 'daemon off;'
    workingDir: "/usr/share/nginx/html" # 定义容器启动后的工作目录
    ports: # 端口配置
    - name: http # 端口名称
      containerPort: 80 # 描述容器内要暴露的端口
      protocol: TCP # 描述该端口是基于哪种协议通信的
    env: # 环境变量
    - name: JVM_OPTS # 环境变量名称
      value: "-Xms128m -Xmx128m" # 环境变量的值
    resources: # 资源限制
      requests: # 最少需要多少资源
        cpu: "100m" # 限制cpu最少使用0.1个核心
        memory: "128Mi" # 限制内存最少使用128兆
      limits: # 最多可以用多少资源
        cpu: "200m" # 限制cpu最多使用0.2个核心
        memory: "256Mi" # 限制最多使用256兆
  restartPolicy: OnFailure # 重启策略，只有失败的情况才会重启

Pod生命周期示例
- 初始化阶段：按序对Pod内所有容器进行初始化操作
- 容器生命周期钩子函数（回调函数）
  - PostStart：在容器创建后立即执行的操作，常用于加载配置、预热缓存等
  - PreStop：容器将结束时执行的操作，常用于注册中心下线、数据销毁、数据清理等
- 探针执行顺序：就绪探针和存活探针会在启动探针执行成功后开始运行，进行持续的就绪和存活状态探查
- Pause容器：为同一Pod中所有的容器提供共享的网络资源、存储资源，并管理整个Pod的生命周期 6. Pod的退出流程
- Endpoint 删除 Pod 的 IP 地址：当一个Pod被标记为删除时，Kubernetes的Endpoint Controller会从Endpoint对象中移除该Pod的IP地址，从而确保了服务的流量不再被路由到即将删除的Pod。
- Pod 变成 Terminating 状态：Pod的状态被设置为Terminating，Kubernetes将不再接受针对该Pod的新请求，以避免在Pod关闭过程中处理新的业务逻辑。
- 执行 preStop 的指令：若Pod配置了preStop钩子，在终止前preStop中的指令将被执行，确保了Pod内的应用程序能够优雅地关闭，避免了突然的中断可能带来的数据不一致或业务中断问题。
- 等待 TerminationGracePeriodSeconds：Pod进入Terminating状态后，Kubernetes会等待一个由terminationGracePeriodSeconds参数定义的宽限期。这个宽限期允许Pod内的应用程序完成当前的业务处理，关闭连接，执行清理操作等。如果在宽限期结束前，Pod内的所有容器都未能优雅地退出，Kubernetes将发送SIGKILL信号强制终止Pod。
- 清理 Pod 资源：一旦Pod内的所有容器都已停止，Kubernetes将执行最后的清理操作，包括释放Pod占用的资源，如存储卷、网络资源等，确保了集群资源的正确回收，为新Pod的创建腾出空间。
用户与Pod通信流程（用户请求 - API Server - svc - ep - node上的kube-proxy - Pod - 容器）
- 用户请求：用户发起请求到API Server ，而API Server会接收并解析用户请求并根据请求的目标和内容，将请求转发到对应的Service
- Service 转发：svc根据Endpoint定义的网络规则将请求转发到对应Pod的kube-proxy中
- kube-proxy：在每个node上的 kube-proxy 组件基于相应的 iptables 规则，高效地将请求转发到目标Pod上
- Pod 接收：Pod 内容器的应用程序监听yaml文件定义的port端口，接收并处理 kube-proxy 转发的请求。
- Pod 响应：处理完请求后，Pod 将响应发送回 kube-proxy，然后通过相同的网络规则路径返回给用户
- 注意：
  - Endpoint 更新：Kubernetes 会持续监控 Pod 的状态，当有新的 Pod 加入或旧的 Pod 被移除时，Endpoint 资源会更新，kube-proxy 也会相应地更新其网络规则。
  - 多种代理方式：根据集群配置不同，svc可能使用不同的代理方式，如默认的kube-proxy 或Cilium、Calico 、Istio 服务网格等

二、资源调度

Deployment

Deployment概述
- 定义：用于管理运行无状态（交互信息由请求方保存）应用程序的Pod的资源对象
- 作用
  - 声明式更新：Deployment 根据配置定义自动进行Pod生命周期的管理，确保应用始终处于期望状态。
  - 滚动更新：Deployment 支持滚动更新策略，允许在不中断服务的情况下逐步更新应用，确保服务的高可用性
  - 版本回滚：若新版本的Deployment出现问题，用户可以通过kubectl快速回滚到应用的历史版本
  - 扩容缩容：根据定义的期望副本数量决定Pod的扩缩容数量
  - 暂停与恢复：在更新过程中，可以暂停更新流程，K8s 会保存当前 Deployment 状态，恢复更新时，会从暂停的状态继续执行
- 原理：Deployment 控制器通过 ReplicaSet（副本集控制器）管理 Pod 的生命周期
Deployment工作流程
- 创建 Deployment：用户根据yaml文件创建Deployment 对象，并定义应用程序的预期运行状态
- 创建 ReplicaSet：Deployment 控制器创建或更新一个 ReplicaSet，以确保 Pod 副本的数量与预期状态一致
- 创建 Pod：ReplicaSet 根据 Deployment 定义的 Pod 模板创建或更新 Pod
- 监控 Pod：Deployment 控制器持续监控 Pod 的状态，确保副本数量与预期状态一致
- 更新 Pod：当用户更新 Deployment 时，控制器会根据定义的更新策略逐步替换旧版本的 Pod
ReplicaSet（副本控制器）
- 作用
  - 符合期望：负责创建和维护一组 Pod，确保集群中运行的Pod 副本数量与配置定义的期望数量相匹配
  - 标签选择器：ReplicaSet 可以使用标签选择器来识别其管理的 Pod
  - Pod模板：ReplicaSet 包含一个 Pod 模板（template），用于定义创建新 Pod 时使用的配置
- 注意：从 Kubernetes v1.2 版本开始，ReplicationController 被升级为 ReplicaSet，以提供更强大的功能和更灵活的 LabelSelector
- 层次包含关系：Deployment $\supset$ ReplicaSet $\supset$ Pods

Deployment的yaml文件示例

apiVersion: apps/v1 # deployment api 版本
kind: Deployment # 资源类型为 deployment
metadata: # 元信息
  labels: # 标签
    app: nginx-deploy # 具体的 key:value 配置形式
  name: nginx-deploy # deployment 的名字
  namespace: default # 所在的命名空间
spec:
  replicas: 1 # 期望副本数
  revisionHistoryLimit: 10 # 进行滚动更新后，保留的历史版本数
  selector: # 选择器，用于找到匹配的 RS
    matchLabels: # 按照标签匹配
      app: nginx-deploy # 匹配的标签key/value
  strategy: # 更新策略
    rollingUpdate: # 滚动更新配置
      maxSurge: 25% # 进行滚动更新时，表示可以同时启动最多 25% 的新实例
      maxUnavailable: 25% # 进行滚动更新时，表示可以同时停止最多 25% 的旧实例
    type: RollingUpdate # 更新类型，采用滚动更新
  template: # pod 模板
    metadata: # pod 的元信息
      labels: # pod 的标签
        app: nginx-deploy
    spec: # pod 期望信息
      containers: # pod 的容器
        - image: nginx:1.7.9 # 镜像
          imagePullPolicy: IfNotPresent # 拉取策略
          name: nginx # 容器名称
      restartPolicy: Always # 重启策略
      terminationGracePeriodSeconds: 30 # 删除操作最多宽限多长时间

Deployment相关的文件
- 创建描述 Deployment 的期望状态的yaml文件
- 基于yaml文件创建Deployment对象：kubectl apply -f [ResourceName-deployment].yaml
- 查看Deployment状态：kubectl get deployments
- 更新Deployment：更改 YAML 文件中的配置，并重新使用kubectl apply -f [ResourceName-deployment].yaml
- 查看 Deployment 详细信息：kubectl describe deployment <deployment-name>
- 扩展或缩容Deployment：kubectl scale deployment <deployment-name> --replicas=<number-of-replicas>
- 删除 Deployment：kubectl delete deployment <deployment-name>
扩容和缩容
- 手动扩/缩容：kubectl scale
  - 作用：用于快速调整ReplicaSet管理的Pod数量，以响应负载变化或资源需求
  - 原理：通过api-server向集群发送请求，只修改内存中控制器对象的 spec.replicas 字段，不修改yaml文件，所以会立即生效
  - 命令：kubectl scale [Type] <Type-name> --replicas=[number]
- 自动扩/缩容：kubectl edit
  - 作用：通过编辑资源对象的yaml文件，实现快速调整应用的规模以响应负载变化或资源需求
  - 原理：编辑yaml文件保存退出后，kubectl edit会将修改后的 YAML 文件发送回 Kubernetes API Server，触发资源对象的更新，然后进行相应的扩缩容操作
  - 命令：kubectl edit [Type] <Type-name>

StatefulSet(缩写sts)

StatefulSet
- 定义：控制和管理有状态（交互信息由响应方保存）应用的控制器对象
- 作用：
  - 按序缩放：确保 Pod 按照顺序依次创建和删除
  - 持久化网络标识：每个 Pod 都有两个持久唯一的网络标识，即使 Pod 崩溃重建后也不会改变。
    - DNS名称：用于在集群内部进行服务发现，通常格式为 <pod-name>.<namespace>.svc.cluster.local
    - Pod IP：用于集群内部的网络通信，该IP 地址在 Pod 的整个生命周期内保持不变
- 原理：
  - 唯一性：StatefulSet 为每个 Pod 分配一个唯一的索引（从 0 开始），这个索引用于生成唯一的Pod 的名称和存储卷的名称。
  - 存储卷：StatefulSet 为每个 Pod 分配一个持久卷（PersistentVolume），并确保卷与 Pod 的生命周期绑定，即使 Pod 重新调度，其存储卷也会重新挂载到新的 Pod 上
  - 更新策略：StatefulSet 支持定义更新策略，可以控制更新的速度和顺序，确保应用的平滑过渡
  - 滚动更新：StatefulSet 支持滚动更新，即逐个更新 Pod，而不是同时更新所有 Pod，这有助于减少更新过程中的停机时间
关联方式
- 持久化关联：将数据持久化后，通过Volume挂载的形式进行访问，如果docker奔溃，数据不会受到影响
- 非持久化关联：docker奔溃时，数据会损坏

sts的创建

编写YAML文件：用于定义 StatefulSet 的配置，如下示例
kubectl创建：kubectl apply -f <filename.yaml>
验证sts的创建
- 查看所有sts的基本信息：kubectl get statefulsets
- 查看指定sts的详细信息：kubectl describe statefulset [name-sts]

--- # 嵌套多个yaml文件
apiVersion: vl
kind: Service
metadata:
  name: nginx  
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIp: None
  selector:
    app: nginx
---
# statefulset 类型的资源
apiVersion: apps/v1
kind: statefulset 
metadata:
  name: web # statefulset 对象的名字
spec:
  "nginx" # 使用哪个 service 来管理 dns
  serviceName:
  replicas: 2
  selector:
    matchLabels: 
	  app:nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:# 容器内部要暴露的端口
        - containerPort: 80 #具体暴露的端日号
          name: web # 该端口配置的名字
        volumeMounts:#加载数据卷
        - name: www #指定加载哪个数据卷
          mountPath: /usr/share/nginx/html #加载到容器中的哪个目录
      volumeClaimTemplates:#数据卷模板
      - metadata:# 数据卷描述
          name: www #数据卷的名称
          annotations:#数据卷的注解
            volume.alpha.kubernetes.io/storage-class: anything
        spec:#数据卷的规约，即PVC的创建要求
          accessModes: 
          - "ReadWriteOnce" # 访问模式
          resources:
            requests:
              storage: 1Gi # 需要 1G 的存储资源

扩容缩容
- 命令： kubectl scale sts [name-sts] --replicas=[num]
- 注意点：
  - PVC保留：在缩容时，PVC 不会被自动删除，以保留数据。如果需要删除 PVC，需要手动执行。
  - 有序扩缩容：当扩容时，新的 Pod 会按照顺序依次创建；缩容时，Pod 会按照相反的顺序依次删除。
镜像更新
- RollingUpdate 策略
  - 定义：k8s默认更新策略，可通过逐步替换旧版本的Pod实现平滑过渡到新版本
  - 特点：
    - 逐步更新：RollingUpdate 策略会按照 Pod 的序号顺序逐个替换旧版本的 Pod。
    - 服务不中断：在更新过程中，只有一部分 Pod 会被同时更新，其他 Pod 继续提供服务，从而最小化服务中断的风险。
    - 健康检查：Kubernetes 会检查新 Pod 的健康状态，只有当新 Pod 完全健康并准备就绪后，才会继续更新下一个 Pod。
    - 金丝雀发布：可以通过partition字段，和Pod状态监控实现新版本的平滑过渡。
- OnDelete 策略
  - 特点
    - 手动控制：更新过程完全由用户控制。用户需要手动删除旧版本的 Pod，Kubernetes 才会根据最新的 StatefulSet 或 Deployment 配置创建新版本的 Pod。
    - 立即删除：当删除 Pod 时，控制器不会等待新版本的 Pod 完全启动和健康就绪，旧版本的 Pod 会被立即终止。
    - 风险较高：如果没有正确管理更新过程，可能会导致服务中断，所以适合不频繁更新或更新时需要大量手动操作的业务场景
删除sts
- 删除sts及pods
  - 级联删除kubectl delete sts [name-sts]：默认情况下，当删除一个 StatefulSet 时，其关联的 Pods 也会被删除
  - 非级联删除kubectl delete sts [name-sts] --save-orphans：在删除 StatefulSet 时保留 Pods，然后手动删除其他pod
- 删除svc：kubectl delete svc [name-svc]
删除pvc
- 注意：当删除 StatefulSet 时，为了保留数据，关联的 PVC 并不会被自动删除。若该数据不再使用，则需要手动删除，且该操作不可逆。
- 指令：kubectl delete pvc [name-pvc]
灰度发布/金丝雀发布/蓝绿部署
- 定义：用于减少新版本上线风险的软件发布策略，从而确保系统的稳定性和可靠性
- 原理
  - 部分更新：只将序号大于或等于 partition 值的 Pod 更新到新版本
  - 流量分割：将用户流量分割一部分到新版本的Pod中
  - 监控和分析：对新版本的性能和用户行为进行监控和分析，以评估新版本的稳定性和效果。
  - 逐步扩大：根据监控结果，逐步增加新版本的流量比例，直至完全替换旧版本。
PersistentVolumeClaim (PVC)
- 定义：基于集群存储资源PV实现的管理用户请求的存储空间的资源对象，定义了存储大小、访问模式（如ReadOnlyMany、ReadWriteMany）等要求。
- 作用：
  - 抽象存储细节：PVC 允许用户请求存储而无需关心底层存储是如何实现的
  - 持久化存储：解决有状态应用的持久化问题，即保证Pod被删除，其持久化的数据仍然存在
  - 动态供应：当 PVC 被创建时，存储供应器会自动将 PVC 与合适的PV)进行匹配和绑定

DaemonSet（简写ds）

基本概述
- 定义：k8s中的一种工作负载资源对象，用于在集群的每个节点上部署一个守护进程Daemon，以执行特定的任务或服务
- 作用：
  - 系统级服务的部署：如日志收集器（Fluentd、Logstash）、监控代理（Prometheus Node Exporter、Collectd、Datadog代理）、网络代理等。
  - 日志和监控：在每个节点上部署日志收集和监控服务，如使用Fluentd或Prometheus Node Exporter。
  - 网络操作：运行管理或维护节点网络配置的应用，确保Pod间的通信。
  - 存储：部署存储驱动，使每个节点能够访问特定的存储资源。
  - 安全：部署安全代理或其他安全工具，实施一致的安全策略
- 原理：
  - 监听节点变化：DaemonSet Controller监听节点的加入和删除事件。
  - 自动部署和清理：为每个符合条件的节点创建Pod；当节点从集群中移除时，自动清理这些Pod。
  - 更新策略：支持滚动更新和重新创建策略，根据DaemonSet的更新策略管理Pod的更新。
  - 污点和容忍：DaemonSet可以配置Pod的容忍度，这对于在特殊用途的节点（如GPU节点）上运行守护进程很有用
创建Daemon的yaml文件示例
- 若不指定部署的节点，则会向所有的非master节点进行部署

apiVersion: apps/v1 # 指定API版本
kind: DaemonSet # 创建 DaemonSet 资源
metadata:
  name: fluentd # 名字
spec:
  selector:
    app:logging
  template:
    metadata:
      labels:
        app: logging # 应用标签
        id: fluentd # 资源ID标签
        name: fluentd # 资源名称标签
    spec:
      containers:
        - name: fluentd-es # 容器名称
          image: agilestacks/fluentd-elasticsearch:vl.3.0 # 使用的镜像
          env: # 环境变量配置
            - name: FLUENTD_ARGS # 环境变量的 key
              value: "-qq" # 环境变量的 value
          volumeMounts: # 加载数据卷，避免数据丢失
            - name: containers # 数据卷的名字
              mountPath: /var/lib/docker/containers # 将数据卷挂载到容器内的哪个目录
            - name: varlog
              mountPath: /var/log # 将数据卷挂载到容器内的哪个目录
      volumes: # 定义数据卷
        - name: containers # 定义的数据卷的名称
          hostPath: # 数据卷类型，主机路径的模式，也就是与 node 共享目录
            path: /var/lib/docker/containers # node 中的共享目录
        - name: varlog # 定义的数据卷的名称
          hostPath: # 数据卷类型，主机路径的模式，也就是与 node 共享目录
            path: /var/log # node 中的共享目录

Horizontal Pod Autoscaler（简写HPA）

概述
- 定义：k8s中自动调整Pod的副本数量从而响应工作负载变化的控制器
- 作用
  - 自动扩缩容：根据预设的资源使用阈值，自动增加/减少Pod的副本数量，以应对负载的增加/减少。
  - 资源优化：确保资源的高效利用，避免资源浪费或过度配置。
  - 成本控制：在低负载期间，HPA可以减少Pod的数量，从而降低云资源的使用成本。
- 原理
  - 监控资源使用：HPA定期（默认为30秒）查询Metrics Server或Prometheus等监控系统，获取Pod的资源使用情况。
  - 计算目标副本数：根据当前的资源使用情况和预设的资源使用阈值，计算出目标的Pod副本数量。
  - 调整Pod数量：如果目标副本数与当前副本数不同，HPA将触发Deployment、StatefulSet或ReplicaSet等控制器来增加或减少Pod的数量。
  - 自定义指标支持：除了CPU和内存使用率，HPA还支持自定义指标，如队列长度、活跃连接数等，这使得HPA能够根据更具体的应用场景进行调整
开启HPA的指标服务
- 安装 Metrics Server
  - Metrics Server 是 Kubernetes 集群的核心监控数据聚合器，它提供了集群内资源使用情况的实时数据
  - 指令：kubectl apply -f metrics-server.yaml
- 配置HPA
  - 快捷指令：kubectl autoscale deployment <deployment-name> --cpu-percent=[目标cpu使用率] --min=最低pod数量 --max=最大pod数量
  - 进行细粒度的yaml文件配置

在不同node上面的节点，IP网段不同

三、服务发布

Service（svc）

Service概述
- 定义：是一组提供相同服务的Pod 集合和Pod访问策略的抽象
- 作用
  - 抽象解耦：Service 为一组 Pod 提供了一个统一的访问点，隐藏了后端 Pod 的具体细节，如 IP 地址和端口。使得客户端可以使用一个静态的Service IP和端口来访问动态变化的 Pod 集合。
  - 负载均衡：在多个可用的Pod中均匀的分发请求
  - 服务发现：Service 通过 Endpoint 实现服务发现，Endpoint 维护所有可用的 Pod 的 IP 地址和端口。当 Pod 的状态发生变化时，Endpoint 会自动更新，确保 Service 始终指向最新的 Pod。
- 原理
  - Service Controller：当创建 Service 时，Service Controller 会监听 Service 和 Pod 的变化，自动创建和更新 Endpoint 对象。Endpoint 对象包含了 Service 后端 Pod 的实际 IP 地址和端口。
  - kube-proxy：kube-proxy 是运行在每个 Node 节点上的代理服务，负责将 Service 的请求转发到正确的 Pod。它通过监听 Service 和 Endpoint 的变化，动态更新节点上的 iptables 或 ipvs 规则，以实现请求的正确路由。
  - 负载均衡策略：Service 支持多种负载均衡策略，如轮询（Round Robin）、最小连接数（Least Connections）等，这些策略决定了请求如何在后端 Pod 之间分发。
Service访问模式
- ClusterIP: 默认配置类型，为服务分配一个只允许集群内部的Pod访问的虚拟IP
- NodePort：客户端访问EXTERNAL-IP : nodePort，每个节点的kube-proxy会将请求转发到Service的targetPort实际进行处理（端口范围：30000~32767）
- LoadBalancer：使用云服务商提供的负载均衡器。客户端访问EXTERNAL-IP : port，负载均衡器会将EXTERNAL-IP更新为负载均衡器的IP地址，所以可以使用内部的port去访问Service
- ExternalName: 此类型将服务映射到外部DNS名称，不分配集群内部的IP地址，而是通过DNS解析来访问外部服务。
- 注意：nodeport最好使用svc的随机指定，手动指定可能冲突。也可以直接暴露给外部访问，但是这种方式实际生产环境中不推荐使用，因为该方法查找集群节点是轮询O(n)的复杂度，效率较低。

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  # 1. ClusterIP类型
  # 访问方式：为服务分配一个只在集群内部可访问的虚拟 IP 地址。
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  type: ClusterIP
  # 2. NodePort类型
  # 访问方式：允许客户端通过每个节点的 EXTERNAL-IP:nodePort 访问服务，其中 nodePort 是你指定的端口。
    ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
      nodePort: 30080
  type: NodePort
  # 3.  LoadBalancer类型
  # 访问方式：通过EXTERNAL-IP:port访问svc，其中 EXTERNAL-IP是由云服务商提供的负载均衡器的 IP 地址
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  type: LoadBalancer
  # 4. ExternalName类型
  # 访问方式：将服务映射到外部 DNS 名称，客户端可以通过解析 my-externalname-service 访问外部服务
  type: ExternalName
  externalName: my.external.service.com

常用指令
- 创建：kubectl apply -f <filename.yaml>
- 查看所有svc信息：kubectl get svc <service-name> -o wide
- 查看指定svc信息：kubectl describe svc <service-name>
- 删除：kubectl delete svc <service-name>
- 更新：kubectl edit svc <service-name>
通过svc-name进行访问
- 进入Pod应用程序终端：kubectl exec -it [pod-name] -- sh
- 访问指定服务：wegt/curl https://[name-svc]
svc通过IP访问外部服务
- 作用：进行项目迁移时，可以与未迁移完成部分进行交互，从而确保服务的稳定迁移
- 原理：svc统一动态Pod集合的访问接口，从而实现更简单的访问k8s集群外的其他服务
- 实现方式：当编写svc配置文件时，不指定selector属性，则svc将不会创建endpoint，从而可以进行自定义【name-ep-external.yaml】文件实现服务的访问
- 使用：通过kubectl create -f [name-ep-external.yaml]创建后，使用vim进行更改
- yaml文件示意
```
apiVersion: v1
kind: Endpoints
metadata:
  name: nginx-svc-external # 与 service 名称一致
  namespace: default # 与 service 一致
  labels:
    app: nginx-svc-external # 与 service 标签一致
subsets:
- addresses:
  - ip: <target-ip> # 目标 IP 地址
  ports:
  - name: http # 与 service 一致
    port: 80
    protocol: TCP
```
- 流程示意图片

反向代理外部域名（通过域名访问外部服务）

将【name-ep-external.yaml】文件更改为ExternalName类型

apiVersion: v1
kind: Service
metadata:
  name: wolfcode-external-domain
  labels:
    app: wolfcode-external-domain
spec:
  type: ExternalName
  externalName: www.外部服务的域名.com

nodeport概述
在 Kubernetes 集群中，当 Service 的类型被设置为 NodePort 时，kube-proxy 会在所有安装了 kube-proxy 的节点上绑定一个端口，此端口可以代理至对应的 Pod。这意味着，集群外部的客户端可以通过任意节点的 IP 地址加上 NodePort 的端口号来访问集群中对应 Pod 中的服务。例如，如果一个 NodePort 被设置为 30080，那么客户端可以通过 <任一节点IP>:30080 来访问服务。
为了配置 NodePort，你可以在 Service 的 YAML 配置文件中的 ports 部分增加 nodePort 配置来指定一个端口。这个端口必须位于 Kubernetes 允许的范围内，通常是 30000-32767。如果你没有指定一个端口，Kubernetes 将随机为你的 Service 分配一个端口。尽管手动指定 NodePort 可以让你控制访问点，但这样做可能会引起端口冲突，因此建议使用 Kubernetes 随机指定的端口。
虽然 NodePort 允许直接从集群外部访问服务，但这种方法在实际生产环境中并不推荐。原因在于，使用 NodePort 访问服务需要客户端轮询所有集群节点（O(n) 复杂度），这会导致效率较低。在生产环境中，更推荐使用负载均衡器或 Ingress 资源来管理外部访问，这些方法可以提供更高效的流量管理和负载分配。在生产环境中，直接使用 NodePort 访问不推荐，因为效率较低，需要客户端轮询所有节点。
推荐实践：推荐使用负载均衡器或 Ingress 资源来管理外部访问，这些方法提供更高效的流量管理和负载分配。

Ingress

Ingress概述
- 定义：负责控制和管理外部访问流量路由到集群内部
- 作用：
  - 流量路由：允许定义基于 URL 路径或主机名的路由规则，将外部流量转发到相应的集群内部服务
  - 负载均衡：可以自动在多个服务实例之间分配流量，实现负载均衡。
  - SSL配置：可以为不同服务配置SSL证书，用于加密和解密外部流量，确保数据传输的安全性。
  - 虚拟托管：允许多个服务共享同一个 IP 地址，但每个服务有不同的 DNS 名称，并且在同一个 DNS 名称下，根据 URL 路径将流量路由到不同的服务
    - 基于路径的服务匹配：根据请求的HTTP URI将来自同一IP 地址的流量路由到多个 Service
    - 基于名称的服务匹配：支持根据多个主机名的 HTTP 流量路由到同一 IP 地址上
- 原理：
  - 根据Ingress规则中的域名和URL路径，将用户的请求转发到集群内部的一个或多个服务。Ingress Controller充当了集群内部服务与外部世界之间的桥梁，实现了基于内容的七层负载均衡。
  - 当外部请求到达 Ingress 资源所配置的入口地址时，Ingress 控制器根据 Ingress 资源中定义的规则（如基于路径、基于主机名等），将请求转发到相应的后端服务。
  - Ingress 资源：用户定义 Ingress 资源，指定路由规则，这些规则告诉 Kubernetes 如何处理进入集群的 HTTP/HTTPS 请求。
  - Ingress 控制器：Ingress 资源本身不处理流量，它需要一个 Ingress 控制器来实现。Ingress 控制器是实现 Ingress 规则的组件，它可能是一个单独的 Pod 或一组 Pod，负责监听 Ingress 资源的变化，并更新其路由规则。
  - 负载均衡器：Ingress 控制器通常使用负载均衡器（如 nginx、HAProxy 或 Traefik）来处理流量的转发。控制器会配置负载均衡器，使其根据 Ingress 规则将请求路由到正确的服务。
  - 服务发现：Ingress 控制器与 Kubernetes API 服务器通信，以发现集群内服务和端点的变化，并更新路由规则以反映这些变化。
  - 网络配置：Ingress 控制器可能会配置网络相关的资源，如 iptables 规则或网络地址转换（NAT）规则，以确保流量正确地从节点的外部接口转发到集群内的服务。
安装Ingress-nginx
基本使用

ingress是标准化网络服务接口，是Nginx等网络服务的抽象
在这里插入图片描述

endpoint（ep）

四、配置与存储

配置管理

ConfigMap(简写cm )

定义：k8s中用于存储非机密性配置数据的一种资源对象
作用
- 统一配置管理：多个 Pod 可以共享引用同一个 ConfigMap，从而保证多个应用实例配置的一致性
- 动态配置更新：当修改 ConfigMap时，引用该 ConfigMap 的 Pod 会自动重新加载配置，而无需重新部署应用。
- 环境配置隔离：为不同的环境（如开发、测试、生产环境）创建不同的 ConfigMap，实现同一应用程序的不同环境下的配置隔离
创建ConfigMap对象：kubectl apply -f my-configmap.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-configfile-po
spec:
  containers:
  - name: config-test
    image: alpine
    command: ["/bin/sh", "-c", "sleep 3600"]
    imagePullPolicy: IfNotPresent
    env:
    - name: JAVA_VM_OPTS
      valueFrom:
        configMapKeyRef:
          name: test-env-config  # ConfigMap 的名字
          key: JAVA_OPTS_TEST  # 表示从 name 的 ConfigMap 中获取名字为 key 的 value，将其赋值给本地环境变量 JAVA_VM_OPTS
    - name: APP_NAME
      valueFrom:
        configMapKeyRef:
          name: test-env-config
          key: APP_NAME
  volumeMounts:  # 加载数据卷
  - name: db-config  # 表示加载哪个数据卷
    mountPath: "/usr/local/mysql/conf"  # 想要将数据卷中的文件加载到哪个目录下
    readOnly: true  # 是否只读
  volumes:  # 数据卷挂载 configmap、secret
  - name: db-config  # 数据卷的名字，随意设置
    configMap:  # 数据卷类型为 ConfigMap
      name: test-dir-config  # configMap 的名字，必须跟想要加载的 configmap 相同
      items:  # 对 configmap 中的 key 进行映射
      - key: "db.properties"  # configMap 中的 key
        path: "db.properties"  # 将该 key 的值转换为文件
  restartPolicy: Never

Secret
- 定义：用于存储敏感信息，如密码、密钥、证书等，以安全的方式提供给 Pod 和其他资源使用。
Subpath
- 定义：允许将一个 Volume 的特定子目录挂载到 Pod 的容器中的挂载策略
- 作用
  - 共享存储：允许多个容器共享同一个存储卷的不同子目录。
  - 隔离数据：确保每个容器只能访问其所需的数据部分，增强数据隔离性。
  - 灵活性：提供更大的灵活性，使得存储卷的使用更加灵活和高效。
- yaml文件示例
```
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: myimage
    volumeMounts:
    - name: myvolume
      mountPath: "/subpath"
      subPath: "mydata"  # 只挂载 Volume 中的 "mydata" 目录
  volumes:
  - name: myvolume
    persistentVolumeClaim:
      claimName: myclaim
```
配置热更新
- 定义：在运行的服务中动态更新配置，而无需停止和重新启动服务。
- 原理：Kubernetes 会监视 ConfigMap 和 Secret 的变化。当 ConfigMap 或 Secret 被更新时，使用它们的 Pod 会自动接收到新的配置。
- yaml文件示例：定义了一个名为 “mypod” 的 Pod，其中包含一个名为 “mycontainer” 的容器，该容器使用 “myimage” 镜像，并从名为 “myconfigmap” 的 ConfigMap 中获取环境变量来进行配置热更新
```
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: myimage
    envFrom:
    - configMapRef:
        name: myconfigmap
```

NFS（Network File System）

基本概述
- 定义：是一种分布式文件系统协议，允许用户和程序像访问本地文件一样访问存储在远程系统上的文件。
- 作用
  - 文件共享：允许多个 Pod 访问同一个文件系统，使得它们可以共享数据和配置文件。
  - 持久化存储：可以用于持久化存储，确保数据在 Pod 重启后仍然可用。
  - 动态扩缩：支持动态扩容，可以根据需求调整存储容量。
  - 简化管理：服务器可以集中管理，简化了存储管理的复杂性
- 原理
  - C/S模型：NFS 客户端（即 Kubernetes 集群中的 Pod）通过网络向 NFS 服务器（通常是一个或多个专用的存储节点）请求文件服务
  - 文件锁定和缓存：NFS 支持文件锁定机制，以防止并发写入冲突。客户端通常会缓存文件数据，以提高访问效率。
  - 网络协议：NFS 使用特定的网络协议（NFS 版本 4 和 NFS 版本 3）来处理文件访问请求和数据传输。
  - 存储导出：在 NFS 服务器上，存储资源被导出为共享目录，客户端可以挂载这些目录以访问文件

NFS的使用

NFS 可以作为 PersistentVolume（PV）的提供者，用于创建 PersistentVolumeClaims（PVC）

# 定义一个PersistentVolume（持久卷）资源
apiVersion: v1
kind: PersistentVolume
metadata:
  # 持久卷的名称
  name: nfs-pv
spec:
  # 容量信息，这里表示存储容量为10GiB
  capacity:
    storage: 10Gi
  # 访问模式，ReadWriteMany表示可以被多个节点以读写方式挂载
  accessModes:
    - ReadWriteMany
  # 指定使用NFS类型的存储后端
  nfs:
    # NFS服务器的地址
    server: nfs-server.example.com
    # NFS服务器上的共享路径
    path: "/exports/data"
---
# 定义一个PersistentVolumeClaim（持久卷声明）资源
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  # 持久卷声明的名称
  name: nfs-pvc
spec:
  # 访问模式，与上面的PersistentVolume的访问模式一致
  accessModes:
    - ReadWriteMany
  # 资源请求，这里请求的存储容量为10GiB，与PersistentVolume的容量匹配
  resources:
    requests:
      storage: 10Gi
---
# 定义一个Pod资源
apiVersion: v1
kind: Pod
metadata:
  # Pod的名称
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: myimage
    # 容器内的存储卷挂载点信息
    volumeMounts:
    - name: nfs-storage
      # 将存储卷挂载到容器内的/usr/share/mydata路径
      mountPath: /usr/share/mydata
  volumes:
  - name: nfs-storage
    # 引用持久卷声明，将通过持久卷声明关联到对应的持久卷
    persistentVolumeClaim:
      claimName: nfs-pvc

五、高级调度

CronJob

基本概述
- 定义：用于在特定的时间或按照预定的时间任务表自动运行任务
- 作用
  - 定时执行任务：允许用户定义一个时间任务表，按照该表到时自动触发任务的执行
  - 自动化运维：可以定期检查应用状态，自动重启问题容器，或者更新配置文件等
  - 资源使用优化：可以在非高峰时段执行资源耗费重的任务

应用

创建：kubectl apply -f [name-cronjob].yaml
查看所有cronjob的信息：kubectl get cronjob [name-cronjob]
查看指定cronjob的详细信息：kubectl describe cronjob name-cronjob
查看由 CronJob 创建的 Job：kubectl get jobs -o wide
查看 Job 详情：kubectl describe job <job-name>
每天凌晨 2 点执行一个简单的命令，输出当前的日期和时间。此外，还设置了重试次数、成功和失败的 Job 历史记录保留数量。

apiVersion: batch/v1beta1  # 指定 Kubernetes API 的版本，用于处理 CronJob 资源
kind: CronJob  # 定义资源类型为 CronJob
metadata:  # 元数据部分，包含资源的名称和命名空间
  name: daily-date-job  # CronJob 的名称
  namespace: default  # 资源所在的命名空间，默认为 default
spec:  # 详细规格部分，定义 CronJob 的行为和配置
  schedule: "0 2 * * *"  # 定义 CronJob 的调度计划，每天凌晨 2 点执行
  jobTemplate:  # 定义一个 Job 模板，CronJob 将基于此模板创建 Job
    spec:  # Job 的规格
      template:  # 定义 Pod 模板，Job 将基于此模板创建 Pod
        spec:  # Pod 模板的规格
          containers:  # 定义容器列表
          - name: date-container  # 容器的名称
            image: busybox  # 容器使用的镜像
            args:  # 容器启动时执行的命令和参数
            - /bin/sh  # 使用 shell
            - -c  # 执行后面的命令字符串
            - date; echo "CronJob executed at $(date)"  # 执行 date 命令并输出当前时间
          restartPolicy: OnFailure  # 定义重启策略，如果容器失败则重启
      backoffLimit: 3  # 定义失败后重试的次数
  successfulJobsHistoryLimit: 3  # 成功 Job 的历史记录保留数量
  failedJobsHistoryLimit: 1  # 失败 Job 的历史记录保留数量

注意
- Cron 表达式：确保你使用的 cron 表达式格式正确，并且符合你的需求。
- 错误处理：考虑 Job 失败时的处理策略，例如重试或发送通知。

初始化容器initC

定义：用于在应用容器启动前执行一些必要的容器初始化任务
特点：
- 顺序执行：所有的初始化容器会按照其在Pod中的定义顺序依次执行，且每个初始化容器执行成功后下一个才能执行
- 阻塞启动：初始化容器会阻塞应用程序容器的启动，直到所有初始化容器都成功完成。
- 重试机制：如果初始化容器失败，Kubernetes 会对其进行重试，直到成功或达到重试次数限制
作用
- 资源配备：加载应用程序运行所需的资源和配置文件等
- 服务检查：在应用容器启动之前，确保所有必需的服务都已经启动并可以接受请求。
- 环境准备：为应用程序容器执行预配置工作，确保主容器能够在正确环境中运行

yaml配置示例

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  initContainers:
  - name: init-db
    image: busybox
    command: ['sh', '-c', "until nslookup mydatabase; do echo waiting for mydatabase; sleep 2; done"]
  containers:
  - name: myapp
    image: myapp-image
    ports:
    - containerPort: 80

污点和容忍度

污点和容忍度
- 定义：定义在集群Node或Pod上的标记，用于控制Pod在集群节点上的调度行为
  - 污点（Taint）：定义在Node上，标识该节点对某些 Pod 的排斥
  - 容忍度（Toleration）：定义在Pod上，标识该Pod可以容忍的节点污点
- 作用
  - 优化调度：允许管理员根据节点状态来控制 Pod 的调度，确保 Pod 被调度到合适的节点上，避免资源浪费和性能问题
  - 资源隔离：通过污点和容忍度机制避免Pod调度到某些节点上，从而实现Pod和Node的隔离
  - 节点维护：在节点发生故障或需要维护时，可以使用 NoExecute 效果的污点来驱逐节点上的所有 Pod，以便进行安全的维护操作，而不会影响集群中其他节点上的 Pod。
污点和容忍度的构成
- 键：键是污点和容忍度匹配的基础，只有当 Pod 的容忍度键与节点上的污点键相匹配时，Pod 才能被调度到该节点上。
- 值：值是与键关联的附加信息，用于进一步描述污点或容忍度的特性。值可以为空，表示任何值都匹配。在匹配过程中，Pod 的容忍度值必须与节点上的污点值相匹配。
- 效果：
  - PreferNoSchedule：较宽松的污点效果。若一个节点有 PreferNoSchedule 效果的污点，Kubernetes 会尽量避免将没有相应容忍度的 Pod 调度到该节点上。但是，如果集群中没有其他更合适的节点，Kubernetes 仍然可能将 Pod 调度到有 PreferNoSchedule 污点的节点上。
  - NoSchedule：较严格的污点效果，若一个节点有 NoSchedule 效果的污点，那么任何没有相应容忍度（Toleration）的 Pod 都不会被调度到该节点上。
  - NoExecute：最严格的污点效果，若一个节点添加了 NoExecute 效果的污点，那么所有没有相应容忍度的 Pod 将会被驱逐出该节点，即使它们已经在节点上运行
yaml文件示例

apiVersion: v1
kind: Node
metadata:
  name: my-node
spec:
  taints:
  - key: "key1"
    value: "value1"
    effect: "NoSchedule"
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoSchedule"

亲和力

基本概述
- 定义：亲和力是一种高级调度参数，能够确保 Pod 能够被调度到最适合的节点上，从而提高整个集群的性能和资源利用率
- 作用
  - 负载均衡：通过节点亲和性将特定类型的 Pod 调度到具有特定硬件资源的节点上，以平衡不同类型的负载。
  - 资源优化：确保 Pod 能够被调度到最适合的节点上，从而提高整个集群的性能和资源利用率。
  - 高可用性：通过反亲和性确保关键服务的 Pod 分布在不同的节点上，以减少单点故障的影响
- 原理
  - 节点选择器：亲和力使用节点选择器来匹配节点的标签，从而决定 Pod 是否应该被调度到特定节点上。
  - 拓扑亲和性：拓扑亲和性允许你基于节点的物理位置（如节点所在的区域、区域或机架）来调度 Pod。
  - Pod 亲和性规则：这些规则定义了 Pod 应该如何与同一命名空间中的其他 Pod 相互关联。
分类
- 节点亲和性（Node Affinity）：节点亲和性允许用户指定 Pod 只能调度到具有特定标签的节点上。
  - 硬亲和性（Required During Scheduling Ignored During Execution）：这是一种强制约束，意味着在 Pod 调度时，必须满足指定的节点条件，否则 Pod 将无法被调度。
  - 软亲和性（Preferred During Scheduling Ignored During Execution）：这是一种优先级建议，表示在满足其他调度条件的前提下，优先将 Pod 调度到符合指定条件的节点上，但并非强制要求。
- Pod 亲和性（Pod Affinity）：Pod 亲和性允许用户指定 Pod 应该与哪些其他 Pod 在同一节点上运行，或者与哪些其他 Pod 在不同的节点上运行。

六、认证与授权

认证

Kubernetes API 请求从发起到持久化到ETCD数据库中的过程
- Authentication（身份验证）：验证用户是否具有合法的身份访问api-server，预防未授权的访问和安全威胁。
- Authorization（权限验证）：划定实体可以访问那些资源，并对资源进行那些操作
- Admission Control（准入控制）：在资源对象被持久化之前执行的一系列策略检查，防止不合规的资源对象影响集群的稳定性和安全性
主要由Role、ClusterRole、RoleBinding 和 ClusterRoleBinding 等资源实现

六、Helm包管理器

Helm架构

基本概述
- 定义：帮助用户更方便地管理 Kubernetes 应用的部署和配置的K8s包管理器，避免使用kubectl apply繁琐的依次部署
- 作用
  - 简化部署：Helm允许使用单个命令轻松部署和管理应用程序，从而简化了整个部署过程
  - 共享和复用：开发人员可以创建和分享 Helm Chart，个人也可从 Helm 仓库中获取其他人创建的 Chart，快速部署常见的应用。
  - 多版本管理：能够管理应用程序的多个版本，从而轻松实现版本控制和回滚等操作
  - 模板化：Helm Charts使用YAML模板来定义K8s对象的配置，更容易地进行复用和扩展
  - Helm 仓库：存储 Helm charts 的Repository，可以轻松实现
  - 插件系统：Helm拥有一个强大的插件系统，允许您扩展和定制Helm的功能，以满足特定的需求和要求。