从源码到部署：基于 Kubernetes 开源项目实现中型团队容器编排平台的实战指南

很多团队在容器化走到第二阶段时，都会遇到一个非常现实的问题：

不再满足“有个 Kubernetes 集群能跑 Pod”就行了，而是需要一套真正能支撑中型研发团队协作的容器编排平台。

这篇文章我会从源码理解到平台落地部署，带你走一遍“基于 Kubernetes 开源项目，搭一个中型团队可用的平台”的过程。重点不是重复讲 Kubernetes 基础概念，而是回答这些更落地的问题：

为什么不能直接裸用 Kubernetes？
中型团队的平台到底要补哪些能力？
如果基于开源项目做二次集成，技术路线怎么选？
如何做一个最小可运行版本，并逐步扩展？
遇到 RBAC、Ingress、存储、证书、构建链路这些坑时，怎么排查？

文章默认你已经有 Kubernetes 基础，适合有一定集群运维或平台开发经验的同学。

背景与问题

为什么“只有 Kubernetes”不够

Kubernetes 非常强，但它本质上是一个容器编排内核，不是开箱即用的企业应用平台。对于中型团队，通常还缺这些东西：

统一应用发布入口：开发同学不想手写一堆 YAML
多租户隔离：不同项目组、环境、命名空间要隔离
镜像构建与交付链路：代码提交后怎么变成镜像、怎么部署
访问入口管理：域名、证书、灰度、流量策略
可观测性：日志、指标、告警
权限体系：谁能发版、谁能看日志、谁能改配置
平台自服务能力：而不是全靠运维手工创建资源

如果你的团队规模在 30~200 人之间，这些能力往往已经是“必需品”，不是“锦上添花”。

中型团队平台的典型诉求

我一般会把诉求拆成三层：

控制面
- Kubernetes API
- 身份认证、授权
- 多集群或多环境管理
交付面
- Git 仓库
- 镜像仓库
- CI/CD
- 发布策略
运行面
- Ingress/Gateway
- 存储
- 日志、监控、告警
- 备份恢复

如果没有一个清晰分层，平台很容易变成“把开源组件全装上”，最后谁都不会维护。

前置知识与环境准备

本文采用一个适合中型团队起步的开源组合，尽量避免过度设计：

Kubernetes：平台核心
ingress-nginx：入口流量控制
cert-manager：证书管理
Harbor：镜像仓库
Argo CD：GitOps 持续部署
Prometheus + Grafana：监控
Loki 或 EFK：日志
可选：KubeSphere / Backstage 作为上层入口

本文目标

我们最终会实现一个最小但可用的平台能力：

基于源码理解 Kubernetes 控制流程
用 kubeadm 搭建集群
部署 NGINX Ingress、Metrics Server、Argo CD
用一个示例应用完成从镜像到发布的全过程
加上 Namespace、RBAC、资源限制，形成“团队级”最小闭环

核心原理

在开始部署前，先把核心原理捋顺。你不一定要天天看 Kubernetes 源码，但至少要理解它为什么能工作。

Kubernetes 的控制回路

Kubernetes 最核心的思想不是“执行命令”，而是声明式状态收敛。

你告诉集群：

我想要 3 个副本
我想要一个 Service 暴露它
我想要一个 Ingress 让外部访问

然后控制器不断对比：

当前状态是什么
目标状态是什么
如何把当前状态收敛到目标状态

这个模式决定了平台设计思路：
你的平台最好也是声明式的，而不是脚本堆起来的手工流程。

flowchart LR
    A[开发者提交 YAML/Git 变更] --> B[API Server]
    B --> C[etcd 持久化]
    B --> D[Controller Manager 监听资源]
    D --> E[创建/更新 ReplicaSet Pod Service]
    E --> F[Kubelet 在节点执行]
    F --> G[容器运行时 containerd]
    B --> H[Scheduler 选择节点]
    H --> F

从源码角度看关键组件

如果你翻 Kubernetes 源码，会发现很多控制器本质上都遵循类似结构：

Informer：监听资源变化
Workqueue：放入待处理任务
Reconcile/Sync：实际做状态收敛

比如 Deployment 控制器大致是：

监听 Deployment 变化
放入队列
检查是否需要创建或更新 ReplicaSet
再由 ReplicaSet 控制器确保 Pod 数量正确

这就是我们做平台时的重要启发：

上层平台不应该直接 SSH 到节点上操作
应该围绕 Kubernetes API 扩展
平台的“应用发布”本质上也是一类控制回路

中型团队平台的参考架构

下面这个架构是我比较推荐的“够用、可演进”的形态：

flowchart TB
    U[开发/测试/运维] --> P[平台入口 Portal]
    P --> G[Git 仓库]
    P --> A[Argo CD]
    P --> K[Kubernetes API Server]

    G --> A
    A --> K

    K --> N[Namespace + RBAC + ResourceQuota]
    K --> I[Ingress NGINX]
    K --> M[Monitoring]
    K --> L[Logging]
    K --> S[StorageClass/PVC]

    CI[CI 系统] --> H[Harbor]
    H --> K
    C[cert-manager] --> I

这个架构的好处有三点：

职责清楚
- CI 负责构建
- Git 负责声明配置
- Argo CD 负责同步部署
- Kubernetes 负责运行
便于审计
- 变更尽量通过 Git 进入集群
易于扩展
- 后面接入灰度、服务网格、策略引擎都方便

方案选型：为什么是这组开源项目

有些同学会问：为什么不是 Rancher、KubeSphere、Jenkins X、Flux、Istio 全家桶？

原因很简单：中型团队最怕的不是能力不够，而是维护成本失控。

本文这套组合的取舍

能力	选型	原因
容器编排	Kubernetes	事实标准
集群安装	kubeadm	标准、透明、可控
流量入口	ingress-nginx	成熟、文档多
证书管理	cert-manager	和 Ingress 集成好
镜像仓库	Harbor	企业常用、权限清晰
CD	Argo CD	GitOps 体验成熟
监控	Prometheus + Grafana	生态最好
日志	Loki 或 EFK	按团队能力选择

什么情况下不适合本文方案

这套方案不是银弹，以下场景要谨慎：

团队太小（<10 人）：维护这套平台可能比收益还大
多云多集群极其复杂：可能更适合 Rancher/OpenShift 这类更完整平台
强合规行业：需要更重的审计、策略与密钥管理方案
缺乏 Kubernetes 运维能力：建议优先托管版 Kubernetes

从源码到平台设计：我们需要补什么

如果把 Kubernetes 看作“平台内核”，那么中型团队还需要补下面这些抽象层。

1. 租户模型

建议至少做这三层映射：

组织/团队
项目
环境（dev/test/prod）

一个常见设计是：

每个项目一个 Namespace
不同环境不同 Namespace，例如：
- team-a-dev
- team-a-test
- team-a-prod

2. 发布模型

应用发布至少要能表达：

镜像地址
副本数
资源请求与限制
环境变量
配置与密钥
服务暴露方式
灰度/回滚策略

这些都可以映射到 Kubernetes 原生资源：

Deployment
Service
Ingress
ConfigMap
Secret
HPA
NetworkPolicy

3. 权限模型

建议最开始就明确：

开发者：看日志、看 Pod、部署 dev/test
测试：操作 test 环境
运维/平台：管理集群级资源
生产发布：单独审批或受限角色

如果一开始图省事全给 cluster-admin，后面几乎一定要返工。

实战代码（可运行）

下面我们从 0 到 1 搭一个最小平台。代码和命令都尽量保持可运行。

第一步：安装 Kubernetes 集群

1.1 安装 containerd

在所有节点执行：

sudo apt-get update
sudo apt-get install -y containerd
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml >/dev/null
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
sudo systemctl restart containerd
sudo systemctl enable containerd

1.2 安装 kubeadm、kubelet、kubectl

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gpg

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key \
  | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' \
  | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

1.3 初始化 control-plane

sudo kubeadm init \
  --apiserver-advertise-address=192.168.56.10 \
  --pod-network-cidr=10.244.0.0/16

初始化成功后，配置 kubectl：

mkdir -p $HOME/.kube
sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown "$(id -u)":"$(id -g)" $HOME/.kube/config

1.4 安装网络插件 Calico

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.1/manifests/calico.yaml

1.5 Worker 节点加入集群

使用 kubeadm init 输出的 join 命令，例如：

sudo kubeadm join 192.168.56.10:6443 \
  --token <your-token> \
  --discovery-token-ca-cert-hash sha256:<your-hash>

1.6 验证

kubectl get nodes -o wide
kubectl get pods -A

第二步：部署平台基础组件

2.1 安装 ingress-nginx

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml

检查状态：

kubectl get pods -n ingress-nginx
kubectl get svc -n ingress-nginx

2.2 安装 metrics-server

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

如果是测试环境，可能需要增加 --kubelet-insecure-tls。可以编辑 Deployment：

kubectl -n kube-system edit deployment metrics-server

在容器参数中加入：

- --kubelet-insecure-tls

验证：

kubectl top nodes
kubectl top pods -A

2.3 安装 Argo CD

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

查看服务：

kubectl get svc -n argocd

本地临时访问：

kubectl port-forward svc/argocd-server -n argocd 8080:443

获取初始密码：

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d && echo

第三步：创建团队级命名空间与权限

这是很多团队早期最容易忽略的部分。我当时踩过一个坑：业务还没几个人，觉得权限先放开吧，结果半年后十几个项目共用一个 namespace，谁也不敢删资源。

3.1 创建 Namespace、ResourceQuota、LimitRange

apiVersion: v1
kind: Namespace
metadata:
  name: team-a-dev
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-dev-quota
  namespace: team-a-dev
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "30"
    services: "10"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: team-a-dev-limits
  namespace: team-a-dev
spec:
  limits:
    - type: Container
      defaultRequest:
        cpu: 100m
        memory: 128Mi
      default:
        cpu: 500m
        memory: 512Mi

保存为 team-a-dev.yaml，执行：

kubectl apply -f team-a-dev.yaml

3.2 创建只允许管理本命名空间的 Role

apiVersion: v1
kind: ServiceAccount
metadata:
  name: team-a-deployer
  namespace: team-a-dev
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-a-dev
  name: team-a-deployer-role
rules:
  - apiGroups: ["", "apps", "networking.k8s.io"]
    resources:
      - pods
      - services
      - configmaps
      - secrets
      - deployments
      - replicasets
      - ingresses
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-deployer-binding
  namespace: team-a-dev
subjects:
  - kind: ServiceAccount
    name: team-a-deployer
    namespace: team-a-dev
roleRef:
  kind: Role
  name: team-a-deployer-role
  apiGroup: rbac.authorization.k8s.io

应用：

kubectl apply -f team-a-rbac.yaml

第四步：部署一个示例应用

我们用一个最简单的 Web 服务来跑通完整链路。

4.1 示例应用代码

from flask import Flask
import os

app = Flask(__name__)

@app.route("/")
def hello():
    return {
        "message": "hello from kubernetes platform",
        "version": os.getenv("APP_VERSION", "v1")
    }

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

文件名：app.py

4.2 requirements.txt

flask==3.0.3
gunicorn==22.0.0

4.3 Dockerfile

FROM python:3.11-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

ENV APP_VERSION=v1
EXPOSE 8080

CMD ["gunicorn", "-w", "2", "-b", "0.0.0.0:8080", "app:app"]

4.4 构建并推送镜像

docker build -t harbor.example.internal/demo/flask-demo:v1 .
docker push harbor.example.internal/demo/flask-demo:v1

第五步：编写 Kubernetes 部署清单

5.1 Deployment + Service + Ingress

apiVersion: apps/v1
kind: Deployment
metadata:
  name: flask-demo
  namespace: team-a-dev
spec:
  replicas: 2
  selector:
    matchLabels:
      app: flask-demo
  template:
    metadata:
      labels:
        app: flask-demo
    spec:
      containers:
        - name: flask-demo
          image: harbor.example.internal/demo/flask-demo:v1
          imagePullPolicy: IfNotPresent
          env:
            - name: APP_VERSION
              value: "v1"
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 300m
              memory: 256Mi
          readinessProbe:
            httpGet:
              path: /
              port: 8080
            initialDelaySeconds: 3
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: flask-demo
  namespace: team-a-dev
spec:
  selector:
    app: flask-demo
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: flask-demo
  namespace: team-a-dev
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
    - host: flask-demo.example.internal
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: flask-demo
                port:
                  number: 80

应用：

kubectl apply -f flask-demo.yaml

验证：

kubectl get all -n team-a-dev
kubectl get ingress -n team-a-dev
curl -H "Host: flask-demo.example.internal" http://<INGRESS_IP>/

第六步：接入 GitOps 持续部署

如果你靠 kubectl apply -f 手工发版，前期还行，项目多了以后会非常痛苦。这里我们用 Argo CD 做一个最小 GitOps 流程。

6.1 应用仓库目录结构建议

platform-demo/
├── app/
│   ├── app.py
│   ├── requirements.txt
│   └── Dockerfile
└── manifests/
    └── team-a-dev/
        └── flask-demo.yaml

6.2 创建 Argo CD Application

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: flask-demo
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://git.example.internal/platform-demo.git'
    targetRevision: main
    path: manifests/team-a-dev
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: team-a-dev
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

应用：

kubectl apply -f argocd-app.yaml

6.3 发布流程

完整链路就是：

开发提交代码
CI 构建镜像并推送 Harbor
CI 修改部署清单中的镜像 tag
Git 仓库合并变更
Argo CD 自动同步到集群
Kubernetes 执行滚动更新

用时序图看更直观：

sequenceDiagram
    participant Dev as 开发者
    participant Git as Git仓库
    participant CI as CI系统
    participant Harbor as Harbor
    participant Argo as Argo CD
    participant K8s as Kubernetes

    Dev->>Git: 提交代码
    Git->>CI: 触发构建
    CI->>Harbor: 推送镜像 v2
    CI->>Git: 更新 manifests 中镜像标签
    Argo->>Git: 拉取最新配置
    Argo->>K8s: 同步 Deployment
    K8s->>K8s: 滚动更新 Pod

第七步：逐步验证清单

很多人部署失败，不是不会装，而是没有“分层验证”的习惯。这里给一套我自己常用的检查顺序。

基础层

kubectl get nodes
kubectl get pods -A
kubectl cluster-info

确认：

节点都 Ready
CoreDNS、Calico、kube-proxy 正常

资源层

kubectl get ns
kubectl get quota -n team-a-dev
kubectl get limitrange -n team-a-dev
kubectl auth can-i create deployment --as=system:serviceaccount:team-a-dev:team-a-deployer -n team-a-dev

确认：

namespace 存在
quota/limit 生效
权限符合预期

应用层

kubectl get deploy,rs,pod,svc,ing -n team-a-dev
kubectl describe deploy flask-demo -n team-a-dev
kubectl logs -l app=flask-demo -n team-a-dev

确认：

Pod Ready
Service Endpoints 正常
Ingress 规则下发成功

入口层

kubectl get svc -n ingress-nginx
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller
curl -H "Host: flask-demo.example.internal" http://<INGRESS_IP>/

确认：

ingress controller 已接管流量
域名与 Host 匹配

常见坑与排查

这一部分很重要。很多文章只讲“怎么装”，但真正花时间的是“为什么不工作”。

1. Pod 一直 Pending

常见原因

节点资源不足
PVC 无法绑定
没有合适的 node selector / taint toleration
镜像拉取失败前的调度问题

排查命令

kubectl describe pod <pod-name> -n team-a-dev
kubectl get events -n team-a-dev --sort-by=.lastTimestamp

重点看：

0/3 nodes are available
Insufficient cpu
pod has unbound immediate PersistentVolumeClaims

2. Pod 启动后 CrashLoopBackOff

常见原因

启动命令错误
环境变量缺失
探针配置过于激进
应用监听端口不对

排查命令

kubectl logs <pod-name> -n team-a-dev
kubectl describe pod <pod-name> -n team-a-dev

经验建议

如果你是刚接入平台的新应用：

先不要急着配 livenessProbe
先让程序稳定跑起来
readinessProbe 可以先保守一点

我见过不少服务其实能正常启动，但因为探针太快，硬是被 Kubernetes 反复杀掉。

3. Ingress 配好了但访问不到

检查顺序

Ingress Controller 是否正常运行
IngressClass 是否匹配
Service 是否有 Endpoints
应用容器是否真的监听目标端口
域名解析或 Host 头是否正确

排查命令

kubectl get ingress -A
kubectl describe ingress flask-demo -n team-a-dev
kubectl get endpoints -n team-a-dev
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller

典型问题

ingressClassName: nginx 没写
Service targetPort 写错
容器实际监听 5000，YAML 写成 8080

4. Argo CD 不同步或状态异常

常见原因

Git 仓库不可达
清单路径错误
目标 namespace 不存在
RBAC 不允许 Argo CD 写入

排查命令

kubectl get applications -n argocd
kubectl describe application flask-demo -n argocd
kubectl logs -n argocd deploy/argocd-application-controller

5. 镜像拉取失败

常见原因

Harbor 证书不受信任
镜像仓库需要认证但未配置 imagePullSecret
镜像 tag 不存在

配置 imagePullSecret 示例

kubectl create secret docker-registry harbor-secret \
  --docker-server=harbor.example.internal \
  --docker-username=admin \
  --docker-password='your-password' \
  --docker-email='[email protected]' \
  -n team-a-dev

在 Deployment 中引用：

spec:
  template:
    spec:
      imagePullSecrets:
        - name: harbor-secret

安全/性能最佳实践

中型团队平台一开始就该做的，不是“最复杂”，而是“最基本”。

安全最佳实践

1. 不要默认给 cluster-admin

平台常见事故之一，就是图方便给一堆人集群管理员权限。建议：

日常发布只给 namespace 级权限
集群级资源由平台团队管理
生产环境采用更严格审批

2. 开启 NetworkPolicy

如果所有 Pod 默认互通，后面排查横向访问会非常麻烦。建议至少对生产命名空间增加默认限制。

示例：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: team-a-dev
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

3. Secret 不要直接明文进 Git

更好的方式：

Sealed Secrets
External Secrets Operator
对接 Vault / 云 KMS

4. 控制镜像来源

建议只允许：

官方基础镜像
内部 Harbor 仓库
扫描未通过的镜像禁止进入生产

5. 使用 Pod Security 标准

至少避免：

privileged 容器
hostPath 滥用
root 用户直接运行

示例容器安全上下文：

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true

性能最佳实践

1. 给请求和限制设合理默认值

如果所有服务都不配资源限制，最终一定会出现“某个服务把节点吃满”的问题。

建议：

默认 request 小一些，保障调度
limit 不要过分夸大
用监控数据持续修正

2. 不要过早上复杂服务网格

对于中型团队，Ingress + 应用级治理通常够用。
如果你还没有把日志、监控、发布流程理顺，就直接上 Istio，维护复杂度会陡增。

3. 监控 API Server 与 etcd

Kubernetes 平台本身也会“累”。重点关注：

API Server 延迟
etcd 磁盘性能
节点 CPU / 内存 / 磁盘 inode
CoreDNS QPS 与失败率

4. 控制命名空间与 CRD 扩张速度

开源组件装多了以后，CRD 数量会快速膨胀。要注意：

不必要的组件别装
先做 POC，再进生产
定期审查平台依赖

一个可演进的落地路线

如果你准备真的在团队里推广，我建议按下面的节奏推进。

阶段 1：最小可用

先有这些就够：

Kubernetes
Harbor
Ingress
Argo CD
Namespace + RBAC + 配额
监控

目标是：让一个团队能稳定发布应用。

阶段 2：标准化

补上：

应用模板
Helm/Kustomize 标准目录
发布规范
日志方案
证书管理
资源基线

目标是：让多个团队以统一方式接入。

阶段 3：平台化

再考虑：

自服务门户
发布审批
多集群管理
成本分析
策略控制（OPA/Gatekeeper/Kyverno）

目标是：减少平台团队重复劳动。

很多平台失败，不是技术不行，而是第一阶段就想把第三阶段全做完。

总结

如果你要为一个中型团队搭建容器编排平台，最重要的不是“把所有热门开源项目都装上”，而是抓住三件事：

以内核思维理解 Kubernetes
- 它本质上是声明式控制系统
- 平台能力要围绕 API 和控制回路扩展
先做最小闭环
- 集群
- 镜像仓库
- Ingress
- GitOps
- 权限与资源隔离
- 基础监控
用可演进架构替代一次性大而全
- 先解决发布问题
- 再解决标准化问题
- 最后才是自服务与治理深化

如果让我给一个最可执行的建议，那就是：

第一周：用 kubeadm 搭好集群，部署 ingress-nginx、metrics-server、Harbor、Argo CD
第二周：按团队维度划分 Namespace，补上 RBAC、Quota、LimitRange
第三周：选一个真实业务服务，完整跑通从代码到镜像到 GitOps 发布
第四周：加监控、日志和安全基线

边界条件也要说清楚：
如果你的团队没有人能维护 Kubernetes 控制面，或者业务规模还远没到需要平台化，那就不要急着自建。托管 Kubernetes + 简化交付链路，可能是更好的答案。

但如果你已经走到了“多团队、多环境、频繁发布、权限复杂”的阶段，那么基于 Kubernetes 开源项目搭建一套中型团队平台，确实是很值得投入的一步。

《从源码到部署：基于 Kubernetes 开源项目实现中型团队容器编排平台的实战指南》

从源码到部署：基于 Kubernetes 开源项目实现中型团队容器编排平台的实战指南

背景与问题

为什么“只有 Kubernetes”不够

中型团队平台的典型诉求

前置知识与环境准备

推荐环境

本文目标

核心原理

Kubernetes 的控制回路

从源码角度看关键组件

中型团队平台的参考架构

方案选型：为什么是这组开源项目

本文这套组合的取舍

什么情况下不适合本文方案

从源码到平台设计：我们需要补什么

1. 租户模型

2. 发布模型

3. 权限模型

实战代码（可运行）

第一步：安装 Kubernetes 集群

1.1 安装 containerd

1.2 安装 kubeadm、kubelet、kubectl

1.3 初始化 control-plane

1.4 安装网络插件 Calico

1.5 Worker 节点加入集群

1.6 验证

第二步：部署平台基础组件

2.1 安装 ingress-nginx

2.2 安装 metrics-server

2.3 安装 Argo CD

第三步：创建团队级命名空间与权限

3.1 创建 Namespace、ResourceQuota、LimitRange

3.2 创建只允许管理本命名空间的 Role

第四步：部署一个示例应用

4.1 示例应用代码

4.2 requirements.txt

4.3 Dockerfile

4.4 构建并推送镜像

第五步：编写 Kubernetes 部署清单

5.1 Deployment + Service + Ingress

第六步：接入 GitOps 持续部署

6.1 应用仓库目录结构建议

6.2 创建 Argo CD Application

6.3 发布流程

第七步：逐步验证清单

基础层

资源层

应用层

入口层

常见坑与排查

1. Pod 一直 Pending

常见原因

排查命令

2. Pod 启动后 CrashLoopBackOff

常见原因

排查命令

经验建议

3. Ingress 配好了但访问不到

检查顺序

排查命令

典型问题

4. Argo CD 不同步或状态异常

常见原因

排查命令

5. 镜像拉取失败

常见原因

配置 imagePullSecret 示例

安全/性能最佳实践

安全最佳实践

1. 不要默认给 cluster-admin

2. 开启 NetworkPolicy

3. Secret 不要直接明文进 Git

4. 控制镜像来源

5. 使用 Pod Security 标准

性能最佳实践

1. 给请求和限制设合理默认值

2. 不要过早上复杂服务网格

3. 监控 API Server 与 etcd

4. 控制命名空间与 CRD 扩张速度