面向业务应用的 Kubernetes 入门

面向业务团队的 Kubernetes 实用入门，不含废话：核心对象的作用、一份可直接复制使用的部署示例，以及如何在境内的 Skyline Cloud 基础设施上运行它以满足 PDPL 数据驻留要求。

业务为什么会用到 Kubernetes

对于单个小型网站，你并不需要 Kubernetes。当你拥有多个服务、多套环境，或者需要承担可用性方面的义务时，才会开始需要它。其带来的实际收益包括：

• 自愈能力： 崩溃的容器会被自动重启；不健康的节点会被排空（drain）。
• 横向扩展： 增加副本以吸收流量峰值，之后再缩减回去。
• 零停机发布： 滚动更新会逐步替换旧的 pod，并在失败时自动回滚。
• 可移植性： 同一份清单（manifest）可以在你的笔记本电脑、测试集群和生产环境中运行。

用通俗的话讲核心对象

Kubernetes 中的一切都是你用 YAML 描述的声明式对象。集群会持续工作，使现实状态与你所声明的状态保持一致。

你很少会直接创建 pod。你创建一个 Deployment，由它来为你管理 pod。

一个可运行的示例

下面是一个无状态 Web 应用的完整、最小化部署，置于一个 service 之后。将其保存为 app.yaml。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "250m"
              memory: "256Mi"
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 3
            periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

这里有两点值得理解。selector 字段是 Deployment 和 Service 找到它们 pod 的方式：它们基于标签 app: web 进行匹配，而不是基于名称。而 readinessProbe 则告诉 Kubernetes，在某个 pod 真正能在 80 端口上响应之前，不要将流量发送给它——正是这一点使滚动更新变得安全。

应用它并观察其收敛过程：

kubectl apply -f app.yaml
kubectl get pods -l app=web
kubectl rollout status deployment/web

你会看到三个 pod 进入 Running 状态。删掉其中一个，即可看到自愈能力的实际效果：

kubectl delete pod -l app=web --field-selector=status.phase=Running --grace-period=0 | head -1
kubectl get pods -l app=web   # 一个替代 pod 已经在被创建

扩展与安全发布

扩展只需一行命令，而且这正是你之后会用来做自动化的同一条命令：

kubectl scale deployment/web --replicas=6

要发布新版本，只需修改镜像，Kubernetes 便会执行滚动更新——只有当新 pod 通过其就绪探针（readiness probe）后，才会启动新 pod 并移除旧 pod：

kubectl set image deployment/web web=nginx:1.27.1
kubectl rollout status deployment/web
# 如果出了问题：
kubectl rollout undo deployment/web

针对生产流量模式，添加一个 HorizontalPodAutoscaler，让集群根据 CPU 自动增加副本：

kubectl autoscale deployment/web --min=3 --max=10 --cpu-percent=70

配置与密钥

让配置脱离你的镜像，在运行时注入它：

kubectl create configmap web-config --from-literal=APP_ENV=production
kubectl create secret generic web-secret --from-literal=DB_PASSWORD='change-me'

然后在 pod 规约中用 envFrom 引用它们。这使得同一个镜像无需改动即可在 staging 和 production 之间运行，凭据被单独管理，且永远不会被打包进构建产物。

在沙特境内运行它

对于沙特和海湾合作委员会（GCC）的企业来说，集群在哪里运行与如何运行同样重要。根据 PDPL，处理沙特居民的个人数据通常必须兼顾数据主体的预期以及适用的跨境传输规则，而 NCA/SDAIA 框架也推动受监管的工作负载转向境内托管。将你的节点、持久卷和备份都放在沙特数据中心内运行，可使这些数据驻留在本地，并简化审计。

Skyline Cloud 是一家境内服务提供商，因此你可以在沙特境内的云服务器和 VPS 上运行 Kubernetes 工作节点，挂载境内的块存储和对象存储用于持久卷和备份，并在凌晨两点出现故障时联系到本地的阿拉伯语团队。如果你的应用还会向客户发送通知或收据，将其与同一境内基础设施上的企业邮箱托管搭配使用，也能让这些数据驻留在本地。若想更深入地了解托管集群及其运维模式，请参阅我们的沙特阿拉伯托管 Kubernetes 专题页。

对大多数企业而言，一个合理的初始集群是三个小型工作节点：既足以在一个节点发生故障时存活下来，又能在不超支的前提下真实地测试滚动更新。

一份实用的入门清单

1. 先将一个无状态服务容器化；起步阶段先把数据库留在托管存储上。
2. 像上面的示例那样编写一个 Deployment + Service，并获得一次干净的 rollout status。
3. 添加就绪探针以及资源请求/限制（requests/limits）——正是这些让集群表现得规范可控。
4. 将配置迁移到 ConfigMap 和 Secret 中。
5. 在基础设置稳定之后，再添加自动伸缩器（autoscaler）和 Ingress。

在 Skyline Cloud 上开始

你可以在几分钟内启动工作节点、挂载境内存储，并让你的数据处于沙特司法管辖之下。创建你的 Skyline Cloud 账户，在本地支持团队的支持下部署你的第一个集群。