kubernetes 学习笔记

K8s

集群组件

控制面组件（Master节点）

通过 kubectl 或 dashboard 访问 apiserver（入口）

• kube-apiserver：提供 k8s 的访问接口。
• kube-controller-manager：负责管理控制器进程。
  • 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应。
  • 任务控制器（Job Controller）：检测代表一次性任务的 Job 对象，然后创建 Pod 来运行这些任务直至完成。
  • 端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象，提供 service 与 pod 之间的链接。
  • 服务账号控制器（ServiceAccount controller）：为新的 namespace 创建默认的服务账号。
• cloud-controller-manager：与第三方云平台提供的控制器 api 对接。
• kube-scheduler：将 pod 调度到更合适的节点。
• etcd：k8s 数据库。

普通节点（Node）

通过 apiserver 访问和管理 node，最终管理到 pod。

• kubelet
  • 是 k8s 集群中每个节点上的主要代理程序，与主控节点（Master）通信，负责管理节点上的容器和容器组。
  • kubelet 会监视分配给节点的 Pod，确保它们处于运行状态，并与其他组件协调容器的创建、启动、停止和删除操作。
• kube-proxy
  • 网络代理，运行在每个节点上，提供网络代理和负载均衡。
  • 通过在节点上的 IPTables 规则或网络层代理实现服务发现和负载均衡，将入站的服务请求转发到相应的 Pod。
• container-runtime
  • 在节点上负责运行和管理容器的软件，包括 Docker、containerd、CRI-O (Container Runtime Interface)等。
  • 负责下载镜像、创建和管理容器、处理容器的生命周期等。

Pod 生命周期

三种探针

1. Startup 探针： Startup 探针用于检测容器是否已经成功启动，它检测的是容器初始化阶段的健康状态。如果 Startup 探针失败，Kubernetes 将认为容器启动失败并进行相应的处理。
2. Readiness 探针： Readiness 探针用于检测容器是否准备好接收用户请求流量，即容器是否处于可服务请求的状态。如果 Readiness 探针失败，Kubernetes 将不会将流量转发给该容器，直到它变为可服务状态。
3. Liveness 探针： Liveness 探针用于检测容器是否仍然处于运行状态。它用于判断容器是否崩溃或进入了无响应状态。如果 Liveness 探针失败，Kubernetes 将重新启动容器或采取其他恢复措施。

apiVersion: v1
kind: Pod
metadata:
  name: probe-pod
spec:
  containers:
  - name: my-container
    image: my-image
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        # 使用 HTTP GET 请求路径 /healthz 和端口 8080 来检测容器的存活状态。
        path: /healthz 
        port: 8080
    readinessProbe:
      httpGet:
	    # 使用 HTTP GET 请求路径 /ready 和端口 8080 来检测容器的就绪状态。我们还设置了初始延迟时间为 10 秒，每隔 5 秒进行一次检测。
        path: /ready
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
    startupProbe:
      # 使用 TCP Socket 检测端口 8080 的可用性来判断容器的启动状态。我们设置了失败阈值为 30，每隔 10 秒进行一次检测。
      tcpSocket:
        port: 8080
      failureThreshold: 30
      periodSeconds: 10

pause 容器

• pause容器在 Pod 中的作用是实现进程间通信（Inter-process Communication，IPC）和共享网络命名空间（Network Namespace）。
• 当一个 Pod 被创建时，Kubernetes 会为每个容器创建一个独立的网络命名空间，使得每个容器拥有自己的网络栈。这意味着每个容器都有自己的 IP 地址、网络设备和路由表。为了实现 Pod 中不同容器之间的通信，Kubernetes 引入了 “pause” 容器。

postStart 和 preStop 处理函数

postStart 最好使用 InitC 替代。

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]

K8s 控制器

1. Deployment：适合无状态的服务部署
2. StatefullSet：适合有状态的服务部署
3. DaemonSet：一次部署，所有的node节点都会部署，例如一些典型的应用场景：
4. Job：一次性的执行任务
5. Cronjob：周期性的执行任务

Deployment（无状态应用）

Deployment控制器建立在ReplicaSet控制器之上，提供了一种声明性方式来管理Pod的部署。
Deployment控制器允许您指定应用程序的期望状态，包括副本数量、容器镜像版本等，并自动协调ReplicaSet的创建、更新和删除，以确保应用程序的无缝部署和滚动更新。

deployment 用于管理 RS (Replication Set)，而RS进行管理 pod。
修改副本数为3，即多创建至 3 个 pod，RS仍然是 1 个（管理着 3 个 pod），不会触发滚动更新，修改 pod 模板才会触发滚动更新。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

kubectl rollout status deployment nginx-deploy：查看nginx-deploy的更新状态。

kubectl edit deployment nginx-deploy
kubectl set image deployment/nginx-deploy nginx=nginx:1.9.1 --record (记录改变comment)
：修改 nginx-deploy 的配置（pod template）。

滚动更新

创建新的 RS，创建一个新的 pod，关闭一个旧的 pod，最后更新完以新的 RS 取代旧的 RS。
滚动更新并行（如果更新的频繁）：（会导致抛弃第一次的更新被抛弃）。
通过RS作为关联（更新或回滚）

updateStrategy（更新策略）

updateStrategy:
  type: Ondelete # 当删除pod后，才更新
# 原为RollingUpdate
updateStrategy:
  rollingUpdate:
    partition: 0
  type: RollingUpdate

回滚

查看更新历史：kubectl rollout history deployment/nginx-deploy
查看具体更新：kubectl rollout history deployment/nginx-deploy --revision=2(第二次更新)
回退版本：kubectl rollout undo deployment/nginx-deploy --to-revision=2(重启之前的RS，回退到第二次更新)
保留多少历史版本 (RS)：.spec.revisionHistoryLimit

扩容缩容

kubectl scale --replicas=6 deploy nginx-deploy：不会改变RS数量，扩缩 pod。

更新的暂停和恢复

想要改变多次 template，又不想更新多次的情况下。

kubectl rollout pause deploy nginx-deploy：暂停滚动更新。
kubectl rollout resume deploy nginx-deploy：恢复滚动更新，并将暂停时的更改进行更新，即创建新RS进行更新。

StatefulSet（有状态应用）

StatefulSet控制器用于管理有状态应用程序的部署。与ReplicaSet控制器不同，StatefulSet控制器为每个Pod分配一个唯一的标识符，例如Pod名称或索引。这对于有状态应用程序非常重要，因为它们通常依赖于稳定的网络标识和持久化存储。
StatefulSet 提供了一种方式来部署和管理需要唯一标识和稳定网络标识的 Pod 集合。

有序的。
有状态应用依赖网络环境（通过service管理）以及本地存储环境（挂载持久卷）。

通过 Kubernetes 的 Headless Service 来实现为 StatefulSet 的每个 pod 分配唯一的网络标识，为每个 pod 提供一个稳定的 DNS 名称。这样，每个 Pod 都可以使用自己的 DNS 名称来进行通信，实现了稳定的网络标识。

• Pod 0: my-statefulset-0
• Pod 1: my-statefulset-1
• Pod 2: my-statefulset-2

kubectl get pvc：查看持久卷。
kubectl scale statefulset web --replicas=4：扩容 statefulSet下的pod（有顺序 ）。

灰度发布/金丝雀发布

小规模测试，一步一步更新完全部。
partition（分区）：更新大于等于该值的pod，不更新小于该值的pod。

删除sts(有pvc，svc都要额外删)

级联删除（删除sts和pod）：
kubectl delete sts web
非级联删除（只删除sts）：
kubectl delete sts web --cascade=false

工具镜像

用于测试容器之间的功能。

kubectl run -it --image busybox dns-test --restart=Never --rm /bin/sh：运行busybox并执行其中的sh。可以 ping 其它容器进行测试。

DaemonSet

DaemonSet控制器用于确保集群中的每个节点都运行一个Pod副本。它适用于运行一些系统级别的守护进程或日志收集器，这些进程需要在每个节点上运行。

当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

kubectl label node k8s-node1 type=microservices：为 node 加标签。

通过 nodeSelector 筛选 node，并且自动调度并在对应节点上启动 DaemonSet 进程（如记录log），如果配置文件中没有 nodeSelector，则部署到所有 node。
并实时监听节点的标签变化，如有对应标签，则自动部署DaemonSet。

DaemonSet 会关联与本身有相同标签的 pod，并管理它们。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: my-daemonset
  labels:
    app: my-app
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      nodeSelector:
        disktype: ssd
      containers:
        - name: my-container
          image: my-image:latest

Job

主要用于负责批量处理（一次要处理指定数量任务）短暂的一次性（每个任务仅运行一次就结束）任务。

apiVersion: batch/v1
kind: Job
metadata:
  name: my-job
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: my-job-container
        image: your-container-image
        command: ["your-command"]
      # 指定它是一个有计数完成模式的 Job，表示 Job 只需要完成指定数量的任务，而不是等待所有 Pod 都成功完成。
      completionMode: "IndexedCount"
      # 指定要运行的任务（Pod）的数量。
      completions: 1

HPA(Horizontal Pod Autoscaler)

根据应用程序的负载自动调整 Pod 的副本数量。它基于资源利用率（如 CPU 使用率、内存使用率）来动态地扩展或缩减 Pod 的数量，以满足应用程序的性能需求。
或者根据自定义指标（metrics）对Pod 自动扩/缩容，默认每30s检测一次。

kubectl get hpa：查看使用率。

kubectl autoscale deploy nginx-deploy --cpu-percent=20 --min=2 --max=5：配置自动扩容/缩容。

上述命令在cpu超过80%，自动扩容，最多扩容至10个；低于80%，则自动缩容，最少2个。

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 80

Service

service可以看作是一组提供相同的pod对外的访问接口，即通过 Service 访问各个 pod。

服务发现是指在Kubernetes集群中，应用程序可以自动发现和访问其他应用程序的能力。当应用程序在集群中创建或删除时，服务发现机制会自动更新应用程序之间的连接信息，以确保它们可以相互通信。（用户服务、商品服务、订单服务）

负载均衡是将传入的请求在多个应用程序实例之间均匀分配的过程。负载均衡有助于确保每个实例都可以处理适当数量的请求，防止单个实例过载而导致性能下降。（提供实时视频。通过负载均衡，流量可以均匀地分配给多个应用程序实例，每个实例只处理一部分请求。）

跨节点访问流程，service 访问内部服务

service 通过 selector 和 pod 建立关联（通过 selector 筛选出对应 pod，记录 pod ip）。
endpoint 包含 service 关联到 pod 的 podIP 信息。
node2 中的 pod 可以通过 service 访问到 node1 的 pod，反之亦然。
使用虚拟网络和核心组件 kube-proxy 实现了不同节点下 Pod 之间的通信。

1. Service 用于将一组具有相同功能的 Pod 组合在一起，并为它们提供一个稳定的网络入口。Service 为这组 Pod 分配了一个唯一的虚拟 IP 地址，作为它们的入口地址。
2. 当创建一个 Service 并选择特定的 Pod 集合作为后端（通过 selector），K8s 会自动创建一个名为 Endpoint 的对象，它记录了与该 Service 关联的每个后端 Pod 的 IP 地址。
3. 通过 Service，其他的 Pod 或外部客户端可以使用 Service 的虚拟 IP 地址来访问后端 Pod。K8s 会自动处理流量的负载均衡，将请求分发给后端 Pod 中的一个或多个实例。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-container
          image: my-image:latest

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  # 选择具有标签 app: my-app 的 Pod 作为后端
  selector:
    app: my-app
  ports:
    - protocol: TCP
      # Service 监听 TCP 80 端口，并将请求转发到后端 Pod 的端口 8080。
      port: 80
      targetPort: 8080

service -> endpoint -> pod

kubectl 都是通过 api-server 访问内部服务。

service 配置

尽量不要使用 service 暴露 service ，用 ingress 暴露 service。（service 暴露端口的处理方式为O(n)）。

Service 主要针对内部流量提供服务，而不适用于外部流量。

1. 外部访问控制：Service 默认情况下提供了一个 Cluster IP，该 IP 只能在 K8s 集群内部访问。如果将服务暴露给集群外部的请求，需要进行额外的配置。
2. 路由和负载均衡：Service 本身并不提供高级路由规则和负载均衡策略，如果需要更复杂的流量管理和路由控制，Service 的功能可能无法满足需求。

service 只做东西流量的处理，最好不做南北流量的处理。

wget 可以通过 ip tables 直接访问 service 的名字。

通过 service 访问外部服务

1. 编写配置文件不指定 selector
2. 自己创建 endpoint（手动关联 pod，端口名要与service 端口名一致）

apiVersion: v1
kind: Service
metadata:
  name: external-service
spec:
  # ClusterIP：默认类型，为 Service 分配一个仅在集群内部可用的虚拟 IP（Cluster IP），用于内部服务发现和负载均衡。
  type: ExternalName
  externalName: www.baidu.com

内部服务(pod(工具镜像测试)) 访问 service -> service 访问 endpoint -> endpoint 访问到外部服务

k8s service常用类型

• ClusterIP：默认值，是k8s系统给service自动分配的虚拟IP，只能在集群内部访问。
• ExternalNmae：直接访问外部域名，将服务通过DNS Cname记录方式转发到指定的域名（通过spec.externlname设定）
• NodePort：将Service通过指定的Node上的端口暴露给外部，访问任意一个NodeIP：NodePort都将路由到Cluster IP
• LoadBalancer：与NodePort类似，在每个节点上启动一个端口暴露服务。除此之外，kubernetes会请求底层云平台（如阿里云，腾讯云，AWS等）上的负载均衡器，将每个Node（NodeIP:NodePort）作为后端添加进去

Ingress

对南北流量的管理，自上而下，类似于nginx，在 nginx 上抽象而成。（Nginx Ingress Controller）
用于管理集群外部流量的访问和路由。它充当了入口控制器的角色，负责将外部流量路由到集群内部的服务（Service）和后端 Pod。
实现灵活的路由和负载均衡。

1. 外部流量路由：Ingress 允许你在 Kubernetes 集群外部配置流量路由规则。通过定义 Ingress 规则，你可以将不同的 URL 路径或域名映射到集群内部的不同服务，实现外部流量的路由和负载均衡。
2. 负载均衡：Ingress 可以与负载均衡器（如 Nginx、HAProxy）配合使用，将流量分发到多个后端服务中。它支持多种负载均衡算法，如轮询、IP 哈希、最少连接等，提供高可用性和性能。

Service 和 Ingress 有以下关系：

1. Service 提供了集群内部的服务发现和负载均衡功能，它将一组 Pod 封装在一个虚拟 IP 地址后面。Ingress 利用 Service 的虚拟 IP 地址作为后端服务的目标，将外部流量引导到相应的 Service。

2. Ingress 使用规则来定义外部流量的路由策略，这些规则可以指定访问的路径、主机名和其他匹配条件。通过定义 Ingress 规则，可以将外部流量路由到不同的 Service 或后端 Pod，实现灵活的流量管理和路由控制。

3. Ingress Controller 是负责监听和解析 Ingress 规则的组件，它与 Service Controller 一起工作，将外部流量转发到适当的 Service 或后端 Pod。Ingress Controller 可以利用 Service 的负载均衡功能，将请求分发给后端 Pod 的实例。
   

配置管理

configMap

将多个应用（pod）的配置额外提出来，统一管理。

configMap 创建方法：

# 将path文件夹下的配置文件合并。
kubectl create configmap test-config-name --from-file=path/

# 指定文件创建 configMap，可以提供重命名。
kubectl create cm test-config --from-file=app.yml=/opt/k8s/config/application.yml

# 手动直接添加键值对
kubectl create cm test-config --from-literal=username=root --from-literal=password=admin

将 configMap 加载到容器中：

1. 在 pod 配置文件中定义数据卷，并挂载 configMap，从而将 configMap 中的 key, value 进行映射。

   如果没有配置 volumes.configMap.items，则会将 name 对应的 configMap 中的所有文件都加载，否则只加载指定的文件。

2. 在 pod 的 containers.volumeMounts 中指定要加载的数据卷，并可以指定将对应数据卷中的文件加载到哪个目录下。

如果在 ConfigMap 中进行更改，Pod 将会自动检测到更改，并重新加载更新后的配置 (依赖更新策略)。

Secret

1. 类似 configMap，主要用于存储敏感信息、需要加密的信息，提供了数据加密、解密的功能（基础加密，基于base64）
2. 有特殊字符的话需要使用单引号。

# 通过字面量创建 secret
kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secretpassword

在 Pod 的卷配置中指定将 Secret 挂载为文件。这样，Secret 中的数据将以文件的形式出现在 Pod 的文件系统中，应用程序可以从这些文件中读取敏感数据。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: my-image
      volumeMounts:
        - name: secret-volume
          mountPath: /etc/secret
  volumes:
    - name: secret-volume
      secret:
        secretName: my-secret

secret 类型：

• docker-registry：用于在 Kubernetes 中与私有 Docker Registry 进行身份验证和拉取镜像，在spec.imagePullSecrets中配置 secret。
  
• generic：(基于base64)
• tls：用于存储 TLS 证书和私钥，以供 Ingress 或其他需要 SSL/TLS 加密的资源使用。

# 基于docker-registry
kubectl create secret docker-registry my-registry-secret --docker-server=my-registry.example.com --docker-username=username --docker-password=password --docker-email=email@example.com

# 基于generic
kubectl create secret generic user --from-literal=username=admin --from-literal=password=1f2d1e2e67df

# 基于tls，创建了一个名为 `my-tls-secret` 的 TLS Secret。它使用 `--cert` 和 `--key` 标志分别指定了证书和私钥文件的路径。
kubectl create secret tls my-tls-secret --cert=path/to/certificate.crt --key=path/to/privatekey.key

SubPath

用途是将configMap和secret作为文件挂载到容器中而不覆盖挂载目录下的文件。

1. volumes 中的path不能以 ‘/‘ 开始。
2. 在 volumeMounts 中增加 subPath，与 volumes 的 path 相同。

volumeMounts.mountPath的目录是将 configMap 的所有项映射到该目录下。

配置 SubPath 之前：

配置 SubPath 之后：

配置热更新

在更新挂载到 pod 中的 configMap 的同时，也会更新 pod 中的配置。

1. 默认方式：会更新，更新周期是更新时间+缓存时间。
2. SubPath：不会更新。（可以通过软链接间接更新，在 pod 生命周期的初始化阶段进行。）
3. pod 中的一个变量是从 configMap 或 secret中得到的（如从configMap中得到，并将其设置为 pod 的环境变量的方式），不会更新。

# 1. 直接edit configMap 来更新
kubectl edit configMap test-config

# 2. 通过 replace 替换，将一个新的配置文件替换旧的配置文件
kubectl create cm test-config --from-file=./test/ --dry-run -o yaml | kubectl replace -f-
# 上述命令中的 ./test/ 是获取该目录下的 yaml 文件作为替换的文件。
# --dry-run:把该配置文件创建出来但不会发给 apiServer。
# -f-：第二个 - 的作用是将控制台的输出作为输入。

禁止配置更新：在配置文件中加：immutable: true，为了线上环境的稳定性。（只能创建新 configMap）

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-configmap
  labels:
    app: my-app
data:
  key1: value1
  key2: value2
immutable: true

持久化存储

存储方案：

HostPath 和 EmptyDir 依赖于本机实现。
NFS 依赖于网络实现。

HostPath

将主机（node）目录挂载到容器中，即共享。

hostPath:
  path: # node 目录
  type: # 检查类型，目录是否创建？不存在是否自动创建？

EmptyDir

用于 pod 下的容器之间共享目录。
非持久性存储，pod 被删除，目录也将被删除

volumes:
- name: cache-volume
  emptyDir: {} # 代表不提供文件，仅提供一个空目录

NFS 挂载

NFS 网络文件系统，pod 被删除，虽然卷被卸载，但数据被保存。
NFS 存储的功能，使得多个 Pod 可以共享同一个 NFS 文件系统，从而实现数据的持久化和共享。

1. node 之间共享目录
2. 可设置目录中的文件权限（只读或读写等）

如何在k8s配置 NFS ：

1. 配置 NFS 服务器

2. 创建 NFS PersistentVolume (创建 PV 时，需要指定 NFS 服务器的地址、共享目录的路径以及其他相关的配置。)

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: nfs-pv
   spec:
     capacity:
       storage: 10Gi
     accessModes:
       - ReadWriteMany
     nfs:
       server: <nfs-server-ip>
       path: /path/to/shared/folder

3. 创建 PersistentVolumeClaim（创建 PVC 来请求和使用 PV）

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: nfs-pvc
   spec:
     accessModes:
       - ReadWriteMany
     resources:
       requests:
         storage: 5Gi

4. 在 Pod 中挂载 NFS 存储

   apiVersion: v1
   kind: Pod
   metadata:
     name: nfs-pod
   spec:
     containers:
       - name: my-container
         image: nginx
         volumeMounts:
           - name: nfs-volume
             mountPath: /mnt/data
     volumes:
       - name: nfs-volume
         persistentVolumeClaim:
           claimName: nfs-pvc

创建多个 pod 即可实现容器间的目录共享（有 NFS 的 node 的目录）

• 修改目录中的文件，实时更新
• 删除 pod，文件依旧在
• 缺点：效率低

PV (PersistentVolume)和PVC (PersistentVolumeClaim)

传统存储方案：

每个服务器都要安装存储相关的依赖，不够统一。

PV 与 PVC 存储方案：

Pod -> PVC -> PV：pod 与 pvc 绑定，pvc 找到相应的 pv。

PV、PVC 生命周期：

1. 构建（制备）：
   1. 静态构建：先行创建 PV，等待用户使用。
   2. 动态构建：已有 PV 不满足需求，则 PVC 通过 StorageClass 构建新的 PV。
2. 绑定：用户创建 PVC，PVC 找到对应 PV（找不到则动态构建），否则一直处于未绑定状态，直到有符合的 PV。
3. 使用：Pod 挂载 PVC 之后，PVC 才会找对应的 PV 绑定，然后可访问 PV 数据。此时无法直接删除 PV 对象。
4. 回收：
   1. Retain（保留）：PVC 被删除时，PV 仍然存在，但状态为 released（已释放），需手动管理。
   2. Delete（删除）（默认）：删除 PV，且将相关联的移除。
   3. Recycle（回收，废弃）：动态制备，不删除 PV 数据，设置为 released 状态，等待被 PVC 重新绑定。

PV 配置

PV状态：

• Available：空闲，未被任何 PVC 绑定
• Bound：已被 PVC 绑定。
• Released：PVC 被删除，但是资源尚未被集群回收。
• Failed：卷自动回收失败，不可被绑定。

accessModes：只能被一个使用、被多个使用等

• RWO - ReadWriteOnce
• ROX - ReadOnlyMany
• RWX - ReadWriteMany
• RWOP - ReadWriteOncePod

PVC 配置

用于匹配 PV：accessModes、volumeMode、storage < PV、storageClassName。
可使用 selector 匹配相应 PV。

Pod 关联 PVC 的配置

persistentVolumeClaim:
  claimName: nfs-pvc # 要绑定的 pvc

通过配置，将 pod 与 pvc 绑定后，则修改被挂载的 nfs 卷的目录或 pod 的挂载的目录会实时更新。

StorageClass

PVC 关联 SC，SC 根据 PVC 的需求动态制备 PV。
通过 Provisioner（制备器）（deployment）选择卷类型。
SC 动态的为 statefulSet（在配置中配置 PVC） 创建PV。

调度

CronJob

类似 Linux 中的 crontab，在 k8s 中周期性运行计划任务。
CronJob 创建 Job -> Job 启动 Pod 执行命令

CronJob 配置

.spec.schedule：调度策略，* 表示任意。

下图配置的 schedule 表示每分钟执行。

InitC（初始化容器）

InitC 是在容器创建完成前创建的执行各种约定功能的容器。

InitC 配置

配置在 pod template 下。
template.spec.initContainers[]

污点（Taint）和容忍（Toleration）

污点（node 上）

例如 master 节点（更重要的任务是控制、管理从节点），或者有特殊任务的 node，避免 pod 分配到含污点的节点上。

master 节点上自带一个污点：node-role.kubernetes.io/master:NoSchedule，因此不包含容忍的 pod 不能被调度到 master 节点上。
同时，如果将 master 节点的该污点去除，pod 则可以被调度到 master 节点上。

not-ready：节点状态，不会将 Pod 部署到该状态的 Node。

污点的 effect (影响)：

• NoSchedule：
  • 不能容忍的 pod 不能被调度到该节点，但是已经存在的节点不会被驱逐。
• NoExecute：
  • 如果 Pod 不能忍受这类污点，Pod 会马上被驱逐。
  • 如果 Pod 能够忍受这类污点，但是在容忍度定义中没有指定 tolerationSeconds， 则 Pod 还会一直在这个节点上运行。
  • 如果 Pod 能够忍受这类污点，而且指定了 tolerationSeconds， 则 Pod 还能在这个节点上继续运行这个指定的时间长度。

# 给 node 添加污点
kubectl taint nodes node1 key1=value1:NoSchedule

# 去除 node 的污点
kubectl taint nodes node1 key1=value1:NoSchedule-

容忍（pod 中）

忽视已有污点的 node，可以将 pod 部署到有污点的 node。

容忍的 operator 配置值：

• Equal
  • 必须与污点值做匹配，key/value都必须相同，才表示能容忍该污点。
• Exists
  • 与污点只比较 key，不比较 value，只要 key 存在，就可以容忍该污点。

容忍的配置（在 pod template下）：

tolerations:
- key: "key1"
  operator: "Equal" # 匹配 key/value
  value: "value1"
  effect: "NoSchedule"

tolerations:
- key: "key1"
  operator: "Exists" # 仅匹配 key
  effect: "NoSchedule"

tolerations.tolerationSeconds 配置：

如果是 NoExecute，没有配置 tolerationSeconds，则一直运行，如果配置了，则运行对应时间被驱逐。

tolerations:
- key: "node.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 6000

亲和力（Affinity）

相比于 nodeSelector 的严格，亲和力表示只需要更接近，可以或不需要完全匹配。

比如：某些 pod 需要存储性能高的，最好部署到 ssd。

操作符（node、pod）	行为
In	标签值存在于提供的字符串集中
NotIn	标签值不包含在提供的字符串集中
Exists	对象上存在具有此键的标签
DoesNotExist	对象上不存在具有此键的标签

操作符（node）	行为
Gt	提供的值将被解析为整数，并且该整数小于等于通过解析此选择算符命名的标签的值所得到的整数
Lt	提供的值将被解析为整数，并且该整数大于等于通过解析此选择算符命名的标签的值所得到的整数

• 节点亲和力（NodeAffinity）

  pod 配置文件中配置要匹配的节点的属性，选择更匹配配置的节点，部署到该节点。

  下面两条配置可以不同时配置。

  • RequiredDuringSchedulingIgnoredDuringExecution

    硬亲和力。必须匹配。

  • PreferredDuringSchedulingIgnoredDuringExecution

    软亲和力。先匹配上面的，这条配置可以匹配也可以不匹配。

  apiVersion: v1
  kind: Pod
  metadata:
    name: with-affinity-anti-affinity
  spec:
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/os
              operator: In
              values:
              - linux
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 1 # 匹配则权重 +1
          preference:
            matchExpressions:
            - key: label-1
              operator: In
              values:
              - key-1
        - weight: 50 # 匹配则权重 +50，最后部署到权重更高的节点
          preference:
            matchExpressions:
            - key: label-2
              operator: In
              values:
              - key-2
    containers:
    - name: with-node-affinity
      image: registry.k8s.io/pause:2.0

• Pod 亲和力（PodAffinity）

  两个 Pod 具有强耦合性，则其中一个 pod 部署在某个节点，另一个 pod 也最好部署在该节点（已存在具有相同标签的 pod）。

  • RequiredDuringSchedulingIgnoredDuringExecution
  • PreferredDuringSchedulingIgnoredDuringExecution

• Pod 反亲和力（PodAntiAffinity）

  Pod 相斥。

  • RequiredDuringSchedulingIgnoredDuringExecution
  • PreferredDuringSchedulingIgnoredDuringExecution

亲和性规则表示，仅当节点和至少一个已运行且有 security=S1 的标签的 Pod 处于同一区域时，才可以将该 Pod 调度到节点上。 更确切的说，调度器必须将 Pod 调度到具有 topology.kubernetes.io/zone=V 标签的节点上，并且集群中至少有一个位于该可用区的节点上运行着带有 security=S1 标签的 Pod。

反亲和性规则表示，如果节点处于 Pod 所在的同一可用区且至少一个 Pod 具有 security=S2 标签，则该 Pod 不应被调度到该节点上。 更确切地说， 如果同一可用区中存在其他运行着带有 security=S2 标签的 Pod 节点， 并且节点具有标签 topology.kubernetes.io/zone=R，Pod 不能被调度到该节点上。

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: topology.kubernetes.io/zone # 调度器必须将 Pod 调度到具有 topology.kubernetes.io/zone=V 标签的节点上
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: topology.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: registry.k8s.io/pause:2.0

Helm

包管理器类似于我们在 Ubuntu 中使用的apt、Centos中使用的yum 或者Python中的 pip 一样，能快速查找、下载和安装软件包。
Helm 管理 chart ，chart 相当于软件安装包。

Helm 常用命令

1. helm install: 用于安装一个 Helm Chart。

   • 示例：helm install my-release ./my-chart

2. helm upgrade: 用于升级一个已安装的 Helm Chart。

   • 示例：helm upgrade my-release ./my-chart

3. helm uninstall: 用于卸载一个已安装的 Helm Chart。

   • 示例：helm uninstall my-release

4. helm list: 列出已安装的 Helm Releases。

   • 示例：helm list

5. helm status: 显示特定 Helm Release 的状态信息。

   • 示例：helm status my-release

6. helm repo add: 添加一个 Helm Chart 仓库。

   • 示例：helm repo add my-repo https://example.com/charts

7. helm repo update: 更新已添加的 Helm Chart 仓库。

   • 示例：helm repo update

8. helm search: 在已添加的 Chart 仓库中搜索 Helm Chart。

   • 示例：helm search repo my-chart

9. helm pull: 下载一个 Helm Chart，但不安装。

   • 示例：helm pull my-repo/my-chart
   • 解压：tar -xvf my-chart

10. helm template: 渲染 Helm Chart 并将其输出为 Kubernetes YAML 文件。

    • 示例：helm template my-release ./my-chart

11. helm create：在本地创建新的 chart。

12. helm dependency：管理 chart 依赖。

13. helm lint：检查 chart 配置是否有误。

14. helm package：打包本地 chart。

15. helm rollback：回滚 release 到历史版本。

Chart 文件组织结构

• Chart.yaml：当前Charts的描述信息，yaml格式的文件。
• LICENSE：当前Charts的许可证信息，纯文本文件；此为可选文件。
• README.md：易读格式的README文件；可选。
• requirements.yaml：当前Charts的依赖关系描述文件；可选。
• values.yaml：当前Charts用到的默认配置值。
• charts/：目录，存放当前Charts依赖到的所有Charts文件。
• templates/：目录，存放当前Charts用到的模板文件，可应用于Charts生成有效的Kuber-netes清单文件。
• templates/NOTES.txt：纯文本文件，Templates简单使用注解
  

chart 的升级与回滚

chart 升级

1. 修改本地 chart 文件夹，比如 redis/
2. helm upgrade redis ./redis：将 redis 应用用 redis/ 进行升级。

chart 回滚

1. helm history redis：查看 redis 历史更新。
2. helm rollback redis 2：回到第二次更新，不加数字则是回到上次。（如果应用不在默认 namespace，则要指定）

chart 删除

1. helm delete redis -n redis：只删除 pod，不删除 pvc。
2. 需要手动删除 pvc，同时自动会将 pv 删除。