1. 容器编排与Kubernetes的"前世今生"

当Docker在2013年横空出世时,开发者们像是拿到了神奇的"集装箱"。但随着微服务架构的普及,手工管理成千上万个容器就像在港口手动调度无数集装箱一样不切实际。这时Kubernetes就像一位精明的港口调度员应运而生。

举个真实案例:某电商公司在促销期间需要快速扩展500个订单处理容器。使用原生Docker需要手动编写脚本调整容器数量,而Kubernetes只需要执行一行命令:

# 使用kubectl伸缩部署的副本数(技术栈:kubectl v1.28)
kubectl scale deployment order-service --replicas=500

2. Kubernetes核心概念"全家桶"

2.1 Pod:最小调度单位

Pod就像太空舱中的宇航员小组,共享生存环境但各司其职。比如一个Web应用Pod可能包含:

  • 主应用容器
  • 日志收集sidecar容器
  • 配置同步init容器
# web-app-pod.yaml(技术栈:Kubernetes v1.28)
apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  initContainers:
  - name: config-sync
    image: busybox
    command: ['sh', '-c', 'git clone https://config-repo /config']
  containers:
  - name: web-server
    image: nginx:1.25
    ports:
    - containerPort: 80
  - name: log-agent
    image: fluentd:1.16

2.2 Deployment:应用的"时光机器"

Deployment实现了"后悔药"功能,轻松回滚到任意版本。下面的示例展示了如何创建带滚动更新的部署:

# frontend-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 3
  revisionHistoryLimit: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: nodejs
        image: my-registry/frontend:v1.2.3
        livenessProbe:
          httpGet:
            path: /health
            port: 3000

3. 单节点集群搭建实战(技术栈:kubeadm + Docker)

3.1 环境准备"三步走"

# 禁用交换分区(永久生效)
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
sudo swapoff -a

# 安装Docker引擎
curl -fsSL https://get.docker.com | sh
sudo systemctl enable --now docker

# 配置kubeadm仓库
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/repodata/repomd.xml.key
EOF

3.2 集群初始化"魔法时刻"

sudo kubeadm init --pod-network-cidr=10.244.0.0/16 \
--apiserver-advertise-address=192.168.1.100 \
--cri-socket unix:///var/run/cri-dockerd.sock

# 输出中的关键信息记得保存!
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

3.3 网络插件:集群的"神经系统"

选择Flannel作为CNI插件:

kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

# 验证网络状态
kubectl get pods -n kube-system -l app=flannel

4. Kubernetes的"七十二变"应用场景

4.1 开发者的"随身实验室"

本地开发环境部署示例:

# 创建开发命名空间
kubectl create ns dev-env

# 部署带热更新的开发容器
kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-dev
  namespace: dev-env
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: node-dev
    spec:
      containers:
      - name: node
        image: node:18
        command: ["/bin/sh", "-c"]
        args: ["npm install && npm run dev"]
        volumeMounts:
        - mountPath: /app
          name: code-volume
      volumes:
      - name: code-volume
        hostPath:
          path: /home/dev/project
          type: Directory
EOF

5. 技术"优劣观"

5.1 优势亮点

  • 自动愈合:节点故障时自动迁移工作负载
  • 弹性伸缩:支持CPU/Memory自定义指标伸缩
  • 多云编排:统一管理不同云厂商的集群

5.2 成长痛点

  • 学习曲线:YAML配置需要记忆大量字段
  • 资源消耗:单个节点建议至少2核4GB内存
  • 网络配置:CNI插件的选择影响集群性能

6. 避坑指南(重点!)

6.1 版本"适配症"

不同组件的版本兼容矩阵:

Kubernetes Docker etcd CNI插件
1.28 20.10+ 3.5 Flannel 0.22
1.27 20.10 3.4 Calico 3.26

6.2 存储"黑洞"

持久化存储的正确姿势:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
  - ReadWriteOnce
  hostPath:
    path: /data/mysql

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

7. 结语与展望

经过本次实践,我们完成了从理论到落地的完整旅程。单节点集群虽然不适合生产环境,但作为学习和开发的原型环境绰绰有余。未来随着Kubernetes的持续进化,我们可能看到更多类似K3s这样的轻量级发行版,以及Operator模式的进一步普及。