1. Kubernetes 初印象:从零认识容器编排系统
第一次接触Kubernetes(简称K8s)是在2017年的一次系统迁移项目中。当时我们的微服务架构已经发展到30多个容器实例,手工管理这些容器的启动、停止、扩缩容和网络配置变得异常痛苦。直到某天凌晨3点,又一次因为容器IP冲突导致服务雪崩后,团队终于下定决心拥抱这个当时还略显神秘的容器编排系统。
Kubernetes本质上是一个开源的容器编排平台,它最初由Google设计开发,现在由云原生计算基金会(CNCF)维护。它的核心价值在于:让开发者能够像管理单个应用程序一样管理成百上千的容器集群。想象一下,你有一个由数十个微服务组成的电商系统,每个服务可能有多个实例运行在不同服务器上。Kubernetes就像是一个智能的交通管制系统,自动处理这些服务实例的部署、网络通信、故障恢复和资源分配。
提示:Kubernetes名称源自希腊语,意为"舵手"或"飞行员",项目缩写K8s中的"8"代表中间省略的8个字母(ubernete),这是技术领域常见的数字缩写方式。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Kubernetes 核心架构解析
2.1 控制平面(Control Plane)组件
Master节点是Kubernetes集群的大脑,包含以下关键组件:
-
API Server:集群的"前门",所有操作指令和状态查询都通过这个REST接口完成。我们团队曾因为不了解其无状态特性,错误地将生产环境的API Server部署为单实例,导致集群控制面完全不可用。
-
etcd:高可用的键值存储数据库,保存整个集群的状态数据。记得在配置etcd集群时,奇数节点数量(3、5、7)对维持quorum至关重要。我们曾因误删etcd数据导致整个集群重建,现在都会定期备份etcd数据。
-
Controller Manager:负责维护集群状态的守护进程,比如确保指定数量的Pod副本始终运行。在节点故障时,正是它触发重新调度流程。
-
Scheduler:决定将Pod放在哪个Node上运行。我们曾通过自定义调度策略,实现将数据库Pod优先调度到SSD存储节点。
2.2 工作节点(Worker Node)组件
-
kubelet:节点上的"Pod管家",负责与API Server通信并管理容器运行时。曾遇到因kubelet版本不匹配导致Pod无法启动的问题,现在严格执行版本一致性检查。
-
kube-proxy:维护节点网络规则,实现Service的IP映射和负载均衡。理解其底层使用的iptables或ipvs规则对排查网络问题很有帮助。
-
容器运行时:实际运行容器的软件,如Docker、containerd等。我们生产环境已从Docker迁移到containerd,资源开销降低约15%。
3. Kubernetes 核心概念详解
3.1 Pod:最小部署单元
Pod是Kubernetes中最小的可部署单元,代表集群中运行的一个或多个容器。关键特性包括:
- 共享网络命名空间:同一个Pod中的容器通过localhost直接通信
- 共享存储卷:Pod级别的Volume可被所有容器挂载
- 生命周期一致性:Pod内所有容器同时创建和销毁
典型的多容器Pod用例:主应用容器+日志收集sidecar容器。我们曾通过这种模式实现零侵入式的日志集中管理。
3.2 Deployment:声明式更新
Deployment是管理Pod副本集的更高级抽象,支持:
- 滚动更新:逐步用新版本替换旧版本Pod
- 回滚机制:一键回退到历史版本
- 副本数维护:自动确保指定数量的Pod运行
示例Deployment配置片段:
yaml复制apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
3.3 Service:稳定的网络端点
Service解决Pod动态IP带来的连接问题,主要类型包括:
- ClusterIP:集群内部虚拟IP(默认类型)
- NodePort:通过节点端口暴露服务
- LoadBalancer:使用云提供商的负载均衡器
- ExternalName:映射到外部DNS名称
我们常用的一种模式是通过Headless Service(clusterIP: None)实现有状态服务的直接Pod访问。
4. Kubernetes 集群部署实践
4.1 单Master集群部署(以CentOS为例)
生产环境推荐至少3个Master节点,但开发测试可以使用单Master配置:
-
环境准备:
- 关闭swap:
swapoff -a并注释/etc/fstab中的swap行 - 设置主机名解析:确保所有节点能互相解析主机名
- 开放必要端口:6443、2379-2380、10250等
- 关闭swap:
-
安装容器运行时(以containerd为例):
bash复制yum install -y containerd systemctl enable --now containerd -
安装kubeadm、kubelet和kubectl:
bash复制cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF yum install -y kubelet kubeadm kubectl systemctl enable --now kubelet -
初始化Master节点:
bash复制
kubeadm init --pod-network-cidr=10.244.0.0/16 -
安装网络插件(以Flannel为例):
bash复制
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
4.2 节点加入集群
在Worker节点执行Master初始化时输出的join命令:
bash复制kubeadm join <master-ip>:6443 --token <token> --discovery-token-ca-cert-hash <hash>
注意:token默认24小时有效,过期后可通过
kubeadm token create --print-join-command生成新命令。
5. Kubernetes 日常运维要点
5.1 监控方案实施
Prometheus是Kubernetes监控的事实标准,典型部署步骤:
-
安装Prometheus Operator:
bash复制
kubectl apply -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/main/bundle.yaml -
部署Prometheus实例:
yaml复制apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: main namespace: monitoring spec: serviceAccountName: prometheus serviceMonitorSelector: matchLabels: team: frontend resources: requests: memory: 400Mi -
配置Grafana可视化:
bash复制
kubectl apply -f https://raw.githubusercontent.com/grafana/helm-charts/main/charts/grafana/values.yaml
5.2 日志收集方案
EFK(Elasticsearch+Fluentd+Kibana)是常见选择:
-
部署Elasticsearch:
bash复制
kubectl apply -f https://download.elastic.co/downloads/eck/2.6.1/crds.yaml kubectl apply -f https://download.elastic.co/downloads/eck/2.6.1/operator.yaml -
部署Fluentd DaemonSet:
yaml复制apiVersion: apps/v1 kind: DaemonSet metadata: name: fluentd namespace: logging spec: selector: matchLabels: name: fluentd template: spec: containers: - name: fluentd image: fluent/fluentd-kubernetes-daemonset:v1.14.3-debian-elasticsearch7-1.1 env: - name: FLUENT_ELASTICSEARCH_HOST value: "elasticsearch.logging.svc.cluster.local"
6. Kubernetes 进阶概念
6.1 Custom Resource Definitions (CRD)
CRD允许扩展Kubernetes API,创建自定义资源类型。例如创建一个CronTab资源:
-
定义CRD:
yaml复制apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: cronSpec: type: string image: type: string replicas: type: integer scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab shortNames: - ct -
创建自定义资源实例:
yaml复制apiVersion: "stable.example.com/v1" kind: CronTab metadata: name: my-cron-tab spec: cronSpec: "* * * * */5" image: my-awesome-cron-image replicas: 3
6.2 Operator 模式
Operator是将领域知识编码到软件中的方法,典型结构包括:
- Controller:监视资源状态变化
- Reconciler:将当前状态调整为期望状态
- Admission Webhooks:验证和修改资源创建/更新请求
我们曾开发一个数据库Operator,自动处理备份、版本升级和故障转移,将DBA的日常管理工作量减少了70%。
7. Kubernetes 与 Docker 的关系演变
早期Kubernetes依赖Docker作为容器运行时,但现在的架构更加模块化:
- Docker → containerd:Kubernetes不再直接使用Docker引擎,而是通过containerd与容器交互
- CRI(Container Runtime Interface):标准化容器运行时接口,支持多种实现
- 当前推荐架构:
- Kubernetes → CRI → containerd → runc
- 完全移除Docker守护进程
迁移注意事项:
- 容器镜像仍然兼容(都遵循OCI标准)
- 日志和监控配置需要调整(不再有Docker日志驱动)
- 网络插件可能需要重新配置
8. 命名空间(Namespace)隔离实践
命名空间是Kubernetes中实现资源隔离的重要机制:
-
多团队共享集群时,为每个团队创建独立namespace
-
资源配额管理:
yaml复制apiVersion: v1 kind: ResourceQuota metadata: name: team-a-quota namespace: team-a spec: hard: pods: "50" requests.cpu: "20" requests.memory: 100Gi limits.cpu: "40" limits.memory: 200Gi -
同名服务部署:不同namespace下可以部署同名服务,通过
<service-name>.<namespace>.svc.cluster.local形式访问
我们曾通过namespace实现开发、测试、预发布环境的隔离,配合NetworkPolicy实现网络层面的隔离控制。
