kubernetes原理及使用

kubernents核心架构

控制平面是就集群的大脑，负责全局决策，通常部署在独立的服务器或虚拟机上，为保证高可用，一般会部署多个副本

一、控制平台核心组件

1.API server

集群的信息传递者，所有操作都通过API server执行，负责接受用户请求，验证请求合法性，将请求存到etcd中

2.etcd

集群唯一的数据存储中心，负责所有的状态信息（存储用户请求的期望状态，组件通过监听etcd中的期望状态来调和实际状态、节点信息、配置等），其他组件通过API server 间接读写etcd

3.Controller Manager

集群的控制器集合，，负责监控集群状态，，确保实际状态和etcd中的期望状态一致（自愈能力的核心）

3.1 Deployment

负责管控无状态的应用，例如nginx、tomcat等web类型，支持滚动更新、回滚、自愈（依赖replicset）

3.2StatefulSet

负责管理有状态的应用，例如MySQL、redis等，支持每个pod独立挂载一个卷（持久化），

3.3DaemonSet

确保所有节点都运行一个相同的pod（日志、监控）

3.4Job/cronJob

管理一次性任务，或者定时任务（删除、备份）

4.scheduler

集群的调度器，有新的pod需要创建时，通过节点的资源、亲和性、硬件约束等去挑选一个最合适的节点并通过API server存储到etcd中

二、节点

1.kubelet

节点的管家。运行在每个节点上，负责与控制面板通信，确保容器安装pod的定义在节点上正常运行，定期向API server 汇报节点和pod状态

2.kube-proxy

节点的网络代理，负责维护节点的网络规则，pod与service之间的通信与pod之间的负载均衡，底层逻辑是iptables或者ipvs

3.容器运行时

负责运行容器的软件、如containerd、CRI-O等，负责容器的创建、启动、停止等生命周期的管理

三、k8s的核心概念和原理

k8s通过一系列的抽象概念实现对容器的编排，核心围绕期望状态与实际状态的调和展开

1.pod pod是k8s的最小管控单元，包含一个或者多个紧密关联的容器、pod是临时的，重启后ip可能变化 ，通常不之间创建pod，而是通过创建控制器管理

2.Server 为pod提供固定的访问入口，解决pod动态变化（创建/销毁）导致的访问问题（通过label），通过kube-proxy实现负载均衡

3.Namespace 集群的隔离空间，用于隔离不同的环境，比如开发、生产、测试

4.Label与selector Label是键值对的标签，用于标记资源，selector通过Label筛选资源（service通过Label关联pod）

核心工作原理

1.用户提交请求

用户通过kubectl命令、API或者UI工具，向API server 提交定义资源，描述期望状态

2.状态存储

API server 验证请求和理性，将期望状态存储到etcd中

3.控制器调和

controller Manager 通过实时监听etcd中的期望状态，与实际状态对比，若有差异，则进行调和动作（如创建pod、删除pod）

4.调度pod

如果需要创建pod则controller通过API server通知scheduler进行节点的选择（资源、亲和性、硬件），选好之后通过API server存储到etcd中

5.节点执行

kubelet 通过监听etcd得知需要在本节点运行新的pod，则调用容器进行时创建启动容器，同时kubeclet定时向API server汇报pod和节点的状态

6.网络与服务发现

kube-proxy 根据server的定义，在节点上配置网络规则（如iptables），实现pod与service之间的通信，pod间 的负载均衡

7.自愈能力：若节点故障或者pod异常，kubelet会上报状态，控制器发现实际状态和期望状态不符后，自动在新的节点重新创建pod，恢复期望状态

k8s优势

1.自动化运维：

自动处理部署、扩缩容、滚动更新、故障恢复、减少人为操作

2.弹性伸缩：

通过 HPA（Horizontal Pod Autoscaler）根据 CPU 使用率、自定义指标自动调整 Pod 数量。

3.高可用：

控制平面多副本部署 + 节点故障自动恢复，确保集群稳定运行。

4.可扩展性：

支持自定义资源（CRD）和控制器，满足复杂业务需求。

5.跨环境兼容：

可运行在物理机、虚拟机、公有云、私有云等多种环境，实现 “一次部署，到处运行”。

pod的状态

1. Pending（挂起）

• 含义：表示 Pod 已经被 Kubernetes 系统接受，但有一些条件尚未满足，导致还不能被调度到节点上运行 ，或者正在从镜像仓库拉取容器镜像。
• 常见原因：资源不足（如节点上 CPU、内存等资源不够分配给该 Pod ）；镜像拉取失败（如镜像仓库不可访问、镜像名错误、权限问题 ）；Pod 的亲和性或反亲和性规则无法满足（例如指定了只能调度到特定标签的节点，但集群中没有符合要求的节点 ）。

2. Running（运行中）

• 含义：Pod 已经被调度到节点上，并且 Pod 内所有容器都已被创建，至少有一个容器正在运行、处于启动状态或者正在重启状态。
• 检查方式：可以使用kubectl describe pod 命令查看 Pod 的详细信息，确认容器是否按预期运行，以及是否有相关的运行日志和事件记录。

3. Succeeded（成功）

• 含义：Pod 内所有容器都成功执行并且已经退出，不会再重启 。通常用于批处理任务类型的 Pod，比如一次性的数据处理作业、脚本运行等，当任务执行完成且没有错误时，Pod 会进入该状态。
• 应用场景：在数据迁移场景中，可以创建一个包含数据迁移脚本的 Pod，当脚本执行完毕，数据迁移成功，Pod 就会进入 Succeeded 状态。

4. Failed（失败）

• 含义：Pod 内所有容器都已终止，并且至少有一个容器是以失败状态退出 。失败原因可能是容器内应用程序崩溃（如代码出现未捕获的异常 ）、执行错误命令、资源不足（如内存溢出导致容器被 OOM Killer 杀死 ）等。
• 排查方法：通过kubectl logs 查看容器日志，定位具体错误信息；使用kubectl describe pod 查看 Pod 的事件记录，了解失败的详细过程。

5. Unknown（未知）

• 含义：由于某种原因，Kubernetes 无法获取 Pod 的状态信息，比如与 Pod 所在节点的通信出现故障，导致 kubelet 无法向 API Server 汇报 Pod 状态。
• 可能情况：节点宕机、网络故障（节点与 API Server 之间的网络中断 ）、kubelet 服务异常等。此时可以检查节点状态（kubectl get nodes ），查看节点的事件记录（kubectl describe node  ），以及排查网络连接是否正常。

6. CrashLoopBackOff（崩溃循环后退）

• 含义：这并非是 Kubernetes API 直接定义的 Pod 状态，而是一种常见的现象，表明 Pod 中的容器不断崩溃并重启。通常是由于容器启动后执行的命令出错，或者应用程序在运行过程中遇到严重错误导致退出，然后 Kubernetes 会根据容器的重启策略（默认是 Always ）重新启动容器，形成循环。
• 解决思路：和 Failed 状态类似，通过kubectl logs 查看容器日志，分析导致容器崩溃的具体原因，如代码逻辑错误、依赖缺失等，然后针对性地修复问题。

k8s的网络模型特点

1.每一个pod有自己的ip，无需再pod之间创立连接、也不需要再容器端口映射到主机端口

2.一个节点的pod可以与所有节点的pod进行通信，不需要NAT转换

3.节点上的代理（例如kubelet）可以与该节点的所有pod进行通信

4.pod中的容器共享他们的网络命名空间（ip和MAC地址），因此可以通过loopback地址相互通信

K8S四种网络模式

一、容器与容器之间

同一pod下的容器共享同一个网络命名空间。例如IP、端口空间、和网络接口，容器间可以通过pod的ip+端口直接访问 ，无需经过网络转发或者外部网络插件，通信效率极高

二、pod与pod之间

pod与pod之间通信直接通过ip访问就行，因为每个pod会由节点分配到一个唯一的ip（通常由网络插件分配），不依赖主机或节点的网络配置

通过网络插件（CNI、Flannel、Weave Net等）给pod分配ip地址，并配置虚拟网络

Pod 间可通过 IP 直接通信，但实际中通常结合 k8s 的 Service 资源实现动态发现（通过 Service 名称解析到 Pod IP）

通信方式

• 直接 IP 通信：Pod A 通过 Pod B 的集群 IP 直接发送数据包（由网络插件负责跨节点路由）。

• Service 代理：通过 Service 的虚拟 IP（ClusterIP）转发到后端 Pod（k8s 内置 kube-proxy 负责负载均衡）

三、pod与外部网络的访问

pod访问集群外部的网络（互联网、外部数据库），需要通过节点的网络接口进行NAT，将pod的私有IP转换为节点的公网或宿主机的ip

实现方式：

SNAT(源地址转换)：网络插件或节点内核配置SNAT规则，当pod访问外部网络时。数据包的源IP（pod IP）被替换为节点的IP。外部响应则通过节点转发返回pod

直接路由： 部分网络插件（如Calico）支持将Pod IP直接路由到外部

典型场景

• Pod 拉取外部镜像（如 Docker Hub）。
• 应用 Pod 调用第三方 API（如支付接口、天气 API）

外部网络访问 Pod 模式（入网）

核心原理外部网络（如用户、其他集群）需要访问集群内的 Pod，通常通过 k8s 的 

Service 资源暴露 Pod 服务，常见方式包括 NodePort、LoadBalancer、Ingress 等。

主要方式

1. NodePort：

• • 在集群所有节点上开放一个静态端口（默认范围 30000-32767），外部通过 节点 IP:NodePort 访问，流量由 kube-proxy 转发到后端 Pod。
  • 示例：外部通过 192.168.1.100:30080 访问集群内的前端服务。

1. LoadBalancer：

• • 依赖云服务商（如 AWS、GCP、阿里云）的负载均衡器，自动分配一个公网 IP，外部通过该 IP 访问，流量经负载均衡器转发到 Service，再到 Pod。
  • 适用于生产环境，支持自动扩缩容和高可用。

1. Ingress：

• • 通过 Ingress 控制器（如 Nginx Ingress、Traefik）管理 HTTP/HTTPS 流量，外部通过域名访问，Ingress 规则将请求路由到对应的 Service 和 Pod。
  • 支持路径转发、SSL 终止、域名绑定等高级功能，适合 HTTP 服务暴露。

1. HostNetwork：

• • Pod 直接使用节点的网络命名空间（共享节点的 IP 和端口），外部可通过 节点 IP:端口 直接访问 Pod（需避免端口冲突）。
  • 示例：监控组件（如 Prometheus）使用 HostNetwork 便于采集节点指标。

k8s通过Label控制pod的位置

在 Kubernetes 中，通过 Label（标签） 配合 NodeSelector、NodeAffinity（节点亲和性）、PodAffinity/PodAntiAffinity（Pod 亲和性 / 反亲和性） 等机制，可以精确控制 Pod 在集群中的调度位置（即被分配到哪个节点上运行）。这种调度控制能力是 Kubernetes 编排能力的核心特性之一，可满足业务对节点资源、拓扑分布、安全隔离等需求。

核心原理

1. Label 是调度的 “桥梁”

• • 节点 Label：管理员可给节点打标签（如 disk=ssd、env=production、zone=cn-beijing），标识节点的属性（硬件、环境、区域等）。
  • Pod 调度规则：在 Pod 配置中定义 “需要匹配哪些节点 Label”，Kubernetes 的调度器（kube-scheduler）会根据规则筛选出符合条件的节点，并将 Pod 调度到其中一个节点上。

具体实现方式

1. NodeSelector（基础级控制）最简单的节点选择机制，通过 Pod 配置中的 

nodeSelector 字段，指定 Pod 只能调度到 “拥有特定 Label 的节点” 上。

操作步骤：

• 步骤 1：给节点打 Label
• bash

# 给节点 node-1 打上 "disk=ssd" 标签 kubectl label nodes node-1 disk=ssd

• 步骤 2：在 Pod 中定义 nodeSelector

yaml

apiVersion: v1 kind: Pod metadata: name: ssd-pod spec: containers: - name: app image: nginx nodeSelector: # 只调度到有 "disk=ssd" 标签的节点 disk: ssd

特点：

• 仅支持 “精确匹配”（等于关系），不支持复杂逻辑（如 in、not in、exists 等）。
• 若没有符合条件的节点，Pod 会一直处于 Pending 状态。

Health Check（健康检查）

 是保障保障容器化应用可用性的关键机制。它通过定期检测容器内应用的状态，自动识别并处理异常情况（如重启故障容器），确保应用始终处于可用状态。

三种核心的健康检查方式

一、livenessProbe（存活探针）

作用判断容器是否 “存活”（运行正常）。如果探测失败，kubelet 会杀死容器并根据 

restartPolicy（重启策略）重启容器。

适用场景

• 检测应用是否陷入死锁、无限循环等 “存活但不可用” 的状态。
• 确保故障应用能自动恢复（如 Java 应用 OOM 后重启）。

支持的探测方式

1. HTTP GET 探测：向容器内的指定 URL 发送 HTTP 请求，返回状态码 

200-399 视为成功。

yaml

livenessProbe: httpGet: path: /health # 应用暴露的健康检查接口 port: 8080 # 容器端口 initialDelaySeconds: 30 # 容器启动后延迟30秒开始探测 periodSeconds: 10 # 每10秒探测一次 timeoutSeconds: 5 # 探测超时时间（默认1秒） failureThreshold: 3 # 连续3次失败视为容器死亡

1. TCP 探测

：尝试与容器的指定端口建立 TCP 连接，连接成功视为存活。

yaml

livenessProbe: tcpSocket: port: 22 # 检测SSH端口是否可连接 periodSeconds: 10

1. Exec 探测：在容器内执行指定命令，命令退出码为 

0 视为成功。

yaml

livenessProbe: exec: command: ["cat", "/tmp/healthy"] # 检查文件是否存在 periodSeconds: 5

二、readinessProbe（就绪探针）

作用

判断容器是否 “就绪”（可以接收请求）。如果探测失败，Pod 会从 Service 的端点列表中移除，不再接收流量。

适用场景

• 应用启动过程中（如加载配置、初始化数据），虽存活但暂时无法提供服务。
• 应用运行中临时不可用（如数据库连接断开），需暂时隔离流量。

探测方式与 

livenessProbe 相同（HTTP、TCP、Exec），但逻辑不同：

yaml

readinessProbe: httpGet: path: /ready # 应用暴露的就绪检查接口 port: 8080 initialDelaySeconds: 5 # 启动后5秒开始探测 periodSeconds: 5 # 每5秒探测一次

与 livenessProbe 的区别

• livenessProbe 关注 “容器是否需要重启”，readinessProbe 关注 “容器是否可接收请求”。
• 就绪探测失败不会杀死容器，只会将其从服务负载均衡中移除。

三、startupProbe（启动探针）

作用

判断容器内的应用是否 “启动完成”。仅在应用启动阶段生效，启动成功后便不再执行，转而由存活 / 就绪探针接管。

适用场景

• 启动缓慢的应用（如大型 Java 服务、数据初始化耗时较长的应用），避免存活探针在启动阶段误判为故障。

探测方式

yaml

startupProbe: httpGet: path: /startup # 应用启动完成的标识接口 port: 8080 failureThreshold: 30 # 最多探测30次 periodSeconds: 10 # 每10秒探测一次（总容忍300秒启动时间）

逻辑

• 如果启动探针成功，livenessProbe 和 readinessProbe 开始工作。
• 如果启动探针失败（超过 failureThreshold），kubelet 会杀死容器并重启。

四、核心参数说明

所有探针共有的关键参数：

• initialDelaySeconds：容器启动后延迟多久开始第一次探测（默认 0 秒）。
• periodSeconds：探测间隔时间（默认 10 秒）。
• timeoutSeconds：单次探测超时时间（默认 1 秒，超时视为失败）。
• successThreshold：连续多少次成功视为 “健康”（默认 1 次）。
• failureThreshold：连续多少次失败视为 “不健康”（默认 3 次）。

五、实际应用示例

一个同时配置三种探针的 Pod 定义：

yaml

apiVersion: v1 kind: Pod metadata: name: app-with-probes spec: containers: - name: app image: my-app:v1 ports: - containerPort: 8080 # 启动探针：容忍最长300秒启动时间 startupProbe: httpGet: path: /startup port: 8080 failureThreshold: 30 periodSeconds: 10 # 存活探针：检测应用是否存活，失败则重启 livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 periodSeconds: 10 # 就绪探针：检测应用是否可接收请求，失败则移除流量 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5

总结

Kubernetes 的健康检查机制通过三种探针实现分层保障：

• startupProbe：确保慢启动应用不被误杀。
• livenessProbe：自动恢复故障容器，维持应用存活。
• readinessProbe：确保流量只转发到可用的容器，提升服务稳定性。

合理配置健康检查是生产环境中保障应用高可用的核心实践，需根据应用特性（启动时间、健康状态指标）调整参数，避免误判或漏判。