K8S RD: Kubernetes核心概念与运维实践详解

本文全面梳理Kubernetes资源类型、架构组件与关键运维机制

Pod资源的核心特性

• 最小工作单元，用于部署服务的基础载体。

• 包含一个或多个容器（类比“花生壳”为Pod，“花生仁”为容器），支持单容器或多容器部署。

• 多容器场景适用于需紧密协作的服务（如日志收集器Sidecar与主应用）

• 但单容器Pod更易管理副本数。Pod直接运行应用实例，副本数量由控制器维护

  # Pod示例：单容器Pod  
  apiVersion: v1  
  kind: Pod  
  metadata:  name: nginx-pod  
  spec:  containers:  - name: nginx-container  image: nginx:1.21  ports:  - containerPort: 80  
  

控制器类型及作用

• ReplicaSet (RS)：

  • 核心作用：确保Pod副本数始终匹配预设值（如3副本），自动替换故障Pod。
  • 局限：需手动删除旧Pod以更新镜像版本。

• Deployment：

  • 升级替代RS：支持滚动更新（无需手动删除Pod）、版本回滚
  • 适用场景：无状态应用（如Web服务）
  • 实践意义：替代RS成为无状态应用标准控制器

• DaemonSet：

  • 核心场景：确保集群所有Node节点部署相同Pod（如日志采集Agent、节点监控工具）。
  • 核心作用：确保所有Node节点运行同一Pod（如日志采集Agent）。
  • 特点：无副本数概念，每节点固定部署一个Pod。
  • 典型应用：filebeat、node-exporter的集群级部署。

• StatefulSet：

  • 针对性场景：管理有状态应用（如MySQL主从、Redis集群）。
  • 核心能力：管理有状态应用（如MySQL集群、Redis哨兵），保障：
    • Pod启动顺序与唯一网络标识（如mysql-0，mysql-1）
    • 持久化存储绑定（PVC随Pod迁移自动关联）
  • 风险提示：生产环境数据库慎用，避免数据安全风险
  • 关键能力：
    • 严格容器启动顺序（如先主后从）。
    • 绑定持久化存储（PVC）。
  • 注意：敏感数据库通常不部署于Kubernetes（数据安全考量）

Service与Ingress机制之服务暴露与配置资源

• Service：

  • 核心功能：提供统一访问入口，通过标签匹配后端Pod，为多副本Pod提供统一入口，通过标签选择器关联后端Pod，实现负载均衡（默认轮询）。
  • 解决痛点：Pod IP动态变化，Service提供稳定访问端点。
  • 功能本质：通过标签选择器聚合Pod，提供：
    • 统一访问入口（ClusterIP）
    • 负载均衡（默认轮询策略）
    • IP漂移容错（解耦Pod生命周期与访问端点）
    • 示例配置片段：

      kind: Service 
      spec:selector:app: nginx  # 关联标签为app:nginx的Podports:- protocol: TCP port: 80    # Service端口targetPort: 80  # Pod端口
      

• Ingress与Ingress Controller：

  • Ingress Controller：部署反向代理服务（如Nginx），提供基础代理能力。
  • Ingress资源：定义路由规则（如域名、路径），（域名→Service），动态修改代理配置，修改Ingress Controller配置，组合实现外部域名访问集群服务
  • 协作流程：
    • 用户创建Ingress规则（关联Service）。
    • Ingress Controller监听规则变化并更新代理配置。
    • 外部流量通过域名暴露服务。

示例

Ingress示例：路由到Nginx Service  
apiVersion: networking.k8s.io/v1  
kind: Ingress  
metadata:  name: nginx-ingress  
spec:  rules:  - host: nginx.example.com  http:  paths:  - path: /  pathType: Prefix  backend:  service:  name: nginx-service  port:  number: 80  

配置与安全资源

• ConfigMap：

  • 解耦应用配置，集中管理配置文件内容。
  • Pod挂载ConfigMap后，所有副本同步更新配置。
  • 适用场景：多副本Pod的统一配置管理（如数据库连接参数）。

    # 示例：ConfigMap定义 
    apiVersion: v1
    kind: ConfigMap
    metadata:name: app-config 
    data:config.properties: |db.host=mysql-service db.port=3306
    

• Secret：

  • 存储加密数据（如账号密码），避免明文暴露。
  • 安全实践：存储加密敏感数据（如数据库凭证），Base64编码避免明文暴露

    # 示例：Secret定义（Base64编码）
    apiVersion: v1 
    kind: Secret
    metadata:name: db-credentials
    type: Opaque 
    data:username: YWRtaW4=  # admin password: cGFzc3dvcmQ=  # password 
    

• ServiceAccount：

  • 权限控制：为Pod分配RBAC身份，限制其对K8s API的操作权限。
  • 服务账号，为Pod分配账号，用于Kubernetes认证与权限控制（绑定Role/RoleBinding）。

健康检查与故障处理机制

1 ) 健康检查类型

• LivenessProbe（存活检查）：
  • 检测Pod不健康时自动重启容器。
• ReadinessProbe（就绪检查）：
  • 检测异常时将Pod标记为不可用（不重建/重启），避免流量导入故障Pod。
  • 行为：检测失败时将Pod移出Service负载池，保障流量仅转发至健康实例

示例

# 健康检查示例  
livenessProbe:  httpGet:  path: /healthz  port: 8080  initialDelaySeconds: 15  
readinessProbe:  tcpSocket:  port: 80  periodSeconds: 10  exec:command: ["cat", "/tmp/healthy"]

2 ) Pod重启策略

策略	触发条件
Always	容器退出即重启（默认策略）
OnFailure	仅容器故障退出时重启
Never	永不重启

Kubernetes架构与组件作用

1 ) Master节点组件

• API Server：集群统一入口，接收所有REST请求。
• Controller Manager：核心控制循环，维护集群状态（如副本数）。
• Scheduler：调度Pod到Node，基于资源评估（预选/优选策略）。

2 ) Node节点组件

• Kubelet：管理Pod生命周期（创建/删除），向Master上报节点状态。
• Kube-proxy：实现Service负载均衡与服务发现。

3 ) 公共组件

• ETCD：存储集群所有元数据（唯一数据存储位置）。
• CNI网络插件（如Calico、Flannel）：为Pod分配IP，提供Overlay网络。
• CoreDNS：集群内部DNS解析与服务发现。

Kubernetes架构组件

组件	节点类型	核心作用
API Server	Master	集群统一入口，接收所有REST操作请求。
Controller Manager	Master	维护集群状态（如节点监控、Pod副本数）。
Scheduler	Master	调度Pod至合适Node（基于资源需求、亲和性）。
kubelet	Node	管理Pod生命周期（创建/删除），向Master报告节点状态。
kube-proxy	Node	实现Service负载均衡（iptables/IPVS规则）。
etcd	独立部署	存储集群所有数据（如Pod、Service配置）。
CNI插件	集群范围	提供Pod网络（如Calico、Flannel），分配Pod IP。
CoreDNS	集群范围	提供集群内部DNS解析，支持服务发现。

高可用架构设计与实现

节点类型	核心组件	核心职能
Master	API Server	集群访问入口，REST API网关
	Controller Manager	维护资源状态（如副本数/节点监控）
	Scheduler	调度策略执行（资源评估/节点选择）
Node	Kubelet	Pod生命周期管理（创建/销毁/状态上报）
	Kube-Proxy	实现Service负载均衡（iptables/IPVS规则生成）
公共层	etcd	分布式键值存储，持久化集群状态
	CNI插件	Pod网络分配与管理（如Calico/Flannel）
	CoreDNS	集群内服务域名解析

高可用必要性

• API Server为单点瓶颈，需通过多Master节点避免集群不可用。
• 核心目标：确保API Server高可用（集群入口），API Server为单点瓶颈，需通过多Master节点避免集群不可用

典型架构：

• 架构：3个Master节点 + N个Worker节点（例：50台）
• 3个Master节点部署API Server、Controller Manager、Scheduler
  • 通过kube-apiserver负载均衡对外服务
• 使用HAProxy + Keepalived代理API Server流量：
  • Node节点连接HAProxy虚拟IP（而非直接连Master）
  • Master故障时自动切换
  • 实现VIP漂移与API Server流量分发

部署方式：

• 二进制部署：手动配置HAProxy代理
• kubeadm部署：初始化后通过kubeadm join添加Master节点（指定控制平面角色）
  • 示例：新Master加入命令：kubeadm join --control-plane（需初始化令牌）

注意事项

• 初始化首个Master后，其他Master以控制平面身份加入集群
• Worker节点以工作节点身份加入

存储与持久化机制

1 ) PV（PersistentVolume）访问模式

模式	说明
ReadWriteOnce (RWO)	单节点读写
ReadWriteMany (RWX)	多节点同时读写
ReadOnlyMany (ROX)	多节点只读

2 ) PV与PVC关联流程

• 顺序：

  graph LR 
  A[Pod] -->|挂载| B(PVC)
  B -->|匹配容量/访问模式| C(PV)
  C -->|绑定| D[底层存储<br>（HostPath/NFS/Ceph）]
  

• PVC：声明存储需求（容量、访问模式）。
• PV：提供具体存储后端实现。

示例：

# 示例：Pod挂载PVC 
apiVersion: v1
kind: Pod 
metadata:name: mysql-pod 
spec:volumes:- name: mysql-storage persistentVolumeClaim:claimName: mysql-pvc  # 关联PVC containers:- name: mysqlimage: mysql:5.7volumeMounts:- mountPath: "/var/lib/mysql"name: mysql-storage 

关键运维策略

1 ）镜像拉取策略：

策略	行为描述
Always (默认)	总是从仓库拉取最新镜像
IfNotPresent	本地不存在时拉取
Never	仅使用本地镜像（需预分发）

推荐镜像策略配置

spec:  containers:  - name: nginx  imagePullPolicy: IfNotPresent  

2 ）Pod重启策略：

策略	适用场景
Always	故障时自动重启（默认）
OnFailure	仅容器异常退出时重启
Never	不重启（用于批量任务）

3 ）PV访问模式：

模式	存储卷特性
ReadWriteOnce	单节点读写（RWO）
ReadOnlyMany	多节点只读（ROX）
ReadWriteMany	多节点读写（RWX）

4 ）PV/PVC关联流程：

顺序：Pod → PVC → PV → 底层存储。

存储后端支持：HostPath（开发测试）、NFS（中小集群）、Ceph/GFS（生产级分布式存储）。

5 ）服务暴露：

• Headless Service：
  • 无ClusterIP，直接通过Pod IP访问（用于StatefulSet或DNS发现）

6 ）故障排查链：

• Pod状态异常 → 检查控制器副本数 → 验证Node资源 → 查看kubelet日志

Docker与运维实践

1 ) 构建镜像：

# 语法 
docker build -t my-image:tag -f Dockerfile .  # 传参示例：--build-arg KEY=VALUE# 示例
docker build -t myapp:v1 --build-arg APP_VERSION=1.0 .  

2 ) 运行容器：

docker run -d --name myapp \  -v /host/data:/container/data \  --network host \  myapp:v1  

上面 --network host 等同于 --net=host

3 ) Harbor部署：

• 在线安装：curl -sSL https://github.com/goharbor/harbor/releases/download/v2.5.0/harbor-online-installer-v2.5.0.tgz | tar -xz
• 离线安装：下载离线包后执行./install.sh

Dockerfile核心指令

指令	作用	示例
FROM	指定基础镜像	FROM ubuntu:20.04
WORKDIR	设置容器工作目录	WORKDIR /app
ARG	定义构建时变量（构建阶段生效）	ARG VERSION=1.0
ENV	设置容器环境变量（运行时生效）	ENV APP_ENV=production
RUN	执行构建命令	RUN apt-get update && apt-get install -y nginx
EXPOSE	声明服务监听端口	EXPOSE 8080
CMD	容器启动命令（可被docker run覆盖）	CMD ["nginx", "-g", "daemon off;"]
ENTRYPOINT	入口命令（不会被覆盖，与CMD参数拼接）	ENTRYPOINT ["java", "-jar"]

关键区别：

• CMD：默认命令可被docker run参数覆盖，多指令时最后一条生效。
• ENTRYPOINT：固定入口命令，docker run参数作为附加参数拼接执行。

安全与访问控制

1 ) 认证方式

• X.509证书认证：用户级访问。
• ServiceAccount认证：服务级访问，需绑定Role/RoleBinding。

2 ) 访问三关口

1. 认证（Authentication）：验证身份（证书/Token）。
2. 授权（Authorization）：RBAC权限校验（Role绑定操作权限）。
3. 准入控制（Admission Control）：资源配额/安全策略限制，如LimitRange。

鉴权流程

• 三阶验证链：
• RBAC核心组件：Role（权限集）、RoleBinding（绑定角色与账号）。

3 ) 证书分类

• ETCD集群证书：节点间通信加密。
• 集群数据存储：所有状态信息持久化于etcd
• API Server → ETCD证书：APIServer访问ETCD的凭证。
• 外部访问证书：用户或服务访问APIServer的凭证。

总结：Kubernetes运维需深度掌握资源对象作用（如Pod/Deployment/Service）、高可用架构（多Master+代理）、存储设计（PV/PVC绑定）及安全机制（认证/授权）。通过ConfigMap/Secret实现配置解耦，结合健康检查与重启策略保障服务韧性，是构建稳定集群的核心实践。