16、Kubernetes存储与集群管理全解析-优快云博客

本文链接：https://blog.youkuaiyun.com/dapp9builder/article/details/152507744

Kubernetes存储与集群管理全解析

1. Kubernetes中的Secret操作

在Kubernetes里，Secret是一种用于存储敏感信息的对象，下面介绍几种创建和使用Secret的方法。

1.1 Base64解码Secret

若要对存储在Secret中的密码键值进行Base64解码，可使用 base64 --decode 命令。例如，解码名为 ha-secret 的Secret中 ha-password 的值，可执行以下命令：

kubectl get secret ha-secret -o jsonpath='{.data.ha-password}' | base64 --decode

1.2 指定文字值创建Secret

使用 kubectl create secret 命令可以创建Secret，示例如下：

kubectl create secret generic ha-secret --from-literal=ha-username=user1 --from-literal=ha-password=user1password1

若要查看解码后的用户名和密码，可执行以下命令：

s1="$(kubectl get secret ha-secret -o jsonpath='{.data.ha-username}' | base64 --decode)"
s2="$(kubectl get secret ha-secret -o jsonpath='{.data.ha-password}' | base64 --decode)"
echo "$s1"
echo "$s2"

1.3 从简单文件创建Secret

可以使用简单的 .txt 文件来创建Secret。首先创建文件，示例命令如下：

echo -n 'user1' > ./username.txt
echo -n 'user1password1' > ./password.txt

然后使用这些文件创建Secret：

kubectl create secret generic ha-secret-file --from-file=username.txt --from-file=password.txt

查看Secret信息：

kubectl get secret
kubectl describe secret ha-secret-file

1.4 从配置/规格文件创建Secret

以下是一个Secret对象的模板：

apiVersion: v1
kind: Secret
metadata:
  name: ha-secret-spec
data:
  ha-username: dXNlcjE=
  ha-password: dXNlcjFwYXNzd29yZDE=
type: Opaque

各字段说明如下：
- kind ：指定Kubernetes对象的类型，这里是Secret。
- metadata.name ：指定该对象的名称，这里是 ha-secret-spec 。
- metadata.data ：指定密钥值对的秘密数据，值应为Base64编码形式。
- metadata.type ：指定Secret对象的类型，这里是 Opaque ，表示可以存储任意数据，默认值也是 Opaque 。

需注意， metadata.data 字段中键值对的“值”必须是Base64编码形式，否则对象创建会失败。

1.5 在Pod中使用Secret

在容器中使用Secret数据主要有两种方法：
- 用Secret数据填充容器环境变量。
- 用Secret数据填充卷。

1.5.1 用Secret数据填充容器环境变量

以下是一个从Secret加载特定键值对的Pod对象示例：

apiVersion: v1
kind: Pod
metadata:
  name: ha-secret-pod
spec:
  containers:
  - name: ha-secret-pod-c-1
    image: nginx:1.10.1
    command: [ "/bin/sh", "-c", "echo Hello, $HA_USERNAME!" ]
    env:
    - name: HA_USERNAME
      valueFrom:
        secretKeyRef:
          name: ha-secret-spec
          key: ha-username

操作步骤如下：
1. 使用 spec.containers.env.valueFrom.secretKeyRef.name 字段指定Secret对象的名称。
2. 使用 spec.containers.env.valueFrom.secretKeyRef.key 字段指定Secret对象的键。
3. 使用 spec.containers.env.name 字段将Secret键绑定到Pod中的环境变量。

查看Secret和Pod日志：

kubectl get secret
kubectl logs ha-secret-pod -c ha-secret-pod-c-1

若要一次性加载Secret对象中的所有键值对，可创建如下Pod：

apiVersion: v1
kind: Pod
metadata:
  name: ha-secret-all-pod
spec:
  containers:
  - name: ha-secret-all-pod-c-1
    image: nginx:1.10.1
    command: [ "/bin/sh", "-c", "echo Hello, $username! Your password is $password." ]
    envFrom:
    - secretRef:
        name: ha-secret-all

创建新的Secret：

kubectl create secret generic ha-secret-all --from-literal=username=user1 --from-literal=password=user1password1

查看Secret和Pod日志：

kubectl get secret
kubectl logs ha-secret-all-pod -c ha-secret-all-pod-c-1

1.6 ConfigMap与Secret的区别

ConfigMap用于以纯文本形式存储配置数据，因此不应用于存储机密数据；而Secret以Base64编码形式存储配置数据，可用于存储机密数据。

2. Kubernetes中的存储类型

Kubernetes中有两种类型的卷：临时卷和持久卷。

2.1 临时卷

临时卷可用于存储能承受Pod和容器重启的数据和文件。它随Pod的创建而创建，随Pod的删除/重启而销毁。临时卷有四种类型： emptyDir 、 downwardAPI 、CSI临时卷和通用临时卷。

2.2 持久卷

持久卷为Kubernetes工作负载资源提供了持久的存储选项。存储在持久卷中的所有数据和文件可以在Pod和容器的删除和重启后存活。 PersistentVolume 和 PersistentVolumeClaim 是用于将卷/存储附加到Kubernetes工作负载资源的Kubernetes对象。 PersistentVolume 代表实际的存储，而 PersistentVolumeClaim 代表对存储的声明或请求。

3. Kubernetes集群的高效管理与监控

接下来将介绍如何使用探针、资源管理以及污点和容忍度来高效管理和监控Kubernetes集群。

3.1 探针：容器健康检查

探针是kubelet根据配置的探针执行的例行容器健康检查。可通过直接在容器中执行命令或向容器发送探针请求来执行探针。

探针有三种可能的结果：
- 成功：容器的所有健康检查都通过。
- 失败：容器的一个或多个健康检查失败。
- 未知：健康检查的结果未知，kubelet将进行进一步的健康检查。

探针有三种类型：
- 存活探针（Liveness Probe） ：用于检查容器是否正在运行。如果存活探针失败，kubelet将杀死容器，是否创建新容器取决于Pod规范的 spec.restartPolicy 字段。若容器内的进程能自行崩溃而不是进入死锁或挂起状态，则不需要存活探针来杀死和重启容器。存活探针的默认结果是成功。
- 就绪探针（Readiness Probe） ：用于检查容器是否准备好接受传入请求。如果就绪探针失败，服务对象的端点将更新以移除该Pod端点。若要确保Pod仅在准备好接受传入流量时才接收流量，可配置就绪探针。
- 启动探针（Startup Probe） ：用于检查容器内的应用程序是否已完全加载。如果启动探针失败，kubelet将杀死容器，是否创建新容器取决于Pod规范的 spec.restartPolicy 字段。当应用程序启动时间较长时，应考虑配置启动探针。若同时配置了所有探针（存活、就绪和启动），则在启动探针成功之前，存活和就绪探针不会启动。

3.2 探针的重要配置参数

以下是适用于所有三种探针的重要配置参数：
- 初始延迟（Initial Delay） ： initialDelaySeconds 字段定义初始延迟，可配置探针在发送第一个探针请求之前应等待的时间，默认和最小值为0秒。
- 探针周期（Probe Period） ： periodSeconds 字段定义探针周期，可配置探针再次发送的时间间隔，默认值为10秒。
- 探针超时（Probe Timeout） ： timeoutSeconds 字段定义探针超时，可配置探针在自动超时之前应等待的时间，默认和最小值为1秒。
- 成功阈值（Success Threshold） ： successThreshold 字段定义探针的成功阈值，可配置探针连续成功的次数以标记探针为成功，默认和最小值为1。
- 失败阈值（Failure Threshold） ： failureThreshold 字段定义探针的失败阈值，可配置探针连续失败的次数以标记容器不健康，并在存活或启动探针的情况下重启容器。
- 终止宽限期（Termination Grace Period） ： terminationGracePeriodSeconds 字段定义kubelet在通知容器运行时停止容器之前应等待的时间，默认值为1分钟或从Pod规范的 terminationGracePeriodSeconds 字段继承的值。在Kubernetes 1.25中，该字段可在Pod和探针规范中定义，若两者都定义，则探针规范的值优先。

3.3 创建exec存活探针

以下是一个使用exec机制创建存活探针的示例：

apiVersion: v1
kind: Pod
metadata:
  name: ha-liveness-exec-pod
spec:
  containers:
  - name: ha-liveness-exec-pod-c-1
    image: nginx:1.10.1
    command: [ "/bin/sh", "-c", "touch /tmp/liveness; sleep 150; rm -f /tmp/liveness; sleep 600" ]
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/liveness
      initialDelaySeconds: 120
      periodSeconds: 50

各字段说明如下：
- spec.containers.livenessProbe ：用于指定存活探针的详细信息。
- spec.containers.livenessProbe.exec.command ：指定作为探针一部分需要执行的命令，该命令在容器内部执行。
- spec.containers.livenessProbe.initialDelaySeconds ：指定发送第一个探针请求之前的初始延迟，这里是120秒。
- spec.containers.livenessProbe.periodSeconds ：指定探针再次发送的时间间隔，这里是50秒。

容器命令解释如下：
| 命令 | 解释 |
| — | — |
| touch /tmp/liveness; | 在 /tmp 目录中创建一个名为 liveness 的文件 |
| sleep 150; | 睡眠150秒 |
| rm -f /tmp/liveness; | 删除 /tmp 目录中名为 liveness 的文件 |
| sleep 600 | 睡眠600秒 |

由于指定了在发送第一个探针请求之前等待120秒，此时 sleep 150; 命令仍在生效， rm -f /tmp/liveness; 尚未执行，因此第一个探针请求（将执行 cat /tmp/liveness 命令）将通过。

Kubernetes存储与集群管理全解析

4. 资源管理

在Kubernetes中，有三种主要的资源管理方式：请求、限制和配额。

4.1 请求与限制

请求（Requests）和限制（Limits）用于管理容器使用的资源。
- 请求（Requests） ：是容器运行所需的最小资源量。Kubernetes调度器在调度Pod时，会根据请求的资源量来选择合适的节点。例如，一个容器请求了1个CPU核心和512MB内存，调度器会寻找有足够可用资源的节点来运行该Pod。
- 限制（Limits） ：是容器可以使用的最大资源量。如果容器尝试使用超过限制的资源，Kubernetes会根据资源类型采取不同的措施。对于CPU资源，容器可能会被限制使用的CPU时间；对于内存资源，容器可能会被杀死。

以下是一个在Pod中设置请求和限制的示例：

apiVersion: v1
kind: Pod
metadata:
  name: resource-pod
spec:
  containers:
  - name: resource-container
    image: nginx:1.10.1
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

在这个示例中，容器请求了64MB内存和0.25个CPU核心，限制为128MB内存和0.5个CPU核心。

4.2 资源配额（ResourceQuota）

资源配额用于限制命名空间（Namespace）内的资源使用。通过设置资源配额，可以确保一个命名空间内的所有Pod不会过度消耗集群资源。

以下是一个创建资源配额的示例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-quota
spec:
  hard:
    pods: "10"
    requests.cpu: "2"
    requests.memory: "2Gi"
    limits.cpu: "4"
    limits.memory: "4Gi"

在这个示例中，命名空间内最多可以创建10个Pod，所有Pod的CPU请求总量不能超过2个核心，内存请求总量不能超过2GB，CPU限制总量不能超过4个核心，内存限制总量不能超过4GB。

4.3 限制范围（LimitRange）

限制范围用于为命名空间内的容器设置默认的请求和限制值。如果一个容器没有明确指定请求和限制，Kubernetes会使用限制范围中定义的默认值。

以下是一个创建限制范围的示例：

apiVersion: v1
kind: LimitRange
metadata:
  name: namespace-limit-range
spec:
  limits:
  - default:
      memory: "256Mi"
      cpu: "500m"
    defaultRequest:
      memory: "128Mi"
      cpu: "250m"
    type: Container

在这个示例中，命名空间内的容器如果没有指定请求和限制，默认请求为128MB内存和0.25个CPU核心，默认限制为256MB内存和0.5个CPU核心。

5. 污点和容忍度

污点（Taints）和容忍度（Tolerations）是一种确保只有特定Pod可以调度到特定节点的机制。

5.1 污点

污点是应用于节点的一种属性，用于排斥某些Pod。可以使用 kubectl taint 命令为节点添加污点。

以下是一个为节点添加污点的示例：

kubectl taint nodes node1 key=value:NoSchedule

在这个示例中，为节点 node1 添加了一个污点，键为 key ，值为 value ，效果为 NoSchedule ，表示新的Pod将不会被调度到该节点，除非Pod有相应的容忍度。

5.2 容忍度

容忍度是Pod的一种属性，用于允许Pod调度到带有特定污点的节点。在Pod的规范中可以定义容忍度。

以下是一个在Pod中定义容忍度的示例：

apiVersion: v1
kind: Pod
metadata:
  name: toleration-pod
spec:
  containers:
  - name: toleration-container
    image: nginx:1.10.1
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"

在这个示例中，Pod定义了一个容忍度，允许它调度到带有 key=value:NoSchedule 污点的节点。

6. 总结

Kubernetes提供了丰富的功能来管理存储、监控容器健康和管理资源。
- 存储方面 ：通过Secret和ConfigMap可以安全地存储和使用配置数据，临时卷和持久卷满足了不同的数据存储需求。
- 健康检查方面 ：存活探针、就绪探针和启动探针确保了容器和应用程序的健康运行。
- 资源管理方面 ：请求、限制、资源配额和限制范围可以有效地管理集群资源，避免资源过度使用。
- 调度方面 ：污点和容忍度机制使得Pod的调度更加灵活和可控。

通过合理使用这些功能，可以构建出高效、稳定的Kubernetes集群，满足不同应用场景的需求。在实际应用中，需要根据具体的业务需求和集群环境，灵活配置和调整这些功能，以达到最佳的性能和可靠性。

下面是一个简单的mermaid流程图，展示了Kubernetes集群管理的主要流程：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(创建Secret和ConfigMap):::process --> B(创建Pod和Deployment):::process
    B --> C(设置探针进行健康检查):::process
    C --> D(使用请求和限制管理资源):::process
    D --> E(设置资源配额和限制范围):::process
    E --> F(使用污点和容忍度调度Pod):::process

这个流程图展示了从创建存储对象到进行健康检查、资源管理和Pod调度的主要步骤，帮助我们更好地理解Kubernetes集群管理的整体流程。