K8s学习

一、K8s的架构层面

Kubernetes（简称 K8s）是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用程序。

（一）Kubernetes 的底层逻辑

1、资源抽象与统一接口

将底层硬件（CPU、内存、存储、网络）抽象为 Pod、Service、ConfigMap 等资源对象，这一点很重要，实际上是将这些硬件的作用体现出来，具体抽象的资源对象具体会在第二部分讲解。
提供统一的 API 接口（如 RESTful API），屏蔽底层差异，用户只需关注业务需求。

2、 声明式配置（Declarative Model）

用户通过 YAML/JSON 文件定义 期望状态（如部署 3 个副本、每个副本需 2GB 内存）。
Kubernetes 持续对比 实际状态 与期望状态，自动调整资源（如重启异常 Pod、扩展副本数），k8s 的核心设计是 “期望状态 vs 实际状态” 的控制循环，API Server 是这个循环的 “桥梁”，这个后面会讲。

3、自动化管理闭环

检测 → 调整 → 验证 的闭环流程：

• 检测：通过监控组件（如 kubelet、控制器）感知集群状态变化。
• 调整：自动触发调度、扩容、故障恢复等操作。
• 验证：确保最终状态符合用户定义。

（二）Kubernetes 的运作步骤

步骤	组件/角色	功能描述
1. 用户操作	kubectl 或 API 客户端	用户通过命令行或 API 提交操作请求（如创建 Deployment）。
2. API 服务器处理	API Server	接收请求并验证权限，将数据写入 ETCD 数据库。
3. 控制器管理	Controller Manager	- 副本控制器：确保 Pod 数量符合预期。 - 服务控制器：维护 Service 与 Endpoints 的映射。
4. 调度器调度	Scheduler	根据资源需求（CPU/内存）和节点标签，将 Pod 分配到合适的 Node。
5. 节点执行	kubelet	- 拉取容器镜像。 - 创建并启动容器。 - 监控容器状态并上报。
6. 网络配置	kube-proxy	通过 IPVS/IPTables 规则实现服务的负载均衡和网络策略。
7. 应用运行	Pod & 容器	容器在 Node 上运行，共享网络命名空间和存储卷。

（三）架构图中各部分详解

1、API Server：集群的 “神经中枢”

k8s 的核心设计是 “期望状态 vs 实际状态” 的控制循环，API Server 是这个循环的 “桥梁”：
控制器的逻辑：

（1）API Server 是 k8s 最核心的组件，所有交互必须经过它，其运作逻辑可拆解为：

• 功能定位

暴露 RESTful API：支持 CRUD（创建、读取、更新、删除）操作，涵盖 Pod、Service、Deployment 等所有资源。
实现 统一准入控制：请求先过认证、鉴权，再执行逻辑（避免非法操作）。
维护 集群状态单一入口：所有组件（调度器、控制器、kubelet）通过 API Server 读写集群状态，而非直接操作 etcd。

• 与 etcd（etcd 是一个开源的、分布式的键值存储系统，基于 Raft 共识算法来保证数据的强一致性、高可用性，最初由 CoreOS
  开发，现在是 CNCF（云原生计算基金会）孵化的项目。在 Kubernetes
  集群里，它主要用于持久化存储所有集群相关的配置信息和运行状态数据。） 的关系
  写流程：用户创建 Pod → API Server 接收请求 → 写入 etcd（持久化）。
  读流程：控制器监听 Pod 变化 → API Server 从 etcd 拉取最新状态 → 返回给控制器。
  为什么不直接连 etcd？
  解耦组件依赖，API Server 可做请求校验、流量控制、审计，让 etcd 专注存储。
• 核心 API 分组
  资源类 API：/api/v1/pods（操作 Pod）、/apis/apps/v1/deployments（操作 Deployment）。
  事件与状态 API：/api/v1/events（集群事件）、/metrics（监控指标）。
  认证鉴权 API：/apis/authentication.k8s.io（认证）、/apis/authorization.k8s.io（鉴权）。

（2）完整运作流程：从 “kubectl 创建 Pod” 看 API 串联逻辑

以 “用户用 kubectl 创建一个 Nginx Pod” 为例，拆解从请求发起到 Pod 运行的全流程，看 API Server 如何驱动集群：
步骤 1：用户发起请求
kubectl run nginx-pod --image=nginx # 创建 Pod
kubectl 会将命令转换为 REST 请求（如 POST /api/v1/namespaces/default/pods），携带 Pod 配置（镜像、资源限制等）。
步骤 2：API Server 准入校验
请求到达 API Server 后，先经过 3 层校验：

• 认证（Authentication）：

验证用户身份（如 TLS 证书、Token、用户名 + 密码），确认 “你是谁”。
例：如果用 kubeconfig，kubectl 会自动附加证书，API Server 校验证书合法性。

• 鉴权（Authorization）：

判断用户是否有权限操作 Pod（如 RBAC 规则：是否允许 create pods 在 default 命名空间）。
例：普通用户可能被限制只能操作自己命名空间的资源。

• 准入控制（Admission Control）：

校验 Pod 配置是否合法（如是否设置资源限额、镜像是否合规），可自定义插件（如限制镜像仓库）。
例：如果集群要求所有 Pod 必须设置 resources.limits，准入控制会拒绝不满足的请求。
步骤 3：写入 etcd 持久化
校验通过后，API Server 会将 Pod 的 “期望状态” 写入 etcd（如 {“kind”:“Pod”, “spec”:{“image”:“nginx”}…}）。
此时，etcd 中新增一条 Pod 记录，但 Pod 尚未真正运行。
步骤 4：调度器监听并调度
调度器 持续 监听 API Server 的 Pod 事件（通过 watch 机制），发现有 “未调度的 Pod” 后：
筛选符合条件的 Node（如资源充足、标签匹配）。
更新 Pod 的 spec.nodeName（绑定到某 Node），并通过 API Server 写入 etcd。
步骤 5：kubelet 执行 Pod 启动
Node 上的 kubelet 也在 监听 API Server，发现 “绑定到本机的 Pod” 后：

• 通过 CRI（容器运行时接口） 调用 Docker（或 containerd）创建容器。
• 通过 CNI（容器网络接口） 配置 Pod 网络（分配 IP、设置路由）。
• 通过 CSI（容器存储接口） 挂载存储卷（如有）。

启动后，kubelet 定期向 API Server 上报 Pod 状态（如 Running、健康检查结果）。
步骤 6：Service 与网络打通（可选）
如果创建了 Service 关联该 Pod：
kube-proxy 监听 API Server 的 Service/Endpoint 变化，配置 IPVS/iptables 规则（将 Service IP 流量转发到 Pod IP）。
外部流量可通过 Ingress 或 LoadBalancer 经 kube-proxy 转发到 Pod。
步骤 7：控制器维持期望状态
如果 Pod 属于 Deployment（或其他控制器）：
Deployment 控制器 监听 API Server，确保 Pod 副本数符合 spec.replicas（如 Pod 异常退出，会自动重建）。

（3）API Server 的 “Watch 机制”：实时感知集群变化

k8s 组件间能实时协同，核心依赖 API Server 的 Watch 机制（类似 “订阅 - 发布”）：
组件如何监听？
调度器、kubelet、控制器等会向 API Server 发起 GET /…?watch=true 请求，建立长连接。
事件如何触发？
当 etcd 中资源状态变化（如创建 Pod、删除 Node），API Server 会主动推送事件给所有监听者。
为什么需要 Watch？
替代 “轮询”，减少无效请求，保证组件实时响应（如 Pod 刚绑定 Node，kubelet 立即启动）。

（4）API Server 的扩展性

k8s 允许通过 CustomResourceDefinition（CRD） 和 Operator 扩展 API：
CRD：自定义资源（如 MyApp），让 API Server 支持新的 REST 端点（/apis/mycompany.com/v1/myapps）。
Operator：自定义控制器，通过 API Server 监听 CRD 变化，实现复杂逻辑（如数据库自动备份）。
例：开发一个 RedisCluster CRD，Operator 监听其变化，自动创建 Pod、配置主从、初始化数据。

（5）总结：API 是集群的 “神经网络”

所有交互必经 API Server：用户、组件、第三方工具都通过 API 读写集群状态。
控制循环的核心枢纽：控制器通过 API 感知 “期望状态”，调谐 “实际状态”。
扩展性的基础：CRD 和 Operator 基于 API 扩展，让 k8s 适配复杂场景。

理解 API Server 的角色后，再看 k8s 架构就清晰了：所有组件围绕 API 协同，etcd 持久化状态，控制器维持秩序，kubelet 执行落地。

2、Pod

（1）Pod 基本概念

Pod 是 Kubernetes 中最小的可部署计算单元，它代表集群中运行的一个或多个容器的组。Pod 内的容器共享网络命名空间、存储卷，并且始终运行在同一个工作节点上。

（2）原子调度单位：Kubernetes 不会单独调度容器，而是将 Pod 作为整体调度到节点上。

共享上下文：

• 共享网络（相同 IP 和端口空间）
• 共享存储卷（可挂载相同数据）
• 共享生命周期（同时创建、终止）

紧密耦合应用：通常用于需要直接通信的组件（如主应用与辅助工具）

3、kube-proxy

（1） 角色定位

• 位置：位于 Kubernetes 的 Worker 节点（Node）中，是每个节点上的核心网络组件。
• 职责：实现 Service 的负载均衡与网络策略管理，是 Kubernetes 服务暴露和流量转发的核心组件。

---

（2）核心功能

功能	描述
服务负载均衡	根据 Service 定义的规则（如 ClusterIP、NodePort、LoadBalancer），将外部或集群内部流量转发到对应的 Pod。
网络规则管理	通过 IPVS 或 IPTables 技术动态维护 Linux 内核的网络规则，实现流量分发。
服务发现与更新	监听 API Server 的 Endpoints 变化，自动更新节点上的网络规则，确保服务地址与 Pod 实际 IP 同步。

---

（3） 工作原理

• *监听 API Server

• kube-proxy 通过与 API Server 通信，获取所有 Service 和 Endpoints 的定义（如 ClusterIP、Port、Pod IP 列表）。

• 生成网络规则

• 根据 Service 类型（ClusterIP、NodePort 等），使用 IPVS 或 IPTables 创建规则：

  • ClusterIP：为服务分配一个虚拟 IP，将流量转发到后端 Pod。
  • NodePort：在所有节点的指定端口监听流量，并转发到后端 Pod。
  • LoadBalancer：配合云服务商的 LB 实现外部流量接入。

• 动态更新

• 当 Pod 的状态变化（如新增/删除/故障）时，kube-proxy 会更新对应的网络规则，确保流量始终指向健康的 Pod。

---

（4）与关键组件的交互

组件	交互方式	作用
API Server	拉取 Service 和 Endpoints 数据	获取服务定义和后端 Pod 列表
kubelet	无直接交互	依赖 kubelet 管理 Pod 生命周期
IPVS/IPTables	调用 Linux 内核模块	实现流量转发和负载均衡
Docker	无直接交互	容器运行时，提供 Pod IP

---

（5）在网络架构中的位置

• 入口流量路径：
  Internet → LB（负载均衡器） → NodePort/ClusterIP → kube-proxy → Pod
• 内部流量路径：
  Pod A → kube-proxy（本节点） → Service → kube-proxy（目标节点） → Pod B

---

（6）常见模式对比

模式	技术	特点	适用场景
IPTables	Linux 内核的 iptables 模块	稳定成熟，但性能较低	小规模集群或旧版本 K8s
IPVS	Linux 的 IP Virtual Server 模块	高性能，支持大规模负载均衡	大规模生产环境推荐

---

总结
kube-proxy 是 Kubernetes 服务网络的核心组件，通过动态维护网络规则，实现了服务的负载均衡、流量转发和高可用性。其工作依赖于 API Server 的数据同步以及 Linux 内核的网络能力（IPVS/IPTables），是连接集群内外流量的关键桥梁。

4、kubelet

二、K8s抽象的资源层面

根据上面第一部分的内容，K8s将底层硬件（CPU、内存、存储、网络）抽象为 Pod、Service、ConfigMap 等资源对象。

（一）资源控制器

1、Deployment 控制器

想象一下你正在经营一家连锁咖啡店，为了应对顾客的需求变化，你需要灵活调整前台接待员（Pod）的数量。Deployment 控制器就像一个智能的排班经理，它能够自动管理前台接待员的数量。例如，如果设定需要5名接待员，当有人请假时，Deployment 会自动补充一名新员工以维持这个数量不变。同时，当你想要引入新的点餐系统时，Deployment 可以帮助你逐步替换旧系统，而不会影响到正常的服务。

2、CronJob 控制器

假设你的咖啡店每天凌晨都需要清洁厨房和整理库存，CronJob 控制器就如同一位安排夜间工作的主管，根据预定的时间表自动启动相应的任务。比如设置为每天凌晨2点开始清洁工作，或者每周一早上检查设备状态。这确保了所有必要的维护工作都能按时完成，而无需人工干预。

3、DaemonSet 控制器

DaemonSet 控制器保证每家新开的咖啡店都有至少一名收银员。无论何时开设新店，DaemonSet 都会在该店部署一名收银员，确保每家店都能顺利进行交易。这种机制非常适合那些需要在每个节点上都运行的服务，如日志收集或监控服务。

4、StatefulSet 控制器

对于一些需要特殊处理的任务，比如后厨的厨师长（主厨），StatefulSet 控制器就显得尤为重要。它确保每位厨师都有自己固定的编号和专属的工作空间（数据卷），即使发生人员变动，也能保持工作的连续性和一致性。这对于数据库等有状态的应用来说至关重要。

5、Job 控制器

有时候，你可能需要临时增加人手来完成特定的任务，比如举办新品试吃活动。Job 控制器就像是一个临时项目组的组长，它负责雇佣所需人数的临时工（Pod），直到任务完成为止。一旦任务结束，这些临时工就会被解散。

6、ReplicaSet 控制器

ReplicaSet 是新⼀代 ReplicationController，除⽀持等值标签选择器外，还⽀持基于集合的选择器，功能更强⼤
ReplicationController：⽀持等值标签选择器
VS controller manager 中的 Replication controller(副本控制器)
两者不同：前者中的POD产⽣后，与它本身没有联系，产⽣的POD由管理；后者需要保障集群中
某个与前者关联的pod副本数与预设值⼀致
ReplicaSet 控制器专注于维持一组Pod的副本数量，确保指定数量的实例始终处于运行状态。在咖啡店的情景中，它可以看作是一个服务员人数统计员，确保任何时候都有足够的服务员（Pod）在岗。如果某个服务员暂时离开，ReplicaSet 会立即补充一个新的服务员以填补空缺。

（二）网络与服务

网络与服务组件在Kubernetes集群中起着至关重要的作用，它们确保了集群内部以及外部与集群之间的高效、可靠的通信。以下是这些组件的具体作用及形象生动的例子说明：

1、Ingress

作用: Ingress作为外部访问集群内服务的入口点，通过配置路由规则将请求转发到不同的Service。它允许你基于URL路径或域名来决定如何路由流量，支持HTTP/HTTPS协议。
例子: 想象一下，你在经营一家咖啡馆（代表你的Kubernetes集群），而这家咖啡馆提供多种饮品（代表不同的服务）。顾客（代表外部请求）来到咖啡馆时，他们只需告诉服务员（Ingress控制器）他们想要什么饮品，服务员根据顾客的需求指引他们去正确的柜台（不同的Service）。例如，如果顾客说“我要一杯拿铁”，服务员会直接引导他们到拿铁制作区，而不是让他们自己去找。

2、Service

作用: Service定义了一组逻辑上的Pod和策略规则，实现服务发现和负载均衡功能，使得客户端能够通过稳定的IP地址和端口访问后端Pod。无论后端Pod的数量如何变化，客户端始终可以通过同一个Service进行访问。
例子: 继续以咖啡馆为例，假设你有多个员工（Pod）负责制作同一种饮品（比如拿铁）。即使某个员工暂时离开或者新增加了一个员工，顾客（客户端）仍然可以无差别地向任何一位员工下单，并得到相同质量的拿铁。这是因为有一个智能系统（Service）在背后动态地分配订单给当前可用的员工，确保服务的一致性和稳定性。

3、Endpoint

作用: Endpoint表示实际提供服务的Pod列表，是Service和Pod之间的映射关系，由Kubernetes自动维护。每当一个新的Pod被创建或者旧的Pod被删除时，Endpoints对象都会相应更新，保证Service总是指向最新的活跃Pod集合。
例子: 回到咖啡馆的情境，当新员工加入团队（新的Pod上线）或某位员工下班（旧的Pod下线），管理系统的名单（Endpoint）会实时更新，确保所有订单都能准确分配给当前正在工作的员工。这意味着，不论团队成员如何变动，顾客总能获得所需的服务，因为管理系统保持了最新最准确的信息。
通过这些比喻，我们可以更直观地理解Kubernetes中网络与服务组件的作用及其重要性。这些机制共同工作，确保了应用的高可用性、可扩展性和灵活性。

（三）存储与配置

☕ 延续咖啡店的例子：Kubernetes 存储与配置组件比喻
场景设定：
你经营一家连锁咖啡店（代表一个 Kubernetes 集群），每个门店（Node）都有自己的员工（Pod），他们共同完成顾客的订单任务。

1、存储卷（Volume）

作用：让多个员工在制作饮品时能访问相同的数据。
例子：
在某家门店里，有几位员工同时负责制作拿铁。他们需要查看同一份配方表（比如牛奶量、咖啡粉比例）。这份配方表就放在一个共享的“工作台”上（相当于 Volume），每位员工都可以读取它。

2、本地存储卷（EmptyDir / HostPath）

emptyDir：⽣命周期与pod相同——pod删除或者重启时数据会清空
hostPath：允许容器直接对主机节点的⽂件系统的访问，有依赖性和⻛险且 Pod 重新调度后
⽆法访问原数据
作用：提供临时存储，Pod 删除后数据也会消失。
例子：
每个员工有一个小记事本（EmptyDir），用来记录当天临时的客户备注，比如“少糖”、“加奶泡”。一旦员工下班（Pod 被删除），记事本的内容也就被丢弃了。

3、网络存储卷（NFS / iSCSI）

作用：跨节点共享数据。
例子：
所有门店之间共享一份“每日销售报表”，总部通过一个中央服务器（NFS）统一管理。每家门店都能访问并更新这份报表，确保数据一致性。

4、持久存储卷（PersistentVolume + PVC）

ersistentVolume（PV）是集群中的存储资源，由管理员配置，独⽴于 Pod 存在，具有持久
性。PVC是pod对PV的申请，申请使⽤资源。
作用：为需要长期保存的数据提供可动态申请的存储资源。
例子：
某家门店使用了一个“顾客会员系统”，里面保存了所有会员的消费记录。这些数据非常重要，不能随着员工换班而丢失。于是，门店向总部申请了一块专属的“云硬盘”（PV），并通过工单（PVC）绑定使用，即使员工更换，数据仍然保留在那里。

5、配置存储卷（ConfigMap / Secret）

Secret ⽤于向 Pod 传递敏感信息，如密码、私钥、证书⽂件等，将敏感数据存储于集群中，
由 Pod 挂载，实现敏感数据与系统解耦 。
ConfigMap ⽤于向 Pod 注⼊⾮敏感数据，⽤户将数据存储于 ConfigMap 对象中，Pod 通过
ConfigMap 卷引⽤，实现容器配置⽂件的集中化定义和管理。
作用：将配置信息集中管理，避免硬编码在程序中。
例子：
每家门店都需要知道总部的联系方式、API 密钥、咖啡机参数等配置信息。总部把这些信息写成“操作手册”（ConfigMap）和“安全密钥卡”（Secret），发放给各门店员工使用。员工在上岗前只需领取这些资料即可开始工作，无需自己记住。
✅ 总结一句话：
如果说 Pod 是咖啡店里的员工，那么 存储与配置组件 就是他们的 工具箱、笔记本、会员数据库、总部手册和密钥卡，帮助他们在工作中高效协作、稳定运行、安全执行任务。

（四）资源划分与管理

☕ 延续咖啡馆的例子：资源划分与管理组件类比
你经营的是一个大型连锁咖啡集团，旗下有多个门店，每个门店有不同的部门（前厅、后厨、IT系统），还有不同的品牌线（比如“冰滴吧”、“拿铁工坊”）。为了高效管理这些资源，你需要一套清晰的组织结构和标识系统。

1、命名空间（Namespace）

作用：将资源按团队、项目或环境进行逻辑隔离。
例子：
你的咖啡集团下有三个“分部”：
dev 分部负责新饮品的研发；
test 分部用于试营业；
production 是正式运营的门店。
每个分部都有自己的员工（Pod）、设备（Service）、配方（ConfigMap）等资源，互不干扰。
即使两个分部中都存在一个叫“拿铁机”的服务，也不会发生冲突，因为它们在不同的“命名空间”里。
类比一句话：就像把咖啡店的不同部门放在不同的楼层里办公，虽然都在一栋楼里，但彼此独立运作

2、标签（Label）

作用：给资源打上“标签”，方便查找、分组、调度和操作。
例子：
在“生产门店”这个命名空间中，你给员工贴上标签：
role=barista（咖啡师）
shift=morning（早班）
lcation=shanghai（上海店）
当需要查看所有“上海店的早班咖啡师”，只需筛选带有这些标签的员工即可。
同样，你可以通过标签来指定哪些 Pod 需要部署到特定节点上，或者触发自动扩缩容。
📌 类比一句话：就像给员工佩戴工作牌，上面写着他们的岗位、班次和所属门店，便于快速识别和调配。

3、注解（Annotation）

作用：为资源附加额外信息，通常是给人或其他工具看的，不用于选择或筛选。
例子：
某台咖啡机（Pod）上有一个小标签贴纸（Annotation）写着：
maintained-by: 李师傅
last-updated: 2025-07-08
version: CoffeeMachine v2.3
这些信息不会影响咖啡机的工作方式，但在维护时非常有用，帮助技术人员快速了解设备状态。
📌 类比一句话：就像在设备背面贴一张小纸条，写明是谁安装的、什么时候更新过、使用的是哪个版本，方便后期维护
✅ 总结一句话：
如果说 Kubernetes 是一家大型连锁咖啡集团，那么 命名空间 就是它的各个分公司或部门，标签 是员工的工作牌，而 注解 则是设备上的维修记录贴纸 —— 它们共同构成了一个清晰、有序、易于管理的资源体系。

（五）认证与授权

☕ 延续咖啡馆的例子：认证与授权类比
你经营着一家大型连锁咖啡集团，现在需要管理门店员工对不同系统的访问权限，比如：
查看销售报表
添加新员工
修改菜单价格
关闭门店系统
为了安全起见，不能让所有员工都拥有全部权限。于是你引入了一套“身份+权限”管理体系。

1、ServiceAccount（服务账户）

作用：为 Pod（即员工）提供身份凭证，使其能合法访问系统。
例子：
每个新入职的员工（Pod）都会自动获得一张“员工卡”（ServiceAccount），上面有基础的身份信息。
这张卡允许员工登录到店内系统（Kubernetes API），进行默认操作，比如查看菜单、打印订单等。
如果没有这张卡，员工就无法进入系统，就像没工牌进不了门一样。
📌 类比一句话：ServiceAccount 就是员工的“工作身份证”，用来证明你是谁。

2、Role（角色）

作用：定义一组操作权限，决定谁能做什么事。
例子：
你定义了几个角色：
barista-role：只能查看菜单和订单；
manager-role：可以修改菜单、调整价格；
admin-role：可以添加/删除员工、关闭门店系统。
每个角色都有对应的权限清单，比如：
📌 类比一句话：Role 就是“岗位说明书”，写明这个职位能操作哪些系统功能.

3、RoleBinding（角色绑定）

作用：把某个 Role 授予具体的用户、组或 ServiceAccount，实现权限分配。
例子：
你把 manager-role 绑定给了店长小王（User）和店员小李的 ServiceAccount。
这样他们就可以使用自己的身份去操作被允许的功能。
如果你想收回权限，只需修改 RoleBinding 即可，不需要改代码或重启系统。
📌 类比一句话：RoleBinding 就像“岗位任命书”，告诉系统：“这个人/这个员工卡”有这个权限。
✅ 总结一句话：
在你的咖啡店里，ServiceAccount 是员工的身份卡，Role 是岗位职责说明书，而 RoleBinding 则是岗位任命书 —— 它们三者配合，确保每个员工只能做自己该做的事，既高效又安全。

三、K8s层面的运维

（一）集群工作节点健康检查

1、查看集群的工作节点状态是否Ready

kubectl get node

2、查看集群的工作节点详细信息

kubectl get node -o wide

3、查看集群工作节点标签

kubectl get node --show-labels

4、添加集群工作节点标签

kubectl label node [node 名称] qfusion/need-oracle=true

5、清除集群工作节点标签

kubectl label node [node 名称] qfusion/need-oracle=true

6、查看工作节点的描述信息

Kubectl describe node [node 名称]

（二）K8s 系统组件检查

1、检查k8s系统组件是否正常,status 为Running 表示正常

kubectl get pod -n kube-system

2、查看cilium网络流量运行的IP地址

cilium status --verbose

3、系统组件异常日志查看

当系统组件的ready 非1/1 时，可以使用kubectl describe pod [pod名称] -nkube-system 查看具体报错信息

kubectl describe pod [pod名称] -n kube-system/ks describe pod [pod名称]

（三）K8s文件导入导出

1、K8s文件导入pod和导出pod

用这里的

cilium-kz9ws

kubectl cp 1.sql [pod名称]:/var/lib/mysql/ -n qfusion-admin -c mysql 文件导入pod
kubectl cp [pod名称]:/var/lib/mysql/1.sql ./1.sql -n qfusion-admin -c mysql 文件导出pod
-c是指定容器名称