tech

Kubernetes 核心对象速查

记录 K8s 业务应用必备的对象层级，从最精简集合到生产必备组件，理清 Deployment、Service、Ingress、ConfigMap、PVC 等核心资源的关系。

#Kubernetes#开发
--

跑一个业务应用上 K8s，能对外访问、具备基本自愈能力，需要哪些对象？这里按「必须」「几乎必用」 梳理，并附上一份极简可用的 YAML 示例合集。

最精简集合（能跑、能访问的极简 Demo）

这套组合足够启动一个无状态服务，并让集群内部能稳定访问它：

  • Deployment —— 无状态业务应用的核心控制器，管理 Pod 副本数、滚动更新、扩缩容和自愈。不要手写 Pod，Pod 由 Deployment 自动生成并托管。
  • Pod —— 最小运行单元，但一般不手动创建，由 Deployment 控制器自动产生。
  • Service —— 给一组 Pod 提供统一的网络入口，实现负载均衡。没有 Service，Pod IP 会随重启变化，集群内部无法稳定访问。

这三者足以构成一个最小可行单元。

对外暴露访问（公网/主机访问）

二选一，按场景决定：

  • Ingress（生产最常用） —— 七层 HTTP/HTTPS 路由，支持域名和路径转发。需要额外部署 Ingress‑Controller（如 Nginx Ingress、Traefik）才能生效。
  • Service 类型为 NodePort / LoadBalancer —— 四层暴露方式，适合测试或非 HTTP 场景。

真实项目几乎必用的对象

线上业务除了跑起来，还要管配置、存数据、做隔离：

配置 & 敏感信息

  • ConfigMap —— 存放非敏感配置，如配置文件、环境变量。
  • Secret —— 存放密码、Token、密钥等敏感数据。注意：Secret 只是 Base64 编码，并非加密，生产环境建议配合外部密钥管理方案（如 HashiCorp Vault、External Secrets Operator）。

存储（有状态业务）

  • PersistentVolumeClaim（PVC） —— Pod 申请存储资源，业务通过 PVC 读写数据。
  • PV —— 集群层面的存储资源，通常由存储类（StorageClass）动态供给，开发者一般只写 PVC 即可。

命名空间

  • Namespace —— 资源隔离，一个项目通常独占一个 Namespace，部署时通过 kubectl apply -n <namespace> 指定。

权限（多团队生产）

  • ServiceAccount + Role + RoleBinding —— RBAC 权限体系，用于 Pod 内应用访问 K8s API。个人开发/测试环境可省略。

极简 YAML 示例（完整可部署）

以下是一个 Golang HTTP 服务的完整最小示例，包含 Deployment + Service + ConfigMap + Ingress：

# 1. Namespace（可选，推荐生产使用）
apiVersion: v1
kind: Namespace
metadata:
  name: demo-app
---
# 2. ConfigMap（非敏感配置）
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: demo-app
data:
  APP_ENV: "production"
  LOG_LEVEL: "info"
---
# 3. Deployment（核心）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: demo-app
  labels:
    app: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: app
          image: nginx:alpine # 替换为你的业务镜像
          ports:
            - containerPort: 80
          envFrom:
            - configMapRef:
                name: app-config
          resources:
            requests:
              memory: "64Mi"
              cpu: "100m"
            limits:
              memory: "128Mi"
              cpu: "200m"
          # 健康检查（生产必备）
          livenessProbe:
            httpGet:
              path: /health
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: 80
            initialDelaySeconds: 3
            periodSeconds: 5
---
# 4. Service（集群内稳定访问）
apiVersion: v1
kind: Service
metadata:
  name: my-app-svc
  namespace: demo-app
spec:
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP # 仅集群内访问，对外暴露用 Ingress 或 NodePort
---
# 5. Ingress（对外七层路由，需 Ingress-Controller）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  namespace: demo-app
spec:
  rules:
    - host: api.your-domain.com # 替换为实际域名
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app-svc
                port:
                  number: 80

注意事项

  • Pod 不应该手动维护：业务 Pod 一律交给 Deployment / StatefulSet 管理，不要单独写 Pod YAML。
  • Service 只做转发：Service 本身不代理外部流量；Ingress 只是路由规则，真正干活的是 Ingress‑Controller。
  • Secret 不是加密：默认只是 Base64，生产环境请使用外部密钥管理。
  • PV 由运维负责：业务开发者通常只写 PVC，PV 由存储类自动供给或集群管理员维护。