Kubernetes on Kang's Blog

昇腾 K8s 环境部署指南

Thu, 08 Jan 2026 00:00:00 +0000

昇腾 K8s 环境部署指南

概述

本文档介绍在 Kubernetes 集群中部署昇腾 NPU 容器化环境的完整流程，适用于以下场景：

容器运行时：Containerd
NPU 设备：Ascend 310P
系统架构：aarch64（ARM64）
Kubernetes 版本：1.28+

部署流程主要包括三个步骤：

环境准备（节点标签、用户、目录）
安装 Ascend Docker Runtime
部署 Ascend Device Plugin

准备工作

创建节点标签

为 Kubernetes 节点添加相应标签，用于后续的 Pod 调度和资源管理。

# 标记主节点
kubectl label nodes ecs-b0tf90001 masterselector=dls-master-node

# 标记 NPU 计算节点
kubectl label nodes ecs-exyqec0002 node-role.kubernetes.io/worker=worker
kubectl label nodes ecs-exyqec0002 workerselector=dls-worker-node
kubectl label nodes ecs-exyqec0002 host-arch=huawei-arm
kubectl label nodes ecs-exyqec0002 accelerator=huawei-Ascend310P

说明：请根据实际节点名称修改 ecs-b0tf90001 和 ecs-exyqec0002。

创建系统用户

在 Ascend 计算节点（如 ecs-exyqec0002）上创建专用用户和用户组。

# 创建 hwMindX 用户（UID 9000）
useradd -d /home/hwMindX -u 9000 -m -s /sbin/nologin hwMindX

# 创建 HwHiAiUser 用户组
groupadd HwHiAiUser

# 将 hwMindX 用户添加到 HwHiAiUser 组
usermod -a -G HwHiAiUser hwMindX

注意：UID 9000 和用户组 HwHiAiUser 是昇腾软件栈的默认配置，请勿随意修改。

创建日志目录

在 Ascend 计算节点上创建 Device Plugin 日志目录。

1
2
3

# 创建日志目录并设置权限
mkdir -m 750 /var/log/mindx-dl/devicePlugin
chown root:root /var/log/mindx-dl/devicePlugin

安装 Ascend Docker Runtime

Ascend Docker Runtime 是容器化环境下使用昇腾 NPU 的核心组件，需要在所有昇腾计算节点上安装。

下载安装包

前往官方 Git 仓库下载对应版本的安装包。

示例：Ascend-docker-runtime_7.2.RC1.SPC2_linux-aarch64.run

安装步骤

步骤 1：进入安装包目录

`1`	`cd <path to run package>`

步骤 2：校验安装包完整性

`1`	`./Ascend-docker-runtime_{version}_linux-{arch}.run --check`

预期输出：

1
2

[WARNING]: --check is meaningless for Ascend-docker-runtime and will be discarded in the future
Verifying archive integrity... All good.

步骤 3：添加可执行权限

`1`	`chmod u+x Ascend-docker-runtime_{version}_linux-{arch}.run`

步骤 4：执行安装

方式一：安装到默认路径（推荐）

`1`	`./Ascend-docker-runtime_{version}_linux-{arch}.run --install`

方式二：安装到自定义路径

`1`	`./Ascend-docker-runtime_{version}_linux-{arch}.run --install --install-path=<path>`

安装成功输出示例：

Uncompressing ascend-docker-runtime  100%
[INFO]: installing ascend docker runtime
...
[INFO] Ascend Docker Runtime install success

默认安装路径：/usr/local/Ascend/Ascend-Docker-Runtime/

配置 Containerd

根据系统使用的 cgroup 版本修改 Containerd 配置文件 /etc/containerd/config.toml。

配置方式一：Cgroup v1

需要修改以下两个关键配置项：

runtime_type = "io.containerd.runtime.v1.linux"
runtime = "/usr/local/Ascend/Ascend-Docker-Runtime/ascend-docker-runtime"

完整配置示例：

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
    runtime_type = "io.containerd.runtime.v1.linux"
    runtime_engine = ""
    runtime_root = ""
    privileged_without_host_devices = false
    base_runtime_spec = ""
    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]

[plugins."io.containerd.grpc.v1.cri".cni]
  bin_dir = "/opt/cni/bin"
  conf_dir = "/etc/cni/net.d"
  max_conf_num = 1
  conf_template = ""

[plugins."io.containerd.grpc.v1.cri".registry]
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
      endpoint = ["https://registry-1.docker.io"]

[plugins."io.containerd.grpc.v1.cri".image_decryption]
  key_model = ""

# ... 其他配置 ...

[plugins."io.containerd.monitor.v1.cgroups"]
  no_prometheus = false

[plugins."io.containerd.runtime.v1.linux"]
  shim = "containerd-shim"
  runtime = "/usr/local/Ascend/Ascend-Docker-Runtime/ascend-docker-runtime"
  runtime_root = ""
  no_shim = false
  shim_debug = false

[plugins."io.containerd.runtime.v2.task"]
  platforms = ["linux/amd64"]

配置方式二：Cgroup v2

需要修改以下关键配置项：

BinaryName = "/usr/local/Ascend/Ascend-Docker-Runtime/ascend-docker-runtime"

完整配置示例：

[plugins."io.containerd.grpc.v1.cri".containerd.default_runtime.options]

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
  [plugins."io.containerd.grpc.v2.cri".containerd.runtimes.runc]
    base_runtime_spec = ""
    cni_conf_dir = ""
    cni_max_conf_num = 0
    container_annotations = []
    pod_annotations = []
    privileged_without_host_devices = false
    runtime_engine = ""
    runtime_path = ""
    runtime_root = ""
    runtime_type = "io.containerd.runc.v2"
    
    [plugins."io.containerd.grpc.v2.cri".containerd.runtimes.runc.options]
      BinaryName = "/usr/local/Ascend/Ascend-Docker-Runtime/ascend-docker-runtime"
      CriuImagePath = ""
      CriuPath = ""
      CriuWorkPath = ""
      IoGid = 0
      IoUid = 0
      NoNewKeyring = false
      NoPivotRoot = false
      Root = ""
      ShimCgroup = ""
      SystemdCgroup = true

提示：查看 cgroup 版本可执行 stat -fc %T /sys/fs/cgroup/，输出 cgroup2fs 表示 v2，输出 tmpfs 表示 v1。

重启服务

1
2

systemctl daemon-reload
systemctl restart containerd kubelet

验证安装

在 Kubernetes 主节点执行以下命令，确认昇腾计算节点状态正常：

`1`	`kubectl get nodes`

预期输出示例：

1
2
3

NAME              STATUS   ROLES           AGE   VERSION
k8s-master        Ready    master,worker   3d    v1.28.12
k8s-worker        Ready    worker          3d    v1.28.12

所有节点状态应显示为 Ready。

部署 Ascend Device Plugin

Ascend Device Plugin 负责在 Kubernetes 中管理和分配 NPU 资源。

准备镜像

1. 拉取镜像

在昇腾计算节点上执行以下命令拉取所需镜像：

# 拉取所有必需镜像
docker pull --platform=arm64 swr.cn-south-1.myhuaweicloud.com/ascendhub/resilience-controller:v7.1.RC1
docker pull --platform=arm64 swr.cn-south-1.myhuaweicloud.com/ascendhub/ascend-operator:v7.2.RC1
docker pull --platform=arm64 swr.cn-south-1.myhuaweicloud.com/ascendhub/npu-exporter:v7.2.RC1
docker pull --platform=arm64 swr.cn-south-1.myhuaweicloud.com/ascendhub/ascend-k8sdeviceplugin:v7.2.RC1
docker pull --platform=arm64 swr.cn-south-1.myhuaweicloud.com/ascendhub/vc-controller-manager:v1.7.0-v7.2.RC1
docker pull --platform=arm64 swr.cn-south-1.myhuaweicloud.com/ascendhub/vc-scheduler:v1.7.0-v7.2.RC1
docker pull --platform=arm64 swr.cn-south-1.myhuaweicloud.com/ascendhub/noded:v7.2.RC1
docker pull --platform=arm64 swr.cn-south-1.myhuaweicloud.com/ascendhub/clusterd:v7.2.RC1

2. 导出镜像

docker save -o ascend.tar \
  swr.cn-south-1.myhuaweicloud.com/ascendhub/resilience-controller:v7.1.RC1 \
  swr.cn-south-1.myhuaweicloud.com/ascendhub/ascend-operator:v7.2.RC1 \
  swr.cn-south-1.myhuaweicloud.com/ascendhub/npu-exporter:v7.2.RC1 \
  swr.cn-south-1.myhuaweicloud.com/ascendhub/ascend-k8sdeviceplugin:v7.2.RC1 \
  swr.cn-south-1.myhuaweicloud.com/ascendhub/vc-controller-manager:v1.7.0-v7.2.RC1 \
  swr.cn-south-1.myhuaweicloud.com/ascendhub/vc-scheduler:v1.7.0-v7.2.RC1 \
  swr.cn-south-1.myhuaweicloud.com/ascendhub/noded:v7.2.RC1 \
  swr.cn-south-1.myhuaweicloud.com/ascendhub/clusterd:v7.2.RC1

3. 导入到 Containerd

`1`	`ctr -n k8s.io images import ascend.tar`

下载部署配置文件

前往官方 Git 仓库下载 Ascend Device Plugin 安装包。

示例：Ascend-mindxdl-device-plugin_7.2.RC1.SPC2_linux-aarch64.zip

解压后将对应的 YAML 文件拷贝到 Kubernetes 管理节点。

选择合适的 YAML 文件

根据实际设备类型和是否使用 Volcano 调度器选择对应的 YAML 文件：

YAML 文件名称	适用场景
`device-plugin-310-v{version}.yaml`	Atlas 300I 推理卡，不使用 Volcano
`device-plugin-310-volcano-v{version}.yaml`	Atlas 300I 推理卡，使用 Volcano
`device-plugin-310P-1usoc-v{version}.yaml`	Atlas 200I SoC A1 核心板，不使用 Volcano
`device-plugin-310P-1usoc-volcano-v{version}.yaml`	Atlas 200I SoC A1 核心板，使用 Volcano
`device-plugin-310P-v{version}.yaml`	Atlas 推理系列产品（如 310P），不使用 Volcano
`device-plugin-310P-volcano-v{version}.yaml`	Atlas 推理系列产品，使用 Volcano
`device-plugin-910-v{version}.yaml`	Atlas 训练系列产品/A2/A3/800I A2，不使用 Volcano
`device-plugin-volcano-v{version}.yaml`	Atlas 训练系列产品/A2/A3/800I A2，使用 Volcano

注意：

对于 Ascend 310P 设备，通常选择 device-plugin-310P-v{version}.yaml

请勿修改 YAML 文件中的 DaemonSet.metadata.name 字段，以免自动识别功能异常

部署 Device Plugin

1
2

# 请修改镜像名称为：swr.cn-south-1.myhuaweicloud.com/ascendhub/ascend-k8sdeviceplugin:v7.2.RC1
kubectl apply -f device-plugin-310P-v7.2.RC1.SPC2.yaml

预期输出：

serviceaccount/ascend-device-plugin-sa created
clusterrole.rbac.authorization.k8s.io/pods-node-ascend-device-plugin-role created
clusterrolebinding.rbac.authorization.k8s.io/pods-node-ascend-device-plugin-rolebinding created
daemonset.apps/ascend-device-plugin-daemonset created

验证部署

查看 Device Plugin 是否启动成功：

`1`	`kubectl get pod -n kube-system \| grep ascend`

预期输出（状态应为 Running）：

1
2

NAME                                   READY   STATUS    RESTARTS   AGE
ascend-device-plugin-daemonset-d5ctz   1/1     Running   0          11s

查看节点 NPU 资源：

`1`	`kubectl describe node <node-name> \| grep -A 5 "Capacity:"`

应能看到 huawei.com/Ascend310P 资源。

使用 NPU 计算卡

Pod 配置示例

在 Pod 定义中通过 resources 字段申请 NPU 资源：

apiVersion: v1
kind: Pod
metadata:
  name: npu-test-pod
spec:
  containers:
    - name: alg-container
      image: ubuntu:22.04
      resources:
        limits:
          memory: 24Gi
          huawei.com/Ascend310P: 1  # 申请 1 张 NPU 卡
        requests:
          memory: 2Gi
          huawei.com/Ascend310P: 1  # 申请 1 张 NPU 卡
      command: ["/bin/bash", "-c", "sleep infinity"]

说明：

huawei.com/Ascend310P 的值表示申请的 NPU 卡数量

limits 和 requests 中的值应保持一致

根据实际 NPU 型号调整资源名称（如 310、910 等）

Helm 核心概念与实践指南

Sat, 18 Jan 2025 00:00:00 +0000

简介

Helm 是一个强大的工具，帮助你管理 Kubernetes 应用程序。通过 Helm Charts，可以定义、安装和升级即使是最复杂的 Kubernetes 应用程序。

Helm Charts 易于创建、版本控制、共享和发布。这意味着你可以更高效地使用 Helm，避免手动复制粘贴配置文件的繁琐过程。

Helm 已成为 CNCF（云原生计算基金会）的毕业项目，并由 Helm 社区持续维护，确保其稳定性和持续发展。

管理复杂性

Helm Charts 可以描述即使是最复杂的应用程序，提供可重复的应用安装流程，并作为应用配置的单一权威来源，确保一致性和可靠性。

轻松更新

使用 Helm，你可以通过原地升级和自定义钩子，轻松管理应用的更新过程，减少因更新带来的困扰。

简单共享

Helm Charts 易于版本控制、共享，并且可以托管在公共或私有服务器上，方便团队协作和应用分发。

回滚

如果更新出现问题，使用 helm rollback 命令可以轻松回滚到之前的发布版本，确保应用的稳定运行。

Helm 的工作原理

结合以上概念，Helm 的工作流程可以这样理解：

安装 Charts： Helm 将 Charts 安装到 Kubernetes 集群中，每次安装都会创建一个新的 Release。
管理 Releases： 每个 Release 独立管理，允许同一个 Chart 被多次部署，满足不同的需求。
查找 Charts： 通过搜索 Helm 的 Chart Repository，可以找到并获取新的 Charts 来部署。

整体图表示意：

+---------------------+          +---------------------+
|    Chart Repository | <------> |        Helm         |
| (存放所有 Charts)    |          | (安装和管理 Charts)   |
+---------------------+          +---------+-----------+
                                         |
                                         v
                               +--------------------+
                               | Kubernetes Cluster |
                               | ------------------ |
                               | Release A          |
                               | Release B          |
                               | ...                |
                               +--------------------+

三个核心概念

Chart（图表）

Chart 是 Helm 的一个包。它包含了在 Kubernetes 集群中运行一个应用、工具或服务所需的所有资源定义。可以将其类比为 Kubernetes 版本的 Homebrew 配方、Apt 的 dpkg 或 Yum 的 RPM 文件。

图表示意：

+-----------------+
| Chart           |
| --------------- |
| Deployment.yaml |
| Service.yaml    |
| ConfigMap.yaml  |
| ...             |
+-----------------+

Helm 会按照一下顺序部署：

Namespace —> NetworkPolicy —> ResourceQuota —> LimitRange —> PodSecurityPolicy —> PodDisruptionBudget —> ServiceAccount —> Secret —> SecretList —> ConfigMap —> StorageClass —> PersistentVolume —> PersistentVolumeClaim —> CustomResourceDefinition —> ClusterRole —> ClusterRoleList —> ClusterRoleBinding —> ClusterRoleBindingList —> Role —> RoleList —> RoleBinding —> RoleBindingList —> Service —> DaemonSet —> Pod —> ReplicationController —> ReplicaSet —> Deployment —> HorizontalPodAutoscaler —> StatefulSet —> Job —> CronJob —> Ingress —> APIService

Repository（仓库）

Repository 是存放和共享 Charts 的地方。它类似于 Perl 的 CPAN 存档或 Fedora 的软件包数据库，但专门用于 Kubernetes 的包。

图表示意：

+---------------------+
| Chart Repository    |
| ------------------- |
| Chart A     Chart B |
| Chart C     Chart D |
| ...                 |
+---------------------+

Release（发布版本）

Release 是在 Kubernetes 集群中运行的 Chart 的一个实例。一个 Chart 通常可以在同一个集群中安装多次。每次安装都会创建一个新的 Release。例如，假设有一个 MySQL Chart。如果你希望在集群中运行两个数据库实例，可以安装该 Chart 两次，每次都会有自己独立的 Release 和 Release 名称。

图表示意：

+------------------+       +------------------+
| Release A 	   |       | Release B        |
|------------------|       |------------------|
| MySQL Chart      |       | MySQL Chart      |
| Release Name: A  |       | Release Name: B  |
| ...              |       | ...              |
+------------------+       +------------------+

安装

Every release of Helm provides binary releases for a variety of OSes. These binary versions can be manually downloaded and installed.

Download your desired version
Unpack it (tar -zxvf helm-v3.0.0-linux-amd64.tar.gz)
Find the helm binary in the unpacked directory, and move it to its desired destination (mv linux-amd64/helm /usr/local/bin/helm)

创建项目模板

通过命令可以创建一个 Helm 项目模板。

`1`	`helm create mychart`

生成以下文件和目录：

.
├── charts                          # 存放依赖的 Charts
├── Chart.yaml                      # 描述 Chart 的元数据
├── templates                       # 存放模板文件
│   ├── deployment.yaml             # 部署模板
│   ├── _helpers.tpl                # 辅助模板
│   ├── hpa.yaml                    # 水平 Pod 自动缩放模板
│   ├── ingress.yaml                # 入口模板
│   ├── NOTES.txt                   # 安装说明
│   ├── serviceaccount.yaml         # 服务账户模板
│   ├── service.yaml                # 服务模板
│   └── tests                       # 测试模板
│       └── test-connection.yaml    # 测试连接模板
└── values.yaml                     # 默认值，可以覆盖模板中的值

总结

Helm 通过 Charts、Repositories 和 Releases 三个核心概念，简化了在 Kubernetes 集群中应用、工具和服务的部署与管理。Charts 提供了应用的定义，Repositories 便于 Charts 的共享和分发，而 Releases 则负责在集群中具体运行和管理这些应用实例。

Kubernetes ingress-nginx 服务证书配置指南

Mon, 16 Dec 2024 00:00:00 +0000

使用 Ingress | Kubernetes 作为 K8s 的应用流量转发代理，并配置证书

服务部署

由于使用的 K8S 集群并非云服务商提供的，需要使用 ingress-nginx 的 LoadBalancer 类型服务的话，先部署 metallb，MetalLB 是裸机 Kubernetes 集群的负载均衡器实现，使用标准路由协议。

部署 MetalLB

# see what changes would be made, returns nonzero returncode if different
kubectl get configmap kube-proxy -n kube-system -o yaml | \
sed -e "s/strictARP: false/strictARP: true/" | \
kubectl diff -f - -n kube-system

# actually apply the changes, returns nonzero returncode on errors only
kubectl get configmap kube-proxy -n kube-system -o yaml | \
sed -e "s/strictARP: false/strictARP: true/" | \
kubectl apply -f - -n kube-system

`1`	`kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.8/config/manifests/metallb-native.yaml`

ip-pool.yaml 创建 IP 池：

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: default
  namespace: metallb-system
spec:
  addresses:
  - 172.16.0.90/32  # 由于是裸机集群，需要手动指定 IP 地址
  autoAssign: true
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: default
  namespace: metallb-system
spec:
  ipAddressPools:
  - default

`1`	`kubectl apply -f ip-pool.yaml`

部署 ingress-nginx

`1`	`kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.11.2/deploy/static/provider/cloud/deploy.yaml`

配置证书

下面介绍 3 种方式配置证书：分别是手动申请自签名证书、手动申请受信任证书、使用 cert-manager 申请证书

手动申请自签名证书

申请证书，可以使用 OpenSSL，也可以使用其他工具 tls.crt 证书文件、tls.key 私钥文件，base64 编码后的内容，可以定制证书的相关信息：国家、省、市、公司、部门、域名、有效时间等

# 生成私钥
openssl genrsa -out tls.key 2048 # 生成私钥文件 tls.key

# 生成证书请求
openssl req -new -key tls.key -out tls.csr -subj "/C=<country>/ST=<province>/L=<city>/O=<company>/OU=<department>/CN=<domain>" # 生成证书请求文件 tls.csr

# 生成证书
openssl x509 -req -in tls.csr -signkey tls.key -out tls.crt -days 3650 # 生成证书文件 tls.crt

# 查看证书信息
openssl x509 -in tls.crt -text -noout

test-ingress.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: test-ingress


---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service1
  namespace: test-ingress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service1
  template:
    metadata:
      labels:
        app: service1
    spec:
      containers:
      - name: service1
        image: nginx:alpine


---
apiVersion: v1
kind: Service
metadata:
  name: service1
  namespace: test-ingress
spec:
  selector:
    app: service1
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80


# letsencrypt 证书，手动创建
---
apiVersion: v1
kind: Secret
metadata:
  name: <domain>
  namespace: test-ingress
data:
  tls.crt: <base64 encoded cert>
  tls.key: <base64 encoded key>
type: kubernetes.io/tls


---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  namespace: test-ingress
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - <domain>
      secretName: <secret name>
  rules:
    - host: <domain>
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: service1
                port:
                  number: 80

`1`	`kubectl apply -f test-ingress.yaml`

手动申请受信任证书

申请证书，可以使用 Let’s Encrypt，也可以使用其他证书颁发机构 tls.crt 证书文件、tls.key 私钥文件，base64 编码后的内容，默认有效时间 90 天

test-ingress.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: test-ingress


---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service1
  namespace: test-ingress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service1
  template:
    metadata:
      labels:
        app: service1
    spec:
      containers:
      - name: service1
        image: nginx:alpine


---
apiVersion: v1
kind: Service
metadata:
  name: service1
  namespace: test-ingress
spec:
  selector:
    app: service1
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80


# letsencrypt 证书，手动创建
---
apiVersion: v1
kind: Secret
metadata:
  name: <domain>
  namespace: test-ingress
data:
  tls.crt: <base64 encoded cert>
  tls.key: <base64 encoded key>
type: kubernetes.io/tls


---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  namespace: test-ingress
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - <domain>
      secretName: <secret name>
  rules:
    - host: <domain>
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: service1
                port:
                  number: 80

`1`	`kubectl apply -f test-ingress.yaml`

使用 cert-manager 申请证书

cert-manager 是一个 Kubernetes 证书管理控制器，基于 Kubernetes 的 CustomResourceDefinitions 资源，提供了证书申请、颁发、更新、删除等功能下面介绍如何使用 cert-manager 申请证书，三种方式：SelfSigned Issuer 类型证书、ACME Issuer 类型证书、CA Issuer 类型证书

安装 cert-manager

`1`	`kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.3/cert-manager.yaml`

默认情况下，cert-manager 将安装到 cert-manager 命名空间中。可以在不同的命名空间中运行证书管理器，尽管需要对部署清单进行修改。

安装证书管理器后，可以通过检查运行Pod的证书管理器命名空间来验证它是否正确部署：

$ kubectl get pods --namespace cert-manager

NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-cainjector-5fd6444f95-kmbmd   1/1     Running   0          60m
cert-manager-d894bbbd4-lrwp5               1/1     Running   0          60m
cert-manager-webhook-869674f96f-ljffr      1/1     Running   0          60m

配置 SelfSigned Issuer 类型证书

test-ingress.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: test-ingress


---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service1
  namespace: test-ingress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service1
  template:
    metadata:
      labels:
        app: service1
    spec:
      containers:
      - name: service1
        image: nginx:alpine


---
apiVersion: v1
kind: Service
metadata:
  name: service1
  namespace: test-ingress
spec:
  selector:
    app: service1
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80


# SelfSigned 证书 100 年，自动创建
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-issuer
  namespace: test-ingress
spec:
  selfSigned: {}

# SelfSigned 证书 100 年，自动创建
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: <domain>
  namespace: test-ingress
spec:
  secretName: <secret name>
  duration: 876000h  # 100 years
  renewBefore: 720h  # 在证书过期前 30 天自动续签
  issuerRef:
    name: selfsigned-issuer
    kind: ClusterIssuer
  commonName: <domain>
  subject:
    organizations:
      - <company>
    organizationalUnits:
      - <department>
  isCA: true
  privateKey:
    algorithm: RSA
    encoding: PKCS1
    size: 2048


---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  namespace: test-ingress
  annotations:
    cert-manager.io/cluster-issuer: selfsigned-issuer
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - <domain>
      secretName: <secret name>
  rules:
    - host: <domain>
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: service1
                port:
                  number: 80

`1`	`kubectl apply -f test-ingress.yaml`

ACME（Automated Certificate Management Environment）是一种协议，用于自动化证书颁发和更新。ACME协议由IETF标准化，目前最常见的实现是Let’s Encrypt。ACME协议的一个关键特性是，它允许证书颁发机构（CA）在不需要人工干预的情况下验证证书请求者的身份。ACME 协议的另一个关键特性是，它允许证书颁发机构自动更新证书，而无需人工干预。颁发者类型表示在自动证书管理环境（ACME）证书颁发机构服务器上注册的单个帐户。创建新的ACME颁发者时，证书管理器将生成一个私钥，用于在ACME服务器上识别。默认情况下，公共ACME服务器颁发的证书通常由客户端的计算机信任。这意味着，例如，访问由为该URL颁发的ACME证书支持的网站，默认情况下会被大多数客户端的web浏览器信任。ACME证书通常是免费的。

配置 ACME Issuer http01 类型证书

HTTP01 质询是通过展示一个计算出的密钥来完成的，这个密钥需要出现在一个可通过互联网访问的 HTTP URL 端点上。这个 URL 将使用申请证书的域名。一旦 ACME 服务器能够通过互联网从这个 URL 获取到这个密钥，就能验证你是该域名的拥有者。当创建 HTTP01 质询时，cert-manager 会自动配置你的集群入口（ingress），将访问这个 URL 的流量路由到一个小型的网络服务器上，由它展示该密钥。通俗的说，就是 cert-manager 会自动创建 ingress 路由到一个小型的网络服务器上，由它展示该密钥，以验证你是该域名的拥有者。

fake 证书一年，自动创建：kubernetes ingress controller fake cert

test-ingress.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: test-ingress


---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service1
  namespace: test-ingress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service1
  template:
    metadata:
      labels:
        app: service1
    spec:
      containers:
      - name: service1
        image: nginx:alpine


---
apiVersion: v1
kind: Service
metadata:
  name: service1
  namespace: test-ingress
spec:
  selector:
    app: service1
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80

# ACME 证书，自动创建
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: sencrypt-prod
  namespace: test-ingress
spec:
  acme:
    email: CoderKang@hotmail.com
    privateKeySecretRef:
      name: sencrypt-prod
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
      - http01:
          ingress:
            class: nginx


---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  namespace: test-ingress
  annotations:
    cert-manager.io/cluster-issuer: sencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - test.example.com
      secretName: example-com
  rules:
    - host: test.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: service1
                port:
                  number: 80

`1`	`kubectl apply -f test-ingress.yaml`

配置 ACME Issuer dns01 类型证书

DNS01 质询是通过提供一个存在于 DNS TXT 记录中的计算密钥来完成的。一旦这个 TXT 记录在互联网中传播开，ACME 服务器就能通过 DNS 查询成功获取该密钥，并验证申请证书的客户端是该域名的拥有者。如果拥有正确的权限，cert-manager 会自动在你指定的 DNS 服务提供商处添加这个 TXT 记录。

但是此次使用的是腾讯云 DNS 服务商，cert-manager 默认不支持腾讯云 DNS 服务商，需要自定义解析器 cert-manager webhook

DNS01 - cert-manager Documentation

`1`	`kubectl apply -f https://raw.githubusercontent.com/imroc/cert-manager-webhook-dnspod/master/bundle.yaml`

test-ingress.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: test-ingress


---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service1
  namespace: test-ingress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service1
  template:
    metadata:
      labels:
        app: service1
    spec:
      containers:
      - name: service1
        image: nginx:alpine


---
apiVersion: v1
kind: Service
metadata:
  name: service1
  namespace: test-ingress
spec:
  selector:
    app: service1
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80


# letsencrypt 自动创建，有效期 90 天
# 配置腾讯云 DNS 服务商的 SecretId 和 SecretKey
# https://console.dnspod.cn/account/token/apikey
---
apiVersion: v1
stringData:
  secret-key: <tencent cloud secret key>  # 腾讯云 SecretKey
kind: Secret
metadata:
  name: dnspod-secret
  namespace: cert-manager
type: Opaque

---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: sencrypt-prod
  namespace: test-ingress
spec:
  acme:
    email: CoderKang@hotmail.com
    preferredChain: ""
    privateKeySecretRef:
      name: dnspod-letsencrypt
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
      - dns01:
          webhook:
            config:
              secretId: <tencent cloud secret id>  # 腾讯云 SecretId
              secretKeyRef:
                key: secret-key
                name: dnspod-secret
              ttl: 600
            groupName: acme.imroc.cc
            solverName: dnspod

---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com
  namespace: test-ingress
spec:
  dnsNames:
    - test.example.com
  issuerRef:
    kind: ClusterIssuer
    name: sencrypt-prod
  secretName: example-com

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  namespace: test-ingress
  annotations:
    cert-manager.io/cluster-issuer: sencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - test.example.com
      secretName: example-com
  rules:
    - host: test.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: service1
                port:
                  number: 80

`1`	`kubectl apply -f test-ingress.yaml`

Kubernetes 部署 JumpServer 与钉钉告警集成指南

Tue, 19 Nov 2024 00:00:00 +0000

ingress

需要搭建 ingress（详见13-K8s ingress-nginx 服务证书）并开启 TCP 转发（详见23-K8s ingress TCP 转发）。

jumpserver

“安装”

`1`	`helm install jms-k8s ./jumpserver-v4.6.0 -n jumpserver --create-namespace -f values.yaml`

“更新”

`1`	`helm upgrade jms-k8s ./jumpserver-v4.6.0 -n jumpserver --create-namespace -f values.yaml`

“卸载”
1

helm -n jumpserver delete jms-k8s

core 组件镜像

修改 core 组件，支持钉钉告警

docker pull docker.1ms.run/jumpserver/core:v4.6.0-ce

cd core
docker build -t jumpserver/core:v4.6.1-ce .

“Dockerfile”

1
2
3

FROM docker.1ms.run/jumpserver/core:v4.6.0-ce

COPY ./notifications.py /opt/jumpserver/apps/notifications/notifications.py

“notifications.py”

import textwrap
import time
import traceback
from itertools import chain

from celery import shared_task
from django.utils.translation import gettext_lazy as _
from html2text import HTML2Text

from common.utils import lazyproperty
from common.utils.timezone import local_now
from notifications.backends import BACKEND
from settings.utils import get_login_title
from terminal.const import RiskLevelChoices
from users.models import User
from .models import SystemMsgSubscription, UserMsgSubscription

__all__ = ('SystemMessage', 'UserMessage', 'system_msgs', 'Message')

system_msgs = []
user_msgs = []


class MessageType(type):
	def __new__(cls, name, bases, attrs: dict):
		clz = type.__new__(cls, name, bases, attrs)

		if 'message_type_label' in attrs \
				and 'category' in attrs \
				and 'category_label' in attrs:
			message_type = clz.get_message_type()

			msg = {
				'message_type': message_type,
				'message_type_label': attrs['message_type_label'],
				'category': attrs['category'],
				'category_label': attrs['category_label'],
			}
			if issubclass(clz, SystemMessage):
				system_msgs.append(msg)
			elif issubclass(clz, UserMessage):
				user_msgs.append(msg)

		return clz


@shared_task(
	verbose_name=_('Publish the station message'),
	description=_(
		"""This task needs to be executed for sending internal messages for system alerts, 
		work orders, and other notifications"""
	)
)
def publish_task(receive_user_ids, backends_msg_mapper):
	Message.send_msg(receive_user_ids, backends_msg_mapper)


def send_dingtalk_task(message):
	# 发送到自定义的 Webhook
	import hmac, hashlib, base64, urllib.parse
	timestamp = str(round(time.time() * 1000))
	# JumpServer
	access_token = '<access token>'
	secret = '<secret>'

	# smartvision
	secret_enc = secret.encode('utf-8')
	string_to_sign = '{}\n{}'.format(timestamp, secret)
	string_to_sign_enc = string_to_sign.encode('utf-8')
	hmac_code = hmac.new(secret_enc, string_to_sign_enc, digestmod=hashlib.sha256).digest()
	sign = urllib.parse.quote_plus(base64.b64encode(hmac_code))
	form_data = {
		"msgtype": "markdown",
		"markdown": {
			"title": "JumpServer 监控报警",
			"text": message
		},
		"at": {
			"atMobiles": [
				"<mobile>"
			],
			"isAtAll": False
		}
	}
	import requests
	try:
		res = requests.post(
			url=f'https://oapi.dingtalk.com/robot/send?access_token={access_token}&timestamp={timestamp}&sign={sign}',
			json=form_data)
	except Exception as e:
		with open('/opt/error.log', 'a+') as f:
			f.write(str(e))


class Message(metaclass=MessageType):
	"""
	这里封装了什么？
		封装不同消息的模板，提供统一的发送消息的接口
		- publish 该方法的实现与消息订阅的表结构有关
		- send_msg
	"""
	message_type_label: str
	category: str
	category_label: str
	text_msg_ignore_links = True
	command = None

	@classmethod
	def get_message_type(cls):
		return cls.__name__

	def publish_async(self):
		self.publish(is_async=True)

	@classmethod
	def gen_test_msg(cls):
		raise NotImplementedError

	def publish(self, is_async=False):
		raise NotImplementedError

	def get_backend_msg_mapper(self, backends):
		backends = set(backends)
		backends.add(BACKEND.SITE_MSG)  # 站内信必须发
		backends_msg_mapper = {}
		for backend in backends:
			backend = BACKEND(backend)
			if not backend.is_enable:
				continue
			get_msg_method = getattr(self, f'get_{backend}_msg', self.get_common_msg)
			msg = get_msg_method()
			backends_msg_mapper[backend] = msg
		return backends_msg_mapper

	@staticmethod
	def send_msg(receive_user_ids, backends_msg_mapper):
		for backend, msg in backends_msg_mapper.items():
			try:
				backend = BACKEND(backend)
				client = backend.client()
				users = User.objects.filter(id__in=receive_user_ids).all()
				client.send_msg(users, **msg)
			except NotImplementedError:
				continue
			except:
				traceback.print_exc()

	@classmethod
	def send_test_msg(cls, ding=True, wecom=False):
		msg = cls.gen_test_msg()
		if not msg:
			return

		from users.models import User
		users = User.objects.filter(username='admin')
		backends = []
		if ding:
			backends.append(BACKEND.DINGTALK)
		if wecom:
			backends.append(BACKEND.WECOM)
		msg.send_msg(users, backends)

	@staticmethod
	def get_common_msg() -> dict:
		return {'subject': '', 'message': ''}

	def get_html_msg(self) -> dict:
		return self.get_common_msg()

	@staticmethod
	def html_to_markdown(html_msg):
		h = HTML2Text()
		h.body_width = 0
		content = html_msg['message']
		html_msg['message'] = h.handle(content)
		return html_msg

	def get_markdown_msg(self) -> dict:
		return self.html_to_markdown(self.get_html_msg())

	def get_text_msg(self) -> dict:
		h = HTML2Text()
		h.body_width = 90
		msg = self.get_html_msg()
		content = msg['message']
		h.ignore_links = self.text_msg_ignore_links
		msg['message'] = h.handle(content)
		return msg

	@lazyproperty
	def common_msg(self) -> dict:
		return self.get_common_msg()

	@lazyproperty
	def text_msg(self) -> dict:
		msg = self.get_text_msg()
		return msg

	@lazyproperty
	def markdown_msg(self):
		return self.get_markdown_msg()

	@lazyproperty
	def get_jumpserver_dingtalk_msg(self) -> str:
		date_str = time.strftime("%Y-%m-%d %H:%M:%S", time.localtime())
		msg = f"""## <font color="#FF0000">[JumpServer 监控告警](https://jumpserver.example.com/)</font>🔥
### <font color="#FF0000">告警状态</font>：{RiskLevelChoices.get_label(self.command['risk_level'])}
### <font color="#FF0000">告警主机</font>：{self.command['asset']}
### <font color="#FF0000">目标用户</font>：{self.command['user']}
### <font color="#FF0000">输入命令</font>：`{self.command['input']}`
### <font color="#FF0000">告警详情</font>：用户 {self.command['user']} 在 {self.command['asset']} 上执行了危险命令 `{self.command['input']}`，请及时处理！
### <font color="#FF0000">触发时间</font>：{date_str}"""
		return msg

	@lazyproperty
	def html_msg(self) -> dict:
		msg = self.get_html_msg()
		return msg

	@lazyproperty
	def html_msg_with_sign(self):
		msg = self.get_html_msg()
		msg['message'] = textwrap.dedent("""
		{}
		<small>
		<br />
		—
		<br />
		{}
		</small>
		""").format(msg['message'], self.signature)
		return msg

	@lazyproperty
	def text_msg_with_sign(self):
		msg = self.get_text_msg()
		msg['message'] = textwrap.dedent("""
		{}
		—
		{}
		""").format(msg['message'], self.signature)
		return msg

	@lazyproperty
	def signature(self):
		return get_login_title()

	# --------------------------------------------------------------
	# 支持不同发送消息的方式定义自己的消息内容，比如有些支持 html 标签
	def get_dingtalk_msg(self) -> dict:
		# 钉钉相同的消息一天只能发一次，所以给所有消息添加基于时间的序号，使他们不相同
		message = self.markdown_msg['message']
		time = local_now().strftime('%Y-%m-%d %H:%M:%S')
		suffix = '\n{}: {}'.format(_('Time'), time)

		return {
			'subject': self.markdown_msg['subject'],
			'message': message + suffix
		}

	def get_wecom_msg(self) -> dict:
		return self.markdown_msg

	def get_feishu_msg(self) -> dict:
		return self.markdown_msg

	def get_lark_msg(self) -> dict:
		return self.markdown_msg

	def get_email_msg(self) -> dict:
		return self.html_msg_with_sign

	def get_site_msg_msg(self) -> dict:
		return self.html_msg

	def get_slack_msg(self) -> dict:
		return self.markdown_msg

	def get_sms_msg(self) -> dict:
		return self.text_msg_with_sign

	@classmethod
	def get_all_sub_messages(cls):
		def get_subclasses(cls):
			"""returns all subclasses of argument, cls"""
			if issubclass(cls, type):
				subclasses = cls.__subclasses__(cls)
			else:
				subclasses = cls.__subclasses__()
			for subclass in subclasses:
				subclasses.extend(get_subclasses(subclass))
			return subclasses

		messages_cls = get_subclasses(cls)
		return messages_cls

	@classmethod
	def test_all_messages(cls, ding=True, wecom=False):
		messages_cls = cls.get_all_sub_messages()

		for _cls in messages_cls:
			try:
				_cls.send_test_msg(ding=ding, wecom=wecom)
			except NotImplementedError:
				continue


class SystemMessage(Message):
	def publish(self, is_async=False):
		subscription = SystemMsgSubscription.objects.get(
			message_type=self.get_message_type()
		)

		# 只发送当前有效后端
		receive_backends = subscription.receive_backends
		receive_backends = BACKEND.filter_enable_backends(receive_backends)

		users = [
			*subscription.users.all(),
			*chain(*[g.users.all() for g in subscription.groups.all()])
		]

		receive_user_ids = [u.id for u in users]
		backends_msg_mapper = self.get_backend_msg_mapper(receive_backends)
		if is_async:
			send_dingtalk_task(self.get_jumpserver_dingtalk_msg)
			# publish_task.delay(receive_user_ids, backends_msg_mapper)
		else:
			self.send_msg(receive_user_ids, backends_msg_mapper)

	@classmethod
	def post_insert_to_db(cls, subscription: SystemMsgSubscription):
		pass

	@classmethod
	def gen_test_msg(cls):
		raise NotImplementedError


class UserMessage(Message):
	user: User

	def __init__(self, user):
		self.user = user

	def publish(self, is_async=False):
		"""
		发送消息到每个用户配置的接收方式上
		"""
		sub = UserMsgSubscription.objects.get(user=self.user)
		backends_msg_mapper = self.get_backend_msg_mapper(sub.receive_backends)
		receive_user_ids = [self.user.id]
		if is_async:
			send_dingtalk_task(self.get_jumpserver_dingtalk_msg)
			# publish_task.delay(receive_user_ids, backends_msg_mapper)
		else:
			self.send_msg(receive_user_ids, backends_msg_mapper)

	@classmethod
	def get_test_user(cls):
		from users.models import User
		return User.objects.all().first()

	@classmethod
	def gen_test_msg(cls):
		raise NotImplementedError

values.yaml

```yaml
# Default values for jumpserver.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

nameOverride: ""
fullnameOverride: ""

## @param global.imageRegistry Global Docker image registry
## @param global.imagePullSecrets Global Docker registry secret names as an array
## @param global.storageClass Global StorageClass for Persistent Volume(s)
## @param global.redis.password Global Redis™ password (overrides `externalRedis.password`)
##
global:
imageRegistry: docker.1ms.run
imageOwner: jumpserver
## E.g.
#  imagePullSecrets:
#  - myRegistryKeySecretName
##
imagePullSecrets: []
storageClass: ""

## Please configure your PostgreSQL server first
## Jumpserver will not start the external PostgreSQL server.
##
externalDatabase:
engine: postgresql
host: postgresql-svc.middleware.svc.cluster.local
port: 5432
user: postgres
password: "uLwHDyYr"
database: jumpserver

## Please configure your Redis server first
## Jumpserver will not start the external Redis server.
##
externalSentinel:
{}
# hosts: mymaster/localhost:26379,localhost:26380,localhost:26381
# password: ""
# socketTimeout: 5

## Sentinel or Redis one of them must be configured.

externalRedis:
host: redis-svc.middleware.svc.cluster.local
port: 6379
password: "******"

serviceAccount:
## Specifies whether a service account should be created
create: false
## The name of the service account to use.
## If not set and create is true, a name is generated using the fullname template
name:

ingress:
enabled: true
annotations:
	cert-manager.io/cluster-issuer: sencrypt-prod
	# nginx.ingress.kubernetes.io/enable-cors: "true"
	# nginx.ingress.kubernetes.io/cors-allow-methods: "GET, POST, OPTIONS, PUT, DELETE"
	# nginx.ingress.kubernetes.io/cors-allow-headers: "Authorization, Content-Type"
	# nginx.ingress.kubernetes.io/cors-allow-credentials: "true"
	# nginx.ingress.kubernetes.io/cors-allow-origin: "*"
	# kubernetes.io/tls-acme: "true"
	kubernetes.io/ingress.class: nginx
	nginx.ingress.kubernetes.io/proxy-body-size: "4096m"
	nginx.ingress.kubernetes.io/server-snippets: |
	proxy_set_header Upgrade "websocket";
	proxy_set_header Connection "Upgrade";

hosts:
	- "jumpserver.example.com"
tls:
	- hosts:
		- jumpserver.example.com
	secretName: jumpserver.example.com

core:
enabled: true

labels:
	app.jumpserver.org/name: jms-core

config:
	## Generate a new random secret key by execute `cat /dev/urandom | tr -dc A-Za-z0-9 | head -c 50`
	secretKey: "TAcm23tDmN9n7cVCbgkDo6ln62qTuXYDKfLFYPFLd1y7DL5cS9"
	## Generate a new random bootstrap token by execute `cat /dev/urandom | tr -dc A-Za-z0-9 | head -c 24`
	bootstrapToken: "KX8k37hBbQjmKgRDR17QF7EB"
	## Enabled it for debug
	debug: false
	log:
	level: ERROR

replicaCount: 1

image:
	registry: docker.1ms.run
	pullPolicy: IfNotPresent

env:
	## See: https://docs.jumpserver.org/zh/master/admin-guide/env/#core
	SESSION_EXPIRE_AT_BROWSER_CLOSE: true
	# SESSION_COOKIE_AGE: 86400
	# SECURITY_VIEW_AUTH_NEED_MFA: true
	## Django CSRF_TRUSTED_ORIGINS need to be set to the domain name of the jumpserver (https://docs.jumpserver.org/zh/v3/installation/upgrade_notice/)
	DOMAINS: "192.168.142.56:33380"

livenessProbe:
	initialDelaySeconds: 90
	failureThreshold: 3
	timeoutSeconds: 5
	httpGet:
	path: /api/health/
	port: web

podSecurityContext:
	{}
	# fsGroup: 2000

securityContext:
	{}
	# capabilities:
	#   drop:
	#   - ALL
	# readOnlyRootFilesystem: true
	# runAsNonRoot: true
	# runAsUser: 1000

service:
	type: ClusterIP
	web:
	port: 8080

resources:
	{}
	## We usually recommend not to specify default resources and to leave this as a conscious
	## choice for the user. This also increases chances charts run on environments with little
	## resources, such as Minikube. If you do want to specify resources, uncomment the following
	## lines, adjust them as necessary, and remove the curly braces after 'resources:'.
	# limits:
	#   cpu: 1000m
	#   memory: 2048Mi
	# requests:
	#   cpu: 500m
	#   memory: 1024Mi

persistence:
	storageClassName: storage
	accessModes:
	- ReadWriteMany
	size: 100Gi
	annotations:
	"helm.sh/resource-policy": keep
	finalizers:
	- kubernetes.io/pvc-protection
	# subPath: ""
	# existingClaim: ""

volumeMounts: []

volumes: []

nodeSelector: {}

tolerations: []

affinity: {}

koko:
enabled: true

labels:
	app.jumpserver.org/name: jms-koko

config:
	log:
	level: ERROR

replicaCount: 1

image:
	registry: docker.1ms.run
	pullPolicy: IfNotPresent

env:
	[]
	## See: https://docs.jumpserver.org/zh/master/admin-guide/env/#koko
	# LANGUAGE_CODE: zh
	# REUSE_CONNECTION: true
	# ENABLE_LOCAL_PORT_FORWARD: true
	# ENABLE_VSCODE_SUPPORT: true

livenessProbe:
	initialDelaySeconds: 10
	failureThreshold: 3
	timeoutSeconds: 5
	httpGet:
	path: /koko/health/
	port: web

podSecurityContext:
	{}
	# fsGroup: 2000

securityContext:
	privileged: true
	# capabilities:
	#   drop:
	#   - ALL
	# readOnlyRootFilesystem: true
	# runAsNonRoot: true
	# runAsUser: 1000

service:
	type: ClusterIP
	web:
	port: 5000
	ssh:
	port: 2222

resources:
	{}
	## We usually recommend not to specify default resources and to leave this as a conscious
	## choice for the user. This also increases chances charts run on environments with little
	## resources, such as Minikube. If you do want to specify resources, uncomment the following
	## lines, adjust them as necessary, and remove the curly braces after 'resources:'.
	# limits:
	#   cpu: 100m
	#   memory: 128Mi
	# requests:
	#   cpu: 100m
	#   memory: 128Mi

persistence:
	storageClassName: storage
	accessModes:
	- ReadWriteMany
	size: 10Gi
	annotations:
	"helm.sh/resource-policy": keep
	finalizers:
	- kubernetes.io/pvc-protection
	# subPath: ""
	# existingClaim: ""

volumeMounts: []

volumes: []

nodeSelector: {}

tolerations: []

affinity: {}

lion:
enabled: true

labels:
	app.jumpserver.org/name: jms-lion

config:
	log:
	level: ERROR

replicaCount: 1

image:
	registry: docker.1ms.run
	pullPolicy: IfNotPresent

env:
	## See: https://docs.jumpserver.org/zh/master/admin-guide/env/#lion
	JUMPSERVER_ENABLE_FONT_SMOOTHING: true
	# JUMPSERVER_COLOR_DEPTH: 32
	# JUMPSERVER_ENABLE_WALLPAPER: true
	# JUMPSERVER_ENABLE_THEMING: true
	# JUMPSERVER_ENABLE_FULL_WINDOW_DRAG: true
	# JUMPSERVER_ENABLE_DESKTOP_COMPOSITION: true
	# JUMPSERVER_ENABLE_MENU_ANIMATIONS: true

livenessProbe:
	initialDelaySeconds: 90
	failureThreshold: 3
	timeoutSeconds: 5
	httpGet:
	path: /lion/health/
	port: web

podSecurityContext:
	{}
	# fsGroup: 2000

securityContext:
	{}
	# capabilities:
	#   drop:
	#   - ALL
	# readOnlyRootFilesystem: true
	# runAsNonRoot: true
	# runAsUser: 1000

service:
	type: ClusterIP
	web:
	port: 8081

resources:
	{}
	## We usually recommend not to specify default resources and to leave this as a conscious
	## choice for the user. This also increases chances charts run on environments with little
	## resources, such as Minikube. If you do want to specify resources, uncomment the following
	## lines, adjust them as necessary, and remove the curly braces after 'resources:'.
	# limits:
	#   cpu: 100m
	#   memory: 512Mi
	# requests:
	#   cpu: 100m
	#   memory: 512Mi

persistence:
	storageClassName: storage
	accessModes:
	- ReadWriteMany
	size: 50Gi
	annotations:
	"helm.sh/resource-policy": keep
	finalizers:
	- kubernetes.io/pvc-protection
	# subPath: ""
	# existingClaim: ""

volumeMounts: []

volumes: []

nodeSelector: {}

tolerations: []

affinity: {}

chen:
enabled: true

labels:
	app.jumpserver.org/name: jms-chen

config:
	log:
	level: ERROR

replicaCount: 1

image:
	registry: docker.1ms.run
	pullPolicy: IfNotPresent

env: []

livenessProbe:
	initialDelaySeconds: 60
	failureThreshold: 3
	timeoutSeconds: 5
	httpGet:
	path: /chen
	port: web

podSecurityContext:
	{}
	# fsGroup: 2000

securityContext:
	{}
	# capabilities:
	#   drop:
	#   - ALL
	# readOnlyRootFilesystem: true
	# runAsNonRoot: true
	# runAsUser: 1000

service:
	type: ClusterIP
	web:
	port: 8082

resources:
	{}
	## We usually recommend not to specify default resources and to leave this as a conscious
	## choice for the user. This also increases chances charts run on environments with little
	## resources, such as Minikube. If you do want to specify resources, uncomment the following
	## lines, adjust them as necessary, and remove the curly braces after 'resources:'.
	# limits:
	#   cpu: 100m
	#   memory: 128Mi
	# requests:
	#   cpu: 100m
	#   memory: 128Mi

persistence:
	storageClassName: storage
	accessModes:
	- ReadWriteMany
	size: 10Gi
	annotations:
	"helm.sh/resource-policy": keep
	finalizers:
	- kubernetes.io/pvc-protection
	# subPath: ""
	# existingClaim: ""

volumeMounts: []

volumes: []

nodeSelector: {}

tolerations: []

affinity: {}

xpack:
enabled: false

magnus:
labels:
	app.jumpserver.org/name: jms-magnus

config:
	log:
	level: ERROR

replicaCount: 1

image:
	registry: docker.1ms.run
	pullPolicy: IfNotPresent

env: []

livenessProbe:
	initialDelaySeconds: 10
	failureThreshold: 3
	timeoutSeconds: 5
	httpGet:
	path: /health
	port: web

podSecurityContext:
	{}
	# fsGroup: 2000

securityContext:
	{}
	# capabilities:
	#   drop:
	#   - ALL
	# readOnlyRootFilesystem: true
	# runAsNonRoot: true
	# runAsUser: 1000

service:
	type: ClusterIP
	web:
	port: 8088
	mysql:
	port: 33061
	mariadb:
	port: 33062
	redis:
	port: 63790
	postgresql:
	port: 54320
	sqlserver:
	port: 14330
	oracle:
	ports: 30000-30100

resources:
	{}
	## We usually recommend not to specify default resources and to leave this as a conscious
	## choice for the user. This also increases chances charts run on environments with little
	## resources, such as Minikube. If you do want to specify resources, uncomment the following
	## lines, adjust them as necessary, and remove the curly braces after 'resources:'.
	# limits:
	#   cpu: 100m
	#   memory: 512Mi
	# requests:
	#   cpu: 100m
	#   memory: 512Mi

persistence:
	storageClassName: storage
	accessModes:
	- ReadWriteMany
	size: 10Gi
	annotations:
	"helm.sh/resource-policy": keep
	finalizers:
	- kubernetes.io/pvc-protection
	# subPath: ""
	# existingClaim: ""

volumeMounts: []

volumes: []

nodeSelector: {}

tolerations: []

affinity: {}

xrdp:
labels:
	app.jumpserver.org/name: jms-xrdp

config:
	log:
	level: ERROR

replicaCount: 1

image:
	registry: registry.fit2cloud.com
	pullPolicy: IfNotPresent

env: []

livenessProbe:
	initialDelaySeconds: 10
	failureThreshold: 3
	timeoutSeconds: 5
	tcpSocket:
	port: rdp

podSecurityContext:
	{}
	# fsGroup: 2000

securityContext:
	{}
	# capabilities:
	#   drop:
	#   - ALL
	# readOnlyRootFilesystem: true
	# runAsNonRoot: true
	# runAsUser: 1000

service:
	type: ClusterIP
	rdp:
	port: 3390

resources:
	{}
	## We usually recommend not to specify default resources and to leave this as a conscious
	## choice for the user. This also increases chances charts run on environments with little
	## resources, such as Minikube. If you do want to specify resources, uncomment the following
	## lines, adjust them as necessary, and remove the curly braces after 'resources:'.
	# limits:
	#   cpu: 100m
	#   memory: 128Mi
	# requests:
	#   cpu: 100m
	#   memory: 128Mi

persistence:
	storageClassName: storage
	accessModes:
	- ReadWriteMany
	size: 50Gi
	annotations:
	"helm.sh/resource-policy": keep
	finalizers:
	- kubernetes.io/pvc-protection
	# subPath: ""
	# existingClaim: ""

volumeMounts: []

volumes: []

nodeSelector: {}

tolerations: []

affinity: {}

razor:
labels:
	app.jumpserver.org/name: jms-razor

config:
	log:
	level: ERROR

replicaCount: 1

image:
	registry: registry.fit2cloud.com
	pullPolicy: IfNotPresent

env: []

livenessProbe:
	initialDelaySeconds: 10
	failureThreshold: 3
	timeoutSeconds: 5
	httpGet:
	path: /razor/health/
	port: web

podSecurityContext:
	{}
	# fsGroup: 2000

securityContext:
	{}
	# capabilities:
	#   drop:
	#   - ALL
	# readOnlyRootFilesystem: true
	# runAsNonRoot: true
	# runAsUser: 1000

service:
	type: ClusterIP
	web:
	port: 8084
	rdp:
	port: 3389

resources:
	{}
	## We usually recommend not to specify default resources and to leave this as a conscious
	## choice for the user. This also increases chances charts run on environments with little
	## resources, such as Minikube. If you do want to specify resources, uncomment the following
	## lines, adjust them as necessary, and remove the curly braces after 'resources:'.
	# limits:
	#   cpu: 100m
	#   memory: 128Mi
	# requests:
	#   cpu: 100m
	#   memory: 128Mi

persistence:
	storageClassName: storage
	accessModes:
	- ReadWriteMany
	size: 50Gi
	annotations:
	"helm.sh/resource-policy": keep
	finalizers:
	- kubernetes.io/pvc-protection
	# subPath: ""
	# existingClaim: ""

volumeMounts: []

volumes: []

nodeSelector: {}

tolerations: []

affinity: {}

video:
labels:
	app.jumpserver.org/name: jms-video

config:
	log:
	level: ERROR

replicaCount: 1

image:
	registry: registry.fit2cloud.com
	pullPolicy: IfNotPresent

env: []

livenessProbe:
	initialDelaySeconds: 10
	failureThreshold: 3
	timeoutSeconds: 5
	httpGet:
	path: /video-worker/health/
	port: web

podSecurityContext:
	{}
	# fsGroup: 2000

securityContext:
	{}
	# capabilities:
	#   drop:
	#   - ALL
	# readOnlyRootFilesystem: true
	# runAsNonRoot: true
	# runAsUser: 1000

service:
	service:
	type: ClusterIP
	web:
	port: 9000

resources:
	{}
	## We usually recommend not to specify default resources and to leave this as a conscious
	## choice for the user. This also increases chances charts run on environments with little
	## resources, such as Minikube. If you do want to specify resources, uncomment the following
	## lines, adjust them as necessary, and remove the curly braces after 'resources:'.
	# limits:
	#   cpu: 100m
	#   memory: 128Mi
	# requests:
	#   cpu: 100m
	#   memory: 128Mi

persistence:
	storageClassName: storage
	accessModes:
	- ReadWriteMany
	size: 50Gi
	annotations:
	"helm.sh/resource-policy": keep
	finalizers:
	- kubernetes.io/pvc-protection
	# subPath: ""
	# existingClaim: ""

volumeMounts: []

volumes: []

nodeSelector: {}

tolerations: []

affinity: {}

web:
enabled: true

labels:
	app.jumpserver.org/name: jms-web

replicaCount: 1

image:
	registry: docker.1ms.run
	pullPolicy: IfNotPresent

env:
	# nginx client_max_body_size, default 4G
	CLIENT_MAX_BODY_SIZE: 4096m
	## See: https://github.com/jumpserver/docker-web/blob/master/init.sh#L37
	# USE_LB: 1, then nginx use 'proxy_set_header X-Forwarded-For $remote_addr'
	# USE_LB: 0, then nginx use 'proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for'
	USE_LB: 0

livenessProbe:
	initialDelaySeconds: 10
	failureThreshold: 3
	timeoutSeconds: 5
	httpGet:
	path: /api/health/
	port: web

podSecurityContext:
	{}
	# fsGroup: 2000

securityContext:
	{}
	# capabilities:
	#   drop:
	#   - ALL
	# readOnlyRootFilesystem: true
	# runAsNonRoot: true
	# runAsUser: 1000

service:
	type: ClusterIP
	web:
	port: 80

resources:
	{}
	## We usually recommend not to specify default resources and to leave this as a conscious
	## choice for the user. This also increases chances charts run on environments with little
	## resources, such as Minikube. If you do want to specify resources, uncomment the following
	## lines, adjust them as necessary, and remove the curly braces after 'resources:'.
	# limits:
	#   cpu: 100m
	#   memory: 128Mi
	# requests:
	#   cpu: 100m
	#   memory: 128Mi

persistence:
	storageClassName: storage
	accessModes:
	- ReadWriteMany
	size: 1Gi
	annotations:
	"helm.sh/resource-policy": keep
	finalizers:
	- kubernetes.io/pvc-protection
	# subPath: ""
	# existingClaim: ""

volumeMounts: []

volumes: []

nodeSelector: {}

tolerations: []

affinity: {}

```

修改 core 模块

1
2
3

kubectl -n jumpserver edit deployments.apps jms-k8s-jumpserver-jms-core

# 将 image 镜像名称修改为 jumpserver/core:v4.6.1-ce

Kubernetes Ingress-Nginx TCP服务转发配置指南

Wed, 20 Dec 2023 00:00:00 +0000

本指南介绍如何在 Kubernetes 集群中配置 Ingress-Nginx 控制器以支持 TCP 服务转发。以 MySQL 服务为例进行说明。

前提条件

已安装 Kubernetes 集群
已部署 Ingress-Nginx 控制器
已有需要暴露的 TCP 服务（本例中使用 MySQL）

配置步骤

配置 TCP 服务映射

创建 tcp-services.yaml 文件，定义 TCP 端口映射：

apiVersion: v1
kind: ConfigMap
metadata:
  name: tcp-services
  namespace: ingress-nginx
data:
  # 格式：外部端口: "目标命名空间/服务名:目标端口"
  3306: "default/mysql-primary:3306"

应用配置：

`1`	`kubectl create -f tcp-services.yaml`

如果 ConfigMap 已存在，可以直接编辑：

1
2

kubectl edit configmap tcp-services -n ingress-nginx
# 在 data 部分添加新的映射: <外部端口>: "<命名空间>/<服务名>:<端口>"

更新 Ingress Controller 配置

编辑 Ingress-Nginx Controller Deployment：

`1`	`kubectl edit deployment ingress-nginx-controller -n ingress-nginx`

在 controller 的 args 部分添加以下配置：

1
2
3

args:
  # ... 其他现有参数 ...
  - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services

配置 Ingress Controller Service

编辑 Ingress-Nginx Controller Service：

`1`	`kubectl edit service ingress-nginx-controller -n ingress-nginx`

在 ports 部分添加 TCP 服务端口：

ports:
  # ... 其他现有端口配置 ...
  - name: mysql-primary
    port: 3306
    protocol: TCP
    targetPort: 3306

验证配置

完成配置后，可以通过以下方式验证：

检查 ConfigMap 是否正确创建：

`1`	`kubectl get configmap tcp-services -n ingress-nginx -o yaml`

确认 Ingress Controller 是否正常运行：

`1`	`kubectl get pods -n ingress-nginx`

验证端口是否正确开放：

`1`	`kubectl get svc ingress-nginx-controller -n ingress-nginx`

注意事项

确保目标服务（如 MySQL）已经在集群中正常运行
注意检查端口冲突
如果使用云服务提供商，可能需要额外配置安全组或防火墙规则

Kubernetes 生命周期与探针详解

Sat, 18 Feb 2023 00:00:00 +0000

K8S 生命周期和探针

1. Pod 的生命周期

📝 备注

Pod 遵循预定义的生命周期，起始于 Pending 阶段，如果至少其中有一个主要容器正常启动，则进入 Running，之后取决于 Pod 中是否有容器以失败状态结束而进入 Succeeded 或者 Failed 阶段。

当一个 Pod 被删除时，执行一些 kubectl 命令会展示这个 Pod 的状态为 Terminating（终止）。这个 Terminating 状态并不是 Pod 阶段之一。

	描述
`Pending`（悬决）	Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间。
`Running`（运行中）	Pod 已经绑定到了某个节点，Pod 中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。
`Succeeded`（成功）	Pod 中的所有容器都已成功终止，并且不会再重启。
`Failed`（失败）	Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止，且未被设置为自动重启。
`Unknown`（未知）	因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。

2. 容器的状态

Kubernetes 会跟踪 Pod 中每个容器的状态，就像它跟踪 Pod 生命周期一样。

一旦调度器将 Pod 分派给某个节点，kubelet 就通过容器运行时开始为 Pod 创建容器。容器的状态有三种：Waiting（等待）、Running（运行中）和 Terminated（已终止）。要检查 Pod 中容器的状态，可以使用 kubectl describe pod <pod 名称>。其输出中包含 Pod 中每个容器的状态。

每种状态都有特定的含义：

2.1 `Waiting` （等待）

如果容器并不处在 Running 或 Terminated 状态之一，它就处在 Waiting 状态。处于 Waiting 状态的容器仍在运行它完成启动所需要的操作：例如，从某个容器镜像仓库拉取容器镜像，或者向容器传递并应用 ConfigMap、Secret 数据等等。

2.2 `Running`（运行中）

Running 状态表明容器正在执行状态并且没有问题发生。

2.3 `Terminated`（已终止）

处于 Terminated 状态的容器已经开始执行并且或者正常结束或者因为某些原因失败。

3. Pod 异常场景

Pod 在其生命周期的许多时间点可能发生不同的异常，按照 Pod 容器是否运行为标志点，可以将异常场景大致分为两类：

在 Pod 进行调度并创建容器过程中发生异常，此时 Pod 将卡在 Pending 阶段。
Pod 容器运行中发生异常，此时 Pod 按照具体场景处在不同阶段。

4. 容器探针

probe 是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 既可以在容器内执行代码，也可以发出一个网络请求。

配置存活、就绪和启动探针 | Kubernetes

4.1 存活探针`livenessProbe`

4.1.1 什么是存活态探针?

存活探针决定何时重启容器。例如，当应用在运行但无法取得进展时，存活探针可以捕获这类死锁。

如果一个容器的存活探针失败多次，kubelet 将重启该容器。如果存活态探测失败，则 kubelet 会杀死容器，并且容器将根据其重启策略决定后续动作。如果容器不提供存活探针，则默认状态为 Success。

存活探针不会等待就绪探针成功。如果想在执行存活探针前等待，可以定义 initialDelaySeconds，或者使用启动探针。

4.1.2 何时该使用存活态探针?

如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活态探针； kubelet 将根据 Pod 的 restartPolicy 自动执行修复操作。

如果希望容器在探测失败时被杀死并重新启动，那么请指定一个存活态探针，并指定 restartPolicy 为 “Always” 或 “OnFailure"。

4.2 就绪探针`readinessProbe`

4.2.1 什么是就绪探针?

就绪探针决定何时容器准备好开始接受流量。这种探针在等待应用执行耗时的初始任务时非常有用，例如建立网络连接、加载文件和预热缓存。

如果就绪探针返回的状态为失败，Kubernetes 会将该 Pod 从所有对应服务的端点中移除。

就绪探针在容器的整个生命期内持续运行。

4.2.2 何时该使用就绪态探针?

如果要仅在探测成功时才开始向 Pod 发送请求流量，请指定就绪态探针。在这种情况下，就绪态探针可能与存活态探针相同，但是规约中的就绪态探针的存在意味着 Pod 将在启动阶段不接收任何数据，并且只有在探针探测成功后才开始接收数据。

如果希望容器能够自行进入维护状态，也可以指定一个就绪态探针，检查某个特定于就绪态的因此不同于存活态探测的端点。

如果应用程序对后端服务有严格的依赖性，可以同时实现存活态和就绪态探针。当应用程序本身是健康的，存活态探针检测通过后，就绪态探针会额外检查每个所需的后端服务是否可用。这可以帮助避免将流量导向只能返回错误信息的 Pod。

如果容器需要在启动期间加载大型数据、配置文件或执行迁移，可以使用启动探针。然而，如果想区分已经失败的应用和仍在处理其启动数据的应用，可能更倾向于使用就绪探针。

4.3 启动探针`startupProbe`

4.3.1 什么是启动探针?

启动探针检查容器内的应用是否已启动。启动探针可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被 kubelet 杀掉。

如果配置了这类探针，它会禁用存活检测和就绪检测，直到启动探针成功为止。

这类探针仅在启动时执行，不像就绪探针那样周期性地运行。

4.3.2 何时该使用启动探针？

对于所包含的容器需要较长时间才能启动就绪的 Pod 而言，启动探针是有用的。不再需要配置一个较长的存活态探测时间间隔，只需要设置另一个独立的配置选定，对启动期间的容器执行探测，从而允许使用远远超出存活态时间间隔所允许的时长。

如果容器启动时间通常超出 initialDelaySeconds + failureThreshold × periodSeconds 总值，应该设置一个启动探测，对存活态探针所使用的同一端点执行检查。 periodSeconds 的默认值是 10 秒。应该将其 failureThreshold 设置得足够高，以便容器有充足的时间完成启动，并且避免更改存活态探针所使用的默认值。这一设置有助于减少死锁状况的发生。

4.4 探针的执行

探针	操作对象	操作动作	操作结果	运行时间
存活探针	容器本身	重启容器	容器重新启动	容器整个生命周期
就绪探针	容器对应的端点	删除端点	从所有对应服务的端点中移除，不接收流量	容器整个生命周期
启动探针	容器本身	重启容器	容器重新启动	容器 Running 后执行一次

4.5 探针的使用

使用探针来检查容器有四种不同的方法。每个探针都必须准确定义为这四种机制中的一种：

探针类型	描述
`exec`	在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
`tcpSocket`	对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。如果远程系统（容器）在打开连接后立即将其关闭，这算作是健康的。
`httpGet`	对容器的 IP 地址上指定端口和路径执行 HTTP `GET` 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。
`grpc`	使用 gRPC 执行一个远程过程调用。目标应该实现 gRPC 健康检查。如果响应的状态是 “SERVING”，则认为诊断成功。

探针参数	描述
`initialDelaySeconds`	容器启动后要等待多少秒后才启动启动、存活和就绪探针。如果定义了启动探针，则存活探针和就绪探针的延迟将在启动探针已成功之后才开始计算。如果 periodSeconds 的值大于 initialDelaySeconds，则 initialDelaySeconds 将被忽略。默认是 0 秒，最小值是 0。
`periodSeconds`	执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
`timeoutSeconds`	探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
`successThreshold`	探针在失败后，被视为成功的最小连续成功数。默认值是 1。存活和启动探针的这个值必须是 1。最小值是 1。
`failureThreshold`	探针连续失败了 failureThreshold 次之后， Kubernetes 认为总体上检查已失败：容器状态未就绪、不健康、不活跃。默认值为 3，最小值为 1。对于启动探针或存活探针而言，如果至少有 failureThreshold 个探针已失败， Kubernetes 会将容器视为不健康并为这个特定的容器触发重启操作。 kubelet 遵循该容器的 terminationGracePeriodSeconds 设置。对于失败的就绪探针，kubelet 继续运行检查失败的容器，并继续运行更多探针；因为检查失败，kubelet 将 Pod 的 Ready 状况设置为 false。
`terminationGracePeriodSeconds`	为 kubelet 配置从为失败的容器触发终止操作到强制容器运行时停止该容器之前等待的宽限时长。默认值是继承 Pod 级别的 terminationGracePeriodSeconds 值（如果不设置则为 30 秒），最小值为 1。`Kubernetes v1.25` 以上版本新增，只对`启动探针`和`存活探针`有效。

4.6 示例

apiVersion: v1
kind: Namespace
metadata:
  name: k8s-test


---
apiVersion: v1
kind: ConfigMap
metadata:
  name: probe-demo
  namespace: k8s-test
data:
  default.conf: |
    server {
        listen       80;
        server_name  localhost;
        keepalive_timeout  0;

        location / {
            root   /usr/share/nginx/html;
            index  index.html index.htm;
        }
    }


---
apiVersion: v1
kind: Service
metadata:
  name: probe-demo
  namespace: k8s-test
spec:
  selector:
    app: probe-demo
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 31080
  type: NodePort


---
apiVersion: v1
kind: Pod
metadata:
  name: probe-demo
  namespace: k8s-test
  labels:
    app: probe-demo
spec:
  restartPolicy: OnFailure  # Pod 的重启策略：OnFailure 表示只有在容器退出码非 0 时才会重启；Always 表示只要容器退出就重启；Never 表示从不重启
  containers:
    - name: probe-demo
      image: 192.168.142.99:7891/devops/nginx:latest
      # command: ["/bin/sh", "-c", "sleep 10"]  # 模拟 pod 状态为 Succeeded
      # command: ["/bin/sh", "-c", "sleep infinity"]  # 启动探针
      command: ["/bin/sh", "-c", "set -ex && nohup nginx && touch /tmp/healthy && sleep 30 && rm -f /tmp/healthy && sleep 600"]
      # startupProbe:
      #   exec:
      #     command:
      #       - cat
      #       - /tmp/healthy
      #   initialDelaySeconds: 5  # 容器启动后要等待 5 秒后才启动探针
      #   periodSeconds: 5  # 每隔 5 秒执行一次探针
      #   timeoutSeconds: 1  # 探测的超时时间为 1 秒
      #   successThreshold: 1  # 探针在失败后，被视为成功的最小连续成功数
      #   failureThreshold: 3  # 探针连续失败了 3 次之后， Kubernetes 认为总体上检查已失败
      # livenessProbe:
      #   exec:
      #     command:
      #       - cat
      #       - /tmp/healthy
      #   initialDelaySeconds: 5
      #   periodSeconds: 5
      #   timeoutSeconds: 1
      #   failureThreshold: 3
      readinessProbe:
        exec:
          command:
            - cat
            - /tmp/healthy
        initialDelaySeconds: 5
        periodSeconds: 5
        timeoutSeconds: 1
        failureThreshold: 3
      
      
      volumeMounts:
        - name: config-volume
          mountPath: /etc/nginx/conf.d/default.conf
          subPath: default.conf

  volumes:
    - name: config-volume
      configMap:
        name: probe-demo
        items:
          - key: default.conf
            path: default.conf

Kubernetes on Kang's Blog

昇腾 K8s 环境部署指南

昇腾 K8s 环境部署指南

概述

准备工作

创建节点标签

创建系统用户

创建日志目录

安装 Ascend Docker Runtime

下载安装包

安装步骤

步骤 1：进入安装包目录

步骤 2：校验安装包完整性

步骤 3：添加可执行权限

步骤 4：执行安装

配置 Containerd

配置方式一：Cgroup v1

配置方式二：Cgroup v2

重启服务

验证安装

部署 Ascend Device Plugin

准备镜像

下载部署配置文件

选择合适的 YAML 文件

部署 Device Plugin

验证部署

使用 NPU 计算卡

Pod 配置示例

Helm 核心概念与实践指南

简介

Helm 的工作原理

三个核心概念

Chart（图表）

Repository（仓库）

Release（发布版本）

安装

创建项目模板

总结

Kubernetes ingress-nginx 服务证书配置指南

服务部署

部署 MetalLB

部署 ingress-nginx

配置证书

手动申请自签名证书

手动申请受信任证书

使用 cert-manager 申请证书

安装 cert-manager

配置 SelfSigned Issuer 类型证书

配置 ACME Issuer http01 类型证书

配置 ACME Issuer dns01 类型证书

Kubernetes 部署 JumpServer 与钉钉告警集成指南

ingress

jumpserver

core 组件镜像

values.yaml

修改 core 模块

Kubernetes Ingress-Nginx TCP服务转发配置指南

前提条件

配置步骤

配置 TCP 服务映射

更新 Ingress Controller 配置

配置 Ingress Controller Service

验证配置

注意事项

Kubernetes 生命周期与探针详解

K8S 生命周期和探针

1. Pod 的生命周期

2. 容器的状态

2.1 Waiting （等待）

2.2 Running（运行中）

2.3 Terminated（已终止）

3. Pod 异常场景

4. 容器探针

4.1 存活探针livenessProbe

4.1.1 什么是存活态探针?

4.1.2 何时该使用存活态探针?

4.2 就绪探针readinessProbe

4.2.1 什么是就绪探针?

4.2.2 何时该使用就绪态探针?

4.3 启动探针startupProbe

2.1 `Waiting` （等待）

2.2 `Running`（运行中）

2.3 `Terminated`（已终止）

4.1 存活探针`livenessProbe`

4.2 就绪探针`readinessProbe`

4.3 启动探针`startupProbe`