SRE文档

深浅模式

1. 谈谈你对k8s的理解☆ ​

Kubernetes (K8s) 是一个开源的容器编排平台，用于自动化容器化应用程序的部署、扩展和管理。我的理解是，Kubernetes 是现代云原生架构的核心组件，广泛用于管理微服务和分布式系统。以下是我对 Kubernetes 的主要理解：

1. 容器编排的核心 ​

  • 容器管理：Kubernetes 是用于管理容器化应用的工具。容器技术，如 Docker，将应用和其依赖打包在一个可移植的镜像中。Kubernetes 通过调度和管理这些容器来确保应用的高可用性、扩展性和一致性。
  • 集群模式：Kubernetes 运行在集群环境中，集群由多个节点组成。每个节点可以运行一个或多个容器。Kubernetes 负责在集群中自动调度和分配资源，从而高效地运行和管理容器。

2. 自动化和自我修复 ​

  • 自动化部署：Kubernetes 允许用户定义应用的所需状态（例如，部署的容器数量、服务的健康状态等），并自动执行操作以保持应用在定义的状态。这大大降低了运维人员的手动干预。
  • 自我修复：Kubernetes 具有自我修复的能力，例如如果某个容器崩溃，Kubernetes 会自动重启该容器；如果某个节点出现问题，Kubernetes 会将容器迁移到其他健康的节点上。

3. 可扩展性和负载均衡 ​

  • 水平扩展：Kubernetes 通过水平扩展机制（例如通过增加或减少 Pod 数量）来响应应用负载的变化。它可以通过 Horizontal Pod Autoscaler (HPA) 来动态调整容器副本数量。
  • 服务发现和负载均衡：Kubernetes 内置了服务发现和负载均衡机制。通过 Kubernetes 的 Service 资源，应用的不同组件可以相互发现并通过 ClusterIP 进行通信。Kubernetes 还可以对外部流量进行负载均衡。

4. 声明式管理 ​

  • Kubernetes 使用声明式配置文件（如 YAML 或 JSON）来描述集群中资源的期望状态。运维人员或开发者通过这些文件定义应用应该如何部署、如何扩展、以及如何恢复故障。Kubernetes 控制器会自动调整资源，使实际状态与声明状态保持一致。

5. 扩展性和插件化 ​

  • 扩展能力：Kubernetes 是高度可扩展的，允许用户编写自定义控制器和自定义资源定义（CRD）以满足特定的业务需求。许多第三方插件和工具，如 Prometheus、Istio、Helm 等，能够与 Kubernetes 集成，进一步扩展其功能。
  • 多种存储和网络支持：Kubernetes 支持多种存储（如 Ceph、NFS、云存储提供商的块存储）和网络方案，用户可以灵活选择存储和网络架构来满足应用需求。

6. 高可用性和持久性 ​

  • 高可用性：通过复制控制、健康检查、负载均衡和自动扩展等机制，Kubernetes 保证了应用程序的高可用性。它可以自动将流量路由到健康的 Pod，确保即使在故障发生时，应用仍能提供服务。
  • 持久存储：Kubernetes 允许将数据持久化，通过 Persistent Volume (PV) 和 Persistent Volume Claim (PVC) 的方式，将存储卷与 Pod 解耦，实现应用状态的持久化。

7. 混合云和跨云能力 ​

  • Kubernetes 是云原生的，支持多种云平台（如 AWS、GCP、Azure）和私有云环境。通过 Kubernetes，用户可以轻松地在不同云平台之间迁移应用，并实现多云或混合云的架构。

8. 应用场景 ​

  • 微服务架构：Kubernetes 是管理和部署微服务应用的理想平台。它能够将不同的微服务组件封装在独立的容器中，并通过 Kubernetes 提供的调度和网络功能进行管理和通信。
  • CI/CD（持续集成与持续交付）：Kubernetes 在 DevOps 工具链中扮演了重要角色。通过结合 Jenkins、GitLab 等工具，Kubernetes 可以实现自动化的构建、测试和部署流程。
  • 大数据处理：Kubernetes 也被用于大数据处理和机器学习任务。许多数据处理框架（如 Apache Spark、TensorFlow）都可以在 Kubernetes 上运行，从而实现分布式计算和模型训练。

总结 ​

Kubernetes 是一个强大、灵活的容器编排平台，提供了自动化、扩展性、自我修复等关键功能，适用于云原生架构下的应用管理。它不仅简化了应用部署的复杂性，还为现代应用程序提供了强大的运维和管理工具，支持大规模分布式系统的部署和管理。

2. k8s集群架构是什么☆ ​

Kubernetes 集群架构是一个分布式系统架构，旨在管理容器化应用的自动化部署、扩展和操作。Kubernetes 集群由多个组件组成，每个组件在集群中执行特定的职责，以确保整个系统的高效运行和管理。下面是 Kubernetes 集群的核心架构及其主要组件：

1. 集群架构概述 ​

Kubernetes 集群由以下核心部分组成：

  • Master 节点（控制平面）：负责管理集群的全局状态、调度和控制。控制平面包含多个组件，负责管理集群中的所有节点和工作负载。
  • Worker 节点（工作节点）：每个节点运行容器化的应用程序。Worker 节点被 Master 节点管理，并实际执行容器工作负载。

2. Master 节点（控制平面） ​

Master 节点是 Kubernetes 集群的控制中心，负责管理整个集群的状态和操作。以下是 Master 节点的核心组件：

  • API Server：
    • 负责处理外部和内部的 REST API 请求，是集群的入口点。
    • 所有的操作（如创建、更新、删除资源）都必须通过 API Server，它确保集群的状态与期望一致。
  • Etcd：
    • 是一个分布式键值存储，用于存储整个集群的配置数据和状态信息。
    • 所有 Kubernetes 资源（如 Pod、Service、ConfigMap 等）都存储在 Etcd 中，它是集群的“数据库”。
  • Controller Manager：
    • 负责执行控制循环来确保集群达到所期望的状态。
    • 包括多种控制器（如节点控制器、Replication Controller、Endpoint Controller 等），这些控制器不断监控集群资源并根据需求做出调整。
  • Scheduler：
    • 负责为 Pod 分配合适的节点。
    • 根据资源需求、节点健康状态、调度策略等，将 Pod 调度到最合适的 Worker 节点上。
  • Cloud Controller Manager（可选）：
    • 与云服务提供商集成，管理与底层云平台相关的资源（如负载均衡器、存储卷等）。

3. Worker 节点（工作节点） ​

Worker 节点负责运行应用程序的实际容器。每个 Worker 节点包含以下关键组件：

  • Kubelet：
    • 是 Worker 节点上的代理，负责与控制平面（API Server）通信。
    • 接收并执行 Master 节点下发的指令（如启动容器、监控容器健康状况等）。
    • Kubelet 通过查询 API Server，确保节点上运行的容器与期望状态一致。
  • Kube-proxy：
    • 是 Kubernetes 的网络代理，负责处理服务间的网络通信。
    • Kube-proxy 实现了服务的负载均衡、IP 转发和路由功能，使得不同节点和 Pod 之间可以通过服务名称访问。
  • 容器运行时（CRI）：
    • 是实际运行容器的组件，常见的容器运行时有 Docker、containerd、CRI-O 等。
    • 容器运行时负责拉取容器镜像、启动容器并管理容器的生命周期。

4. 网络模型 ​

Kubernetes 提供了独特的网络模型，要求所有 Pod 在集群中都能直接通信，且每个 Pod 有一个唯一的 IP 地址。以下是网络层的关键组件：

  • CNI 插件（Container Network Interface）

    ：

    • 用于管理 Kubernetes 的 Pod 网络。
    • 常见的 CNI 插件有 Flannel、Calico、Weave 等，它们负责为每个 Pod 分配 IP 地址，提供网络隔离和流量控制。

5. 存储模型 ​

Kubernetes 支持多种类型的存储，包括本地存储、网络存储和云存储。以下是存储管理的关键组件：

  • Persistent Volumes (PV)

    和

    Persistent Volume Claims (PVC)

    ：

    • PV 是集群管理员提供的存储资源，而 PVC 是用户申请的存储资源。它们解耦了存储和 Pod，从而实现了数据的持久化。

6. 附加组件 ​

除了核心组件外，Kubernetes 还支持许多附加组件来增强集群的功能，例如：

  • DNS 服务：为 Pod 提供集群内部的 DNS 解析服务。
  • Dashboard：一个 Web 界面，允许用户查看和管理集群。
  • 监控与日志系统：如 Prometheus 和 Fluentd，提供监控、报警和日志收集功能。

7. 架构工作流程 ​

  • 当用户通过 kubectl 或者其他工具向 API Server 提交请求时，API Server 会将资源的期望状态保存到 Etcd 中。
  • Controller Manager 检查实际状态与期望状态的差异，并通过控制循环来调整实际状态（如创建或删除 Pod）。
  • Scheduler 为需要创建的 Pod 分配节点，确保它们被调度到合适的 Worker 节点上。
  • Kubelet 和容器运行时在 Worker 节点上运行这些容器，并监控它们的健康状况。

3. 简述Pod创建过程☆ ​

1. 用户提交请求 ​

用户通过 Kubernetes 的 CLI 工具（如 kubectl）或 API Server 提交一个 Pod 定义请求。Pod 的定义通常包含容器镜像、资源请求和限制、网络配置、存储需求等信息。用户可以直接提交 Pod，也可以通过 Deployment、StatefulSet 等高级控制器来间接创建 Pod。

  • 命令示例：

    bash
    kubectl apply -f pod-definition.yaml
    kubectl apply -f pod-definition.yaml

2. API Server 接收请求 ​

Kubernetes 的 API Server 是集群的入口，负责接收来自用户的 REST API 请求。API Server 解析 Pod 的定义，并将其转化为 Kubernetes 内部的对象形式。

  • API Server 会进行一些基本的验证，例如 YAML 格式是否正确、字段是否合法、资源是否超限等。

3. 将 Pod 信息存储到 Etcd ​

通过验证后，API Server 会将 Pod 对象的期望状态写入到集群的 Etcd 中。Etcd 是一个分布式键值存储，存储了整个集群的配置、状态和资源定义。

  • 此时，Pod 还没有被调度到任何节点上，只是被保存到 Etcd 中。

4. Scheduler 选择节点 ​

Kubernetes Scheduler 负责为 Pod 分配合适的节点。Scheduler 会从 Etcd 中读取新创建的 Pod 信息，并根据以下因素选择最合适的 Worker 节点：

  • 节点资源（CPU、内存等）的可用性
  • 节点的污点和容忍度
  • Pod 的亲和性/反亲和性规则
  • 节点的健康状态
  • 自定义调度策略

Scheduler 选定一个合适的节点后，会将调度决策更新到 Pod 对象中，将该 Pod 标记为要调度到某个具体的节点上。

5. Kubelet 创建 Pod ​

在调度成功后，目标节点上的 Kubelet 负责创建和管理 Pod。Kubelet 是每个节点上的代理，它会通过 API Server 监控节点上分配的 Pod。

  • Kubelet 接收到调度到该节点的 Pod 信息后，会根据 Pod 的定义，拉取指定的容器镜像。
  • 容器运行时（CRI）（如 Docker、containerd）被 Kubelet 调用来执行容器镜像的下载、解压和启动。Kubelet 还会处理网络设置、挂载卷等任务。

6. CNI 插件设置网络 ​

Kubelet 在启动容器时，会通过 CNI（Container Network Interface）插件 配置 Pod 的网络环境。CNI 插件负责为每个 Pod 分配 IP 地址，确保 Pod 可以与集群中的其他 Pod 进行通信。

  • 常用的 CNI 插件包括 Flannel、Calico、Weave 等。
  • CNI 插件会在节点的网络堆栈中设置必要的路由、IP 地址，并确保 Pod 与其他 Pod、服务和外部网络的连接。

7. 容器启动 ​

Kubelet 通过调用容器运行时启动容器。在此过程中，容器运行时会拉取镜像并根据 Pod 的定义启动容器。启动成功后，Pod 内的容器开始运行。

  • 如果 Pod 需要挂载存储卷，Kubelet 会在启动容器之前完成存储卷的挂载工作。
  • 如果 Pod 需要配置环境变量、秘密（Secrets）、配置映射（ConfigMaps）等，Kubelet 会在启动容器时注入这些配置。

8. 健康检查与监控 ​

Kubelet 启动容器后，会不断通过 Liveness Probe 和 Readiness Probe 来检查容器的健康状态和是否准备好处理流量。

  • Liveness Probe：用于判断容器是否处于健康状态，如果检查失败，Kubelet 会重新启动该容器。
  • Readiness Probe：用于判断容器是否已经准备好接收流量，如果检查失败，Pod 不会被加入到服务的负载均衡中。

9. Pod 完成创建 ​

当容器启动成功并通过了健康检查后，Pod 状态被标记为 Running，并开始对外提供服务。

10. 服务注册与暴露 ​

如果 Pod 通过了健康检查，且 Pod 依赖于 Service 来暴露它的服务，那么 kube-proxy 负责为该 Pod 设置负载均衡规则，使外部或其他 Pod 可以通过 Service 访问该 Pod。

总结 ​

Pod 的创建过程是 Kubernetes 各组件之间的协作，从用户提交请求开始，到 Pod 调度、容器启动，再到健康检查和服务暴露，整个流程自动化、分布式地完成。Kubernetes 通过这种流程，实现了对容器化应用的自动化部署和管理。

4. 简述删除一个Pod流程☆ ​

删除一个 Pod 的流程是 Kubernetes 集群内部多个组件的协作过程。以下是删除一个 Pod 的详细步骤：

1. 用户发起删除请求 ​

用户通过 kubectl 或者 API Server 发起删除 Pod 的请求。用户可以直接删除一个 Pod，或者通过删除其控制器（如 Deployment、ReplicaSet、StatefulSet）间接删除 Pod。

  • 命令示例：

    bash
    kubectl delete pod <pod-name>
    kubectl delete pod <pod-name>

2. API Server 接收删除请求 ​

Kubernetes 的 API Server 接收到用户的删除请求，进行验证和授权检查。如果删除操作合法，API Server 会更新 Etcd 中 Pod 对象的状态，将其标记为即将被删除（Terminating 状态）。

3. 发送 Termination 信号 ​

在 Pod 被标记为 Terminating 后，API Server 会向运行该 Pod 的节点上的 Kubelet 发送一个删除请求信号，通知 Kubelet 停止并清理该 Pod。

4. 触发 PreStop 钩子（如果定义了的话） ​

如果 Pod 的容器定义中配置了 PreStop Hook，Kubelet 会在停止容器之前执行这个钩子。PreStop Hook 通常用于在容器停止之前执行一些清理工作，如关闭网络连接或清理缓存。

  • PreStop Hook 是一个容器生命周期的回调函数，允许在 Pod 停止前执行一些自定义操作。

5. 发送 SIGTERM 信号给容器 ​

Kubelet 向 Pod 中的每个容器发送 SIGTERM 信号，以优雅地终止容器。这使得容器可以在规定的宽限期内完成当前的处理任务并进行清理工作。

  • 默认的宽限期是 30 秒，但可以通过 terminationGracePeriodSeconds 字段配置。如果容器在宽限期内没有退出，Kubelet 会强制终止容器。

6. 从 Service 解除注册 ​

Kubelet 同时会从与该 Pod 关联的 Service 负载均衡中移除该 Pod。这样，新的流量将不再被路由到该 Pod。

  • 如果 Pod 处于负载均衡中，kube-proxy 会更新 iptables 或 ipvs 规则，确保流量不再发送到该 Pod。

7. 等待容器优雅终止 ​

Kubelet 允许 Pod 内的容器在宽限期内完成正常的关闭操作。如果容器在规定的时间内成功退出，Kubelet 会继续删除 Pod。如果容器未能在宽限期内退出，Kubelet 将强制发送 SIGKILL 信号以终止容器。

8. 释放资源 ​

一旦容器停止运行，Kubelet 会释放与该 Pod 相关的所有资源，包括：

  • 解除与存储卷的绑定
  • 回收网络资源（如 IP 地址）
  • 清理挂载的卷
  • 解除与 CNI 网络插件的连接

9. 从 Etcd 中移除 Pod 对象 ​

当 Pod 完全停止并释放所有资源后，API Server 会将该 Pod 的定义从 Etcd 中删除，彻底清除该 Pod 的记录。

10. 删除完成 ​

Kubernetes 完成 Pod 删除的所有操作后，Pod 对象会从集群中彻底移除。

  • 对于控制器管理的 Pod（如 Deployment 管理的 Pod），一旦 Pod 被删除，控制器会根据其期望状态自动创建新的 Pod 来替代被删除的 Pod，确保集群中有足够数量的副本运行。

总结 ​

删除一个 Pod 的过程是从用户发起请求到 API Server 更新 Etcd 中的状态，然后通过 Kubelet 逐步优雅地终止 Pod 的容器，释放资源，最后彻底删除 Pod。整个过程确保了 Pod 的优雅终止和资源回收，同时保证集群的稳定性和服务的连续性。

5. 不同node上的Pod之间的通信过程☆ ​

在 Kubernetes 集群中，部署在不同节点上的 Pod 之间可以通过集群网络实现通信。为了使这种跨节点通信顺畅，Kubernetes 依赖底层网络插件（如 Flannel、Calico、Weave 等）来创建一个全局路由，使每个 Pod 都可以无缝地相互通信。以下是不同 Node 上的 Pod 之间通信的流程和机制。

Pod 通信的网络架构 ​

  1. Pod IP 和 CNI 插件
    • 每个 Pod 都会被分配一个独立的 IP 地址。Pod 内部的所有容器共享这个 IP。
    • Kubernetes 使用 CNI（Container Network Interface）插件来管理 Pod 网络。常用的 CNI 插件包括 Flannel、Calico、Weave 等，它们负责实现跨节点的 Pod 网络互通。
    • 每个 Node 都有一个不同的网段范围，并为部署到该节点的 Pod 分配 IP 地址。
  2. Kubernetes Service 和 ClusterIP
    • Pod 可以通过 IP 或者 Service（通常通过 ClusterIP 暴露的虚拟 IP）进行访问。
    • Service 对多个 Pod 进行负载均衡，当访问 Service 的 IP 地址时，流量会被自动分配到后端的多个 Pod。
    • Service 是基于 iptables 或 IPVS 的，能够将请求分发到后端的 Pod 上。

不同 Node 上的 Pod 之间通信的基本流程 ​

  1. Pod 发送数据包
    • 假设 Pod A 在 Node 1 上，Pod B 在 Node 2 上。当 Pod A 需要与 Pod B 通信时，首先会构造一个数据包，该数据包的目标地址是 Pod B 的 IP 地址。
  2. 路由查找
    • 数据包首先会经过 Node 1 的路由表。由于 Node 1 并不直接托管 Pod B，它会发现该数据包需要发送到 Node 2 才能到达 Pod B。
    • Node 1 的路由表是由 CNI 插件设置的，它知道哪个节点拥有哪个 IP 段的 Pod，基于此信息将数据包转发到 Node 2。
  3. 跨节点通信
    • VXLAN/Overlay 网络：如果使用的是 Overlay 网络（如 Flannel），数据包会通过 VXLAN 隧道封装。数据包会被封装成内网通信数据，并且通过隧道传递到 Node 2。Node 2 解封装数据包，并将其路由到 Pod B。
    • BGP/Direct Routing 网络：如果使用的是 BGP 或直接路由（如 Calico），数据包不会进行封装，而是直接通过路由表发送到 Node 2，随后到达 Pod B。
  4. Node 2 接收数据包
    • Node 2 接收到数据包后，会通过本地的路由表将数据包发送到相应的 Pod B。
    • 这时，Pod B 可以处理从 Pod A 发来的数据包，完成通信。

具体网络模型 ​

  1. Flannel（Overlay 网络）
    • Flannel 是一种 Overlay 网络插件，使用 VXLAN 技术创建虚拟网络。每个 Node 上的 Pod 通过隧道（Tunnel）相互通信。
    • 数据包会被封装成 VXLAN 报文并通过主机网络传输。
  2. Calico（路由网络）
    • Calico 使用 BGP 协议实现直接路由。每个节点之间建立直接的路由，数据包无需封装，可以直接通过网络路由到达目的地。
    • Calico 提供更高的性能，因为它避免了封装和解封装过程。

通信示例 ​

假设有两个 Node：

  • Node 1 上运行 Pod A，IP 地址为 10.244.1.2
  • Node 2 上运行 Pod B，IP 地址为 10.244.2.2
  1. Pod A 在 Node 1 上发起请求，目标 IP 是 Pod B 的 IP 地址 10.244.2.2。
  2. Node 1 查找路由表，发现 10.244.2.2 属于 Node 2 的网段。
  3. Node 1 使用 VXLAN 隧道（若使用 Flannel）或直接通过 BGP 路由（若使用 Calico）将数据包发送到 Node 2。
  4. Node 2 解封装数据包（如果使用 Overlay 网络），并通过路由将数据包转发到 Pod B。
  5. Pod B 接收到数据包并处理请求。

潜在问题 ​

  1. 网络插件故障
    • 如果 CNI 插件有问题，可能导致 Pod 间无法通信或延迟较高。
  2. 跨节点延迟
    • 不同节点的网络延迟可能较大，尤其在使用 Overlay 网络时，封装和解封装可能会增加通信的开销。
  3. IP 冲突或资源不足
    • 如果节点之间的 IP 地址分配不当，可能会导致 Pod IP 冲突，影响 Pod 的正常通信。

总结 ​

不同 Node 上的 Pod 之间通过 Kubernetes 网络插件（如 Flannel、Calico 等）建立的集群网络进行通信。CNI 插件为每个节点配置相应的路由表，确保跨节点的 Pod 可以相互访问。不同网络模型（如 Overlay 网络或 BGP 路由）影响了具体的通信方式，但 Kubernetes 的设计使得 Pod 之间的通信是透明和无缝的。

6. pod创建Pending状态的原因☆ ​

7. deployment和statefulset区别☆ ​

特性DeploymentStatefulSet
用途无状态应用有状态应用
状态管理无状态有状态，每个 Pod 保留自己的状态
存储无持久化存储持久化存储，每个 Pod 有独立存储
Pod 启动顺序无序启动和停止严格的启动和停止顺序
Pod 标识Pod 是可互换的，没有固定标识每个 Pod 有固定的标识（pod-0、pod-1）
适用场景无状态的微服务、Web 应用有状态的数据库、分布式系统、集群服务
滚动更新支持支持，但更新按顺序进行

总结 ​

  • Deployment 适用于无状态应用，关注的是快速扩展、灵活的滚动更新和可用性维护。
  • StatefulSet 适用于有状态应用，需要维护 Pod 的状态、顺序和持久化数据，确保分布式应用或数据库集群的正确运行。

8. kube-proxy有什么作用☆ ​

9. pod之间访问不通怎么排查☆ ​

1. 检查 Pod 的状态 ​

  • 使用 kubectl get pods 命令检查 Pod 是否处于 Running 状态。确保目标 Pod 正常运行，没有处于 CrashLoopBackOff 或 Pending 状态。
  • 可以使用 kubectl describe pod <pod-name> 来查看 Pod 的详细信息，包括事件日志，以检查是否有异常情况。

2. 检查 Pod 的网络配置 ​

  • IP 地址: 使用 kubectl get pod -o wide 查看 Pod 的 IP 地址。确认源 Pod 和目标 Pod 是否正确地分配了 IP 地址。
  • 网络插件: 确保你的集群中已经正确安装并配置了网络插件（如 Calico、Flannel 等）。如果网络插件有问题，可能导致 Pod 之间的网络不通。

3. 检查网络策略（NetworkPolicy） ​

  • 如果集群中使用了 NetworkPolicy，确保你的策略配置正确。NetworkPolicy 可以用来控制 Pod 之间的流量，如果配置不当，可能会阻止 Pod 之间的通信。
  • 使用 kubectl get networkpolicy 查看是否有任何 NetworkPolicy 应用在这些 Pod 上。必要时，可以暂时删除或修改策略进行测试。

4. 检查 DNS 服务 ​

  • Kubernetes 使用 DNS 来解析服务名。如果 Pod 通过服务名访问其他 Pod，确认 DNS 是否正常工作。
  • 可以使用 kubectl exec <pod-name> -- nslookup <service-name> 或 kubectl exec <pod-name> -- dig <service-name> 命令检查 DNS 解析是否正常。
  • 如果 DNS 不工作，可以检查 kube-dns 或 CoreDNS 服务的状态，并查看相关日志。

5. 检查防火墙和安全组 ​

  • 确保 Kubernetes 节点之间的网络没有被防火墙或安全组（如 AWS 的 Security Groups 或 GCP 的防火墙规则）阻断。节点之间需要允许相应的网络端口（如 VXLAN、BGP 等）开放，以确保网络插件能够正常工作。

6. 使用 ping 和 curl 进行测试 ​

  • 使用 kubectl exec 进入一个 Pod，然后尝试 ping 目标 Pod 的 IP 地址，或者使用 curl 测试目标 Pod 提供的服务（如 HTTP）。
  • 示例：kubectl exec -it <source-pod> -- ping <target-pod-ip> 或 kubectl exec -it <source-pod> -- curl <target-pod-ip>:<port>。
  • 如果 ping 成功但 curl 失败，可能是服务端口或协议的问题。

7. 检查 Service 配置 ​

  • 如果 Pod 通过 Kubernetes Service 进行访问，检查 Service 的配置是否正确，特别是 selector 标签是否匹配了目标 Pod。
  • 使用 kubectl describe service <service-name> 查看 Service 的详细信息，并确认目标 Pod 被正确地包含在后端。
  • 使用 kubectl get endpoints <service-name> 查看 Service 的 Endpoints，确保 Pod 被正确注册。

8. 查看节点的网络连接 ​

  • 如果问题存在于跨节点的 Pod 访问中，检查节点之间的网络是否正常。可以使用 ping 或 traceroute 测试节点之间的连通性。
  • 还可以使用 iptables 或 tc 命令检查节点上的网络规则是否正确配置。

9. 检查日志和事件 ​

  • 检查 Kubernetes 系统组件的日志（如 kubelet、kube-proxy）以及网络插件的日志，看看是否有任何错误或警告信息。
  • 使用 kubectl logs <component-pod> 查看这些组件的日志。

10. 重新启动相关组件 ​

  • 如果无法找到明显的原因，尝试重启相关的 Pod 或服务（如 DNS、网络插件）以查看问题是否能够解决。

10. k8s的Service是什么☆ ​

在 Kubernetes 中，Service 是一种资源对象，用于定义如何访问集群中的一组 Pod。它为这些 Pod 提供了一个稳定的网络服务接口，使得 Pod 可以通过固定的 IP 地址和 DNS 名称被访问，即使这些 Pod 的 IP 地址在集群中发生变化。

Service 的主要功能和类型 ​

  1. 负载均衡: Service 可以将流量分发到后端的多个 Pod 上，确保流量负载均衡，从而提供高可用性。
  2. 服务发现: Service 提供了一个稳定的 DNS 名称，使得其他 Pod 可以通过该名称访问服务，而不需要关心具体的 Pod IP 地址。
  3. 服务类型:
    • ClusterIP: 默认类型，服务只能在集群内部访问。它分配一个虚拟 IP 地址，仅在 Kubernetes 集群内部有效。
    • NodePort: 在每个节点上开放一个端口，将流量转发到 ClusterIP 类型的服务上。这样可以通过节点的 IP 地址和指定的端口访问服务。
    • LoadBalancer: 在支持的云环境中，创建一个外部负载均衡器，自动分配一个公共 IP 地址，将流量分发到 NodePort 类型的服务上。
    • ExternalName: 将服务映射到外部的 DNS 名称，而不是将流量路由到集群内部的 Pod 上。
  4. 服务选择器: Service 使用标签选择器来确定哪些 Pod 是服务的后端。通过标签选择器，可以灵活地选择需要服务的 Pod。
  5. 端口配置: Service 定义了服务的端口以及后端 Pod 的端口。外部访问时通过指定的端口访问 Service，然后 Service 将流量转发到后端 Pod 的相应端口。

11. Calico和flannel区别☆ ​

Calico和Flannel都是用于Kubernetes集群中网络配置的网络插件，但它们的设计理念和实现方式有所不同。下面是它们的主要区别：

Calico ​

  1. 网络模型: Calico 支持使用BGP（边界网关协议）来实现容器之间的网络连接，并且可以通过IP-in-IP或VXLan等技术进行封装。
  2. 网络策略: Calico 提供强大的网络策略功能，允许用户定义细粒度的流量控制规则，以实现更复杂的安全策略。
  3. 性能: 由于它使用了BGP等协议，Calico 通常具有较高的性能和可扩展性，特别是在大规模集群中。
  4. 支持的环境: Calico 不仅支持Kubernetes，还支持其他容器编排平台和裸金属环境。
  5. 数据平面: Calico 主要使用Linux内核的路由功能来实现数据平面。

Flannel ​

  1. 网络模型: Flannel 主要使用Overlay网络模型，即通过创建一个虚拟网络来封装和转发容器之间的流量。常见的实现有VXLAN、host-gw和aws-vpc等。
  2. 网络策略: Flannel 的网络策略功能较为基础，主要用于提供简单的网络覆盖，而不提供复杂的网络策略和安全控制。
  3. 性能: Flannel 的性能可能不如Calico，特别是在大规模集群中，因为Overlay网络模型可能引入一些额外的开销。
  4. 支持的环境: Flannel 主要针对Kubernetes环境进行优化，并且集成较为简单。
  5. 数据平面: Flannel 主要依赖Overlay技术来实现数据平面。

总的来说，Calico 更适合需要复杂网络策略和高性能的大规模集群，而Flannel 更加简单易用，适合小到中等规模的集群。选择哪个插件通常取决于你的具体需求和集群的规模。

12. pod DNS解析流程☆ ​

Kubernetes 中的 Pod 通过 DNS 进行服务发现和通信，这对于容器化应用的互联至关重要。Kubernetes 为集群内的 Pod 提供了 DNS 服务，允许 Pod 通过服务名称进行解析，而不必使用硬编码的 IP 地址。

Pod DNS 解析流程 ​

  1. Pod 启动并加入网络

    • 每个 Pod 都有一个唯一的 IP 地址，分配给它的网卡。Pod 启动时，Kubelet 会负责配置网络，确保 Pod 能够连接到 Kubernetes 集群的网络，并能够访问其他 Pod 和服务。

  2. DNS 配置

    • 当 Pod 启动时，Kubelet 会根据集群的 DNS 设置为该 Pod 配置

      /etc/resolv.conf
      /etc/resolv.conf

      文件，文件中通常包含：

      • nameserver：集群内 DNS 服务的 IP 地址。
      • search：定义域名搜索路径，例如 default.svc.cluster.local，表示 Pod 在解析域名时，优先按该路径查找。
      • options：包括超时时间和重试次数等。

    示例 /etc/resolv.conf 文件：

    yaml
    nameserver 10.96.0.10    # Cluster DNS IP (例如 CoreDNS 的服务 IP)
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
    nameserver 10.96.0.10    # Cluster DNS IP (例如 CoreDNS 的服务 IP)
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

  3. Pod 发起 DNS 查询

    • 当 Pod 内的应用尝试通过域名访问集群内的服务时，例如访问

      my-service.default.svc.cluster.local
      my-service.default.svc.cluster.local

      ：

      • 应用通过标准 DNS 解析机制，调用系统的 DNS 解析库（如 gethostbyname()），DNS 请求被发送到 /etc/resolv.conf 中配置的 nameserver。

  4. DNS 服务（CoreDNS 或 kube-dns）处理请求

    • Kubernetes 中运行的 DNS 服务（通常是 CoreDNS 或 kube-dns）会接收 Pod 发来的 DNS 请求。它们作为 DNS 服务器运行在 Kubernetes 中，并负责集群内服务名称到 IP 地址的解析。

  5. CoreDNS 或 kube-dns 查询服务的 ClusterIP

    • 当接收到 my-service.default.svc.cluster.local 的 DNS 请求时，CoreDNS 会根据请求的域名去查找该服务的 ClusterIP。
    • CoreDNS 查询 Kubernetes API Server，获取与服务名关联的 IP 地址。如果是 Headless Service（即没有 ClusterIP），CoreDNS 会返回该服务的所有 Pod 的 IP 地址列表。

  6. 返回 IP 地址

    • CoreDNS 成功解析后，将服务的 IP 地址返回给发起请求的 Pod。对于正常的 ClusterIP 服务，它会返回单个 ClusterIP；对于 Headless Service，它可能返回多个 Pod IP 地址。

  7. Pod 连接到服务

    • Pod 接收到解析结果后，应用程序使用返回的 IP 地址连接到目标服务或 Pod，并进行通信。

DNS 解析的内部工作原理 ​

  • Service DNS 名称格式

    • 完整服务的 DNS 名称格式为

      service-name.namespace.svc.cluster.local
      service-name.namespace.svc.cluster.local

      ，其中：

      • service-name：服务的名称。
      • namespace：服务所在的命名空间。
      • svc.cluster.local：集群的根域名。

    Kubernetes 支持使用短格式的域名。如果没有指定完整域名，DNS 服务会根据 /etc/resolv.conf 的 search 配置进行域名补全。例如，如果只查询 my-service，会自动补全为 my-service.default.svc.cluster.local。

  • DNS 轮询与负载均衡

    • 对于没有 ClusterIP 的 Headless Service，DNS 解析返回多个 Pod IP 地址（即服务的各个副本）。客户端会从返回的 IP 列表中随机选择一个，进行流量负载均衡。

  • ClusterIP 与 Headless Service

    • ClusterIP 服务有一个固定的 IP 地址，CoreDNS 将返回这个 IP 地址。
    • Headless Service 没有 ClusterIP，CoreDNS 返回与该服务相关联的 Pod IP 地址列表，客户端直接与这些 Pod 通信。

DNS 解析的错误与排查 ​

  1. DNS 解析失败
    • 如果 Pod 无法解析域名，常见的原因可能是：
      • CoreDNS Pod 未正常运行（可通过 kubectl get pods -n kube-system 检查 CoreDNS 状态）。
      • resolv.conf 配置错误或缺失 DNS 服务器地址。
      • 应用配置有误，没有正确使用集群的服务名称。
  2. DNS 请求超时
    • DNS 请求可能会超时，原因可能包括网络问题、DNS 服务负载过高等。可以通过 kubectl logs 查看 CoreDNS 日志排查问题。
  3. 服务未找到
    • 如果服务名称拼写错误或服务未在指定命名空间中创建，DNS 服务无法解析该服务。可以通过 kubectl get svc -n <namespace> 确认服务是否存在。

总结 ​

Kubernetes 中的 Pod 通过配置文件（如 /etc/resolv.conf）进行 DNS 解析。请求被 CoreDNS 或 kube-dns 服务处理，它们从 API Server 获取服务的 IP 地址，并返回给 Pod。通过 DNS 服务，Pod 可以通过服务名称轻松发现和连接到其他 Pod 和服务，实现集群内部的灵活通信和服务发现。

13. 节点NotReady可能的原因？会导致哪些问题？☆ ​

在 Kubernetes 集群中，节点（Node）的状态会影响整个集群的正常运行。如果某个节点的状态变为 NotReady，它意味着该节点无法正常运行 Pod，可能会导致一系列问题。

节点 NotReady 的可能原因 ​

  1. Kubelet 停止运行或不可达
    • Kubelet 是节点上的核心组件，负责与控制平面通信、管理容器等。如果 Kubelet 崩溃、停止运行或无法与 API Server 通信，节点状态可能会被标记为 NotReady。
  2. 网络故障
    • 节点与控制平面之间的网络连接中断、延迟过大或者出现分区，都会导致节点无法与 API Server 通信，从而被标记为 NotReady。
  3. Docker 或 Containerd 问题
    • 如果节点上的容器运行时（如 Docker、Containerd）出现故障（崩溃、挂起、配置错误），节点无法正常启动或管理 Pod，可能会被标记为 NotReady。
  4. 节点资源耗尽
    • 节点的资源（CPU、内存、磁盘）用尽也会导致其无法正常工作。例如，磁盘空间不足会导致 Kubelet 停止接收新的 Pod 调度请求，从而进入 NotReady 状态。
  5. 磁盘或文件系统问题
    • 文件系统出现故障、磁盘满了或损坏，可能会导致节点无法正常写入日志或其他必要文件，导致 NotReady 状态。
  6. 节点上的关键进程崩溃
    • 诸如 kube-proxy、flannel 等重要进程崩溃或失效，会影响节点的功能。尤其是 kubelet 或网络插件故障，通常会导致节点标记为 NotReady。
  7. 网络插件故障
    • Kubernetes 网络插件（如 Calico、Flannel、Weave 等）出现问题，导致节点与其他节点无法正常通信，会影响到节点的状态。
  8. 证书或配置过期
    • Kubernetes 依赖证书进行身份验证。如果节点上的证书过期，或者配置文件被意外修改，节点可能无法正常通信，从而进入 NotReady 状态。
  9. 系统时间不同步
    • 节点与控制平面的系统时间不同步可能导致认证失败、通信问题，进而导致节点 NotReady。
  10. API Server 无法访问节点
  • 如果节点的 API Server 连接丢失或过载，API Server 无法周期性地探测节点的状态，可能会导致节点被标记为 NotReady。

节点 NotReady 会导致哪些问题？ ​

  1. Pod 调度失败
    • 当节点处于 NotReady 状态时，Kubernetes 将停止将新的 Pod 调度到该节点上。集群中的工作负载可能会因为缺少足够的可用节点而无法正常运行。
  2. 现有 Pod 可能无法访问
    • 已经调度在该节点上的 Pod 可能会失效或变得不可访问。控制平面无法通过该节点与 Pod 进行交互，应用可能会出现宕机或不可用的情况。
  3. 数据丢失或不一致
    • 如果有状态应用（如数据库）运行在节点上，节点的 NotReady 状态可能导致数据无法同步或出现丢失，特别是在没有数据备份或持久化存储的情况下。
  4. 应用高可用性受损
    • 多副本的应用依赖于多个节点来确保高可用性。如果节点 NotReady，应用的副本数量可能不足，进而影响集群的冗余性和高可用性。
  5. 服务中断
    • 如果某个节点是应用服务的关键部分（例如负载均衡器、数据库等），NotReady 可能导致服务完全中断，影响用户体验。
  6. 卷的不可用性
    • 如果使用了本地持久卷（如 hostPath 或者本地 PV），节点不可用时，绑定在该节点上的持久卷将无法被其他节点访问，可能导致应用不可用。
  7. 网络问题
    • 某些网络拓扑或插件可能依赖于所有节点的健康状态。如果节点 NotReady，可能导致集群内部或外部的网络连接问题，影响整个集群的通信。

如何应对节点 NotReady 状态？ ​

  1. 检查 Kubelet 运行状况
    • 登录到节点，检查 Kubelet 日志，确认 Kubelet 是否在正常运行以及是否有错误日志。
  2. 验证网络连接
    • 检查节点与控制平面之间的网络连通性（如 ping、telnet），确认网络连接是否正常。
  3. 检查节点资源
    • 确认节点的 CPU、内存、磁盘空间是否充足。如果资源不足，清理不必要的文件或重启相关进程。
  4. 检查容器运行时
    • 确保 Docker 或 Containerd 等容器运行时正在正常工作，可以通过重启 Docker 服务来尝试修复。
  5. 监控和报警
    • 使用监控工具（如 Prometheus、Grafana 等）监控节点状态，提前预警节点资源不足或故障情况。
  6. 定期更新证书和配置
    • 确保 Kubernetes 节点证书和配置文件定期更新，防止因证书过期或配置错误导致的节点不可用。

总结 ​

节点进入 NotReady 状态通常意味着节点在 Kubernetes 集群中失去了正常功能。这个状态可能由多种原因引起，涉及到网络、资源、系统配置或运行时故障。及时发现并解决节点问题对于保持集群的健康状态和应用的高可用性至关重要。

14. HPA怎么实现的☆ ​

Kubernetes 中的 HPA（Horizontal Pod Autoscaler） 是一种自动伸缩机制，用于根据工作负载动态调整 Pod 的数量，从而保证应用的性能和资源利用率。HPA 主要依据 Pod 的 CPU 使用率、内存使用率或自定义指标（如 QPS、响应时间）等来决定是否自动增加或减少 Pod 数量。

HPA 的工作流程 ​

HPA 的工作原理包括以下几个步骤：

  1. 指标收集：
    • HPA 使用 Metrics Server 或者 Prometheus Adapter 等监控系统来获取当前集群中 Pod 的资源使用数据（例如 CPU 使用率、内存使用率等）。
    • 指标收集是定期进行的，默认情况下，HPA 每 15 秒检查一次相关指标。
  2. 决策算法：
    • HPA 使用内置的算法来决定是否进行 Pod 伸缩。最常用的是基于 CPU 使用率的算法。
    • 公式： 目标Pod数量=当前Pod数量×(当前 CPU 使用率目标 CPU 使用率)目标 Pod 数量 = 当前 Pod 数量 \times \left(\frac{\text{当前 CPU 使用率}}{\text{目标 CPU 使用率}}\right)目标Pod数量=当前Pod数量×(目标 CPU 使用率当前 CPU 使用率)
    • 比如，设定目标 CPU 使用率为 50%，而当前 CPU 使用率为 100%，那么 HPA 将认为需要将 Pod 数量翻倍来平衡负载。
  3. 自动伸缩：
    • 根据计算出的目标 Pod 数量，HPA 将通过控制器（如 Deployment、ReplicaSet 等）调整 Pod 的副本数量。
    • 如果目标 Pod 数量大于当前 Pod 数量，HPA 会创建更多的 Pod。
    • 如果目标 Pod 数量小于当前 Pod 数量，HPA 会缩减 Pod 数量。
  4. 稳态控制：
    • HPA 并不会立即将 Pod 数量调整到计算出的目标数量，而是逐步进行调整，避免因为瞬时峰值导致频繁伸缩。这种机制被称为 Cooldown，以确保系统的稳定性。
    • HPA 还可以设置最小和最大 Pod 数量，确保伸缩范围在设定的边界内。

HPA 的实现机制 ​

HPA 的实现依赖于以下几个核心组件：

  1. Metrics Server：
    • Metrics Server 是 Kubernetes 的核心组件之一，它从 Kubelet 中收集各个节点上容器的资源使用数据，并以聚合形式提供给 HPA。
    • HPA 通过 Metrics Server 来获取 Pod 的 CPU 和内存使用数据。
  2. API Server：
    • HPA 控制器通过 Kubernetes API Server 访问和修改集群状态。
    • 当 HPA 需要调整 Pod 副本数量时，它会调用 Deployment 或 ReplicaSet 的 scale 操作，API Server 负责处理该请求。
  3. HPA 控制器：
    • HPA 控制器运行在 Kubernetes 控制平面中，负责定期检查指定的 Pod 的资源使用情况，并根据预定义的策略决定是否进行水平扩展或收缩。
    • 该控制器根据配置好的策略和收集到的指标数据来计算目标 Pod 数量。
  4. Kube Controller Manager：
    • HPA 控制器是 Kube Controller Manager 中的一个组件。它定期检查应用的指标数据并据此调整 Pod 数量。
    • 伸缩操作由 Kube Controller Manager 中的控制器完成，确保集群状态与期望状态一致。

HPA 的配置 ​

HPA 的配置文件通常定义在 YAML 文件中，配置项包括目标对象、伸缩的指标类型、目标值、最小和最大 Pod 数量等。

示例 HPA 配置： ​

以下是一个简单的基于 CPU 使用率的 HPA 示例：

yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  • scaleTargetRef: 指定要伸缩的目标资源对象，这里是 nginx-deployment。
  • minReplicas 和 maxReplicas: 定义最小和最大 Pod 数量。
  • metrics: 定义伸缩的触发指标。在此例中，HPA 将基于 CPU 使用率，如果平均 CPU 使用率超过 50%，将进行扩容。

HPA 支持的指标类型 ​

HPA 支持多种指标类型，包括：

  1. 资源型指标（Resource Metrics）：
    • CPU 和内存等基础资源。
    • 这是最常用的 HPA 伸缩依据。
  2. 自定义指标（Custom Metrics）：
    • 用户可以定义自己的业务指标，如请求数、响应时间等，HPA 根据这些指标进行伸缩。
    • 通常使用 Prometheus Adapter 来获取自定义指标。
  3. 外部指标（External Metrics）：
    • HPA 还可以根据外部服务提供的指标进行伸缩，如来自云提供商的监控数据。

总结 ​

HPA 是 Kubernetes 中用于自动化管理 Pod 数量的机制，通过与 Metrics Server 或其他监控系统协同工作，实现了对应用的动态伸缩。它利用 cgroups 的底层机制，以及控制器来平衡集群负载，并确保应用的高可用性与稳定性。

15. request limit底层是怎么限制的☆ ​

在 Kubernetes 中，Request 和 Limit 是用于控制 Pod 中容器的资源使用的两个关键机制，主要针对 CPU 和内存资源。这些机制底层依赖于 Linux 内核中的 cgroups（控制组），通过 cgroups，Kubernetes 实现了对容器资源的隔离和限制。以下是 Kubernetes 如何在底层实现 Request 和 Limit 资源限制的细节：

1. Request 和 Limit 的概念 ​

  • Request：是容器所需要的最小资源量。Kubernetes 调度器在调度 Pod 时会考虑 Request 值，以确保节点有足够的资源来满足容器的需求。
  • Limit：是容器可以使用的资源的上限。容器不能超过这个资源量，否则可能会受到限制或者被终止。

2. 底层实现：基于 cgroups ​

cgroups 是 Linux 内核中的一种功能，允许对进程或进程组进行资源的控制与隔离。Kubernetes 使用 cgroups 来管理 CPU 和内存的使用。

1. CPU 的 Request 和 Limit ​

  • CPU Request：
    • Kubernetes 使用 cgroups 中的 cpu.shares 来管理 CPU 的 Request 值。
    • cpu.shares 是一个相对值，表示进程可以使用的 CPU 资源份额。调度器会根据 Request 值来分配 CPU 资源份额，确保容器能够获得相应的 CPU 资源。
    • 例如，如果一个容器的 CPU Request 是 500m（即 0.5 个核心），cgroups 会为其分配相应的 cpu.shares，保证它能至少使用 0.5 个核心的 CPU 时间。
  • CPU Limit：
    • Kubernetes 使用 cgroups 中的 cpu.cfs_quota_us 和 cpu.cfs_period_us 来限制 CPU 的使用。
    • cpu.cfs_quota_us 限制了容器在一段时间内可以使用的 CPU 时间。比如，如果 CPU Limit 被设置为 1 个核心（1000m），那么容器每 100ms 可以使用最多 100ms 的 CPU 时间。
    • 如果容器超过了这个限额，那么它将在当前周期中被阻塞，直到下一个周期才会继续执行。

2. 内存的 Request 和 Limit ​

  • 内存 Request：
    • 内存的 Request 并不会在运行时限制容器的使用，但 Kubernetes 调度器会根据 Request 值来确定是否将 Pod 调度到某个节点上。
    • 节点必须至少拥有该容器请求的内存量才能调度。
  • 内存 Limit：
    • Kubernetes 使用 cgroups 中的 memory.limit_in_bytes 来限制内存的使用。
    • 当容器超过了设定的内存 Limit，cgroups 会触发 Out of Memory (OOM) 杀手来终止该容器。
    • 例如，如果容器的内存限制被设置为 512Mi，那么 cgroups 会确保容器使用的内存不会超过 512Mi，否则该容器将被终止。

3. 调度阶段：Request 的作用 ​

  • 在调度阶段，Kubernetes 调度器会考虑 Pod 的 Request，并基于节点的可用资源决定将 Pod 调度到哪个节点。
  • 这确保了即使节点上运行了多个 Pod，它们的资源需求都能得到满足，不会出现资源过载。

4. 运行时阶段：Limit 的作用 ​

  • 在容器的运行时阶段，Kubernetes 使用 cgroups 强制执行 Limit 值。
  • 如果容器尝试使用超出其配置的 CPU 或内存资源，cgroups 会通过限流或终止（如 OOM）机制来限制容器的资源使用。

5. 动态调整 ​

  • Kubernetes 允许动态调整 Request 和 Limit，但调整生效需要重启容器，重新分配 cgroups 配置。
  • 动态调整时，调度器会根据新配置重新评估节点的资源情况。

总结 ​

  • Request 主要用于调度阶段，确保容器的资源需求能够被满足。
  • Limit 用于运行时阶段，通过 cgroups 强制执行 CPU 和内存资源的使用上限。
  • 这些机制通过 cgroups 来隔离和限制资源，使得 Kubernetes 能够高效管理和分配节点上的 CPU 和内存资源。

16. docker和container区别☆ ​

1. Docker 是一个容器平台 ​

  • Docker 是一个容器化平台，提供了开发、部署和运行容器化应用程序的工具和服务。
  • Docker 提供了创建、管理和分发容器的基础设施。它包括多个组件，比如 Docker CLI、Docker Daemon、Docker Hub、Docker Compose 等等。
  • Docker 的主要功能是使应用程序能够在隔离的环境中运行，确保一致性和便携性，无论是在开发环境、测试环境还是生产环境中。

2. Container 是一种虚拟化技术 ​

  • Container 是 Docker 及其他容器平台所使用的技术，本质上是一种虚拟化技术。容器封装了应用程序及其所有依赖项（例如库、环境变量、配置文件等），使其能够在任何兼容的操作系统上运行。
  • 容器是隔离的运行环境，类似于轻量级的虚拟机，但由于共享主机的内核，它们比虚拟机更轻量和高效。

关系 ​

  • Docker 创建和管理容器：Docker 是一种工具和平台，使用容器技术来封装应用程序并保证其在不同的环境中一致运行。
  • 容器是 Docker 的执行单元：容器是运行在 Docker 上的实际实例。Docker 用来创建和管理这些容器。

17. Pause容器的用途☆ ​

Pause 容器在 Kubernetes 中扮演了一个非常重要但低调的角色。它主要用于管理和维护 Pod 内的网络和 PID 命名空间，是 Pod 的“基础容器”。每个 Pod 都会包含一个 Pause 容器，它是 Pod 内其他所有容器的“父”容器。下面是 Pause 容器的几个关键用途：

1. 管理网络命名空间 ​

  • Pause 容器为 Pod 中的所有容器提供一个共享的网络命名空间。
  • 具体来说，所有同一个 Pod 中的容器都会共享 Pause 容器的 IP 地址和网络栈。通过这样做，Pod 中的所有容器可以在同一个网络命名空间内相互通信，而不需要额外的配置。
  • 如果没有 Pause 容器，每个容器都将独立拥有自己的网络栈，无法实现 Pod 内的容器网络共享。

2. PID 命名空间的共享 ​

  • 在某些场景中，Pod 中的所有容器会共享 Pause 容器的 PID 命名空间。这意味着 Pod 内的所有容器可以相互看到彼此的进程。
  • 这对于像 Sidecar 容器模式或需要进程级别协作的容器场景非常有用。

3. 作为 Pod 生命周期的管理器 ​

  • Pause 容器的启动标志着 Pod 的开始。一旦 Pause 容器启动，其他容器可以在这个基础上启动。
  • Pause 容器本身并不执行实际的应用程序逻辑，它的作用仅仅是作为一个占位符，用来管理 Pod 中的其他容器的生命周期。

4. 隔离与容器重启 ​

  • 由于 Pause 容器负责管理网络命名空间和进程命名空间，即使 Pod 中的应用容器崩溃或重启，网络配置仍然不会丢失。因为 Pause 容器一直保持运行，所以 Pod 的 IP 地址、端口映射等配置也不会发生变化。

5. 占用较少的资源 ​

  • Pause 容器非常轻量化，通常只运行一个空的、无实际操作的进程（例如 sleep infinity）。它的存在几乎不消耗任何计算资源，但其作用却至关重要。

总结 ​

Pause 容器的主要用途是为 Pod 提供共享的网络和 PID 命名空间管理，确保 Pod 内的容器可以协作和共享资源，同时简化了 Kubernetes 的 Pod 管理。尽管它本身不处理应用程序逻辑，但它的存在是 Pod 实现容器编排的重要基础。

18. K8S QoS等级☆ ​

Guaranteed,requests 和 limits 的值相同，因此该 Pod 属于 Guaranteed QoS 等级

yaml
apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  containers:
  - name: container-1
    image: nginx
    resources:
      requests:
        memory: "500Mi"
        cpu: "200m"
      limits:
        memory: "500Mi"
        cpu: "200m"
apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  containers:
  - name: container-1
    image: nginx
    resources:
      requests:
        memory: "500Mi"
        cpu: "200m"
      limits:
        memory: "500Mi"
        cpu: "200m"

Burstable,requests 和 limits 的值不同，因此该 Pod 属于 Burstable QoS 等级

yaml
apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
spec:
  containers:
  - name: container-1
    image: nginx
    resources:
      requests:
        memory: "500Mi"
        cpu: "200m"
      limits:
        memory: "1Gi"
        cpu: "500m"
apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
spec:
  containers:
  - name: container-1
    image: nginx
    resources:
      requests:
        memory: "500Mi"
        cpu: "200m"
      limits:
        memory: "1Gi"
        cpu: "500m"

BestEffort

决策顺序

Guaranteed > Burstable > BestEffort

19. Headless Service和ClusterIP区别☆ ​

在 Kubernetes 中，Headless Service 和 ClusterIP Service 都是用来暴露服务的，但它们的工作方式和使用场景有一些不同。

1. ClusterIP Service ​

概念：

  • ClusterIP 是 Kubernetes 中的默认服务类型。它会为服务分配一个虚拟的 IP 地址（ClusterIP），该 IP 地址只在集群内部可访问。
  • 通过该 IP 地址，集群内部的其他 Pod 可以访问这个服务。

工作方式：

  • Kubernetes 为 ClusterIP 服务自动创建一个负载均衡机制（通常基于 kube-proxy），将流量均匀地分发给服务后面的多个 Pod。
  • 该服务的 IP 地址和端口是集群内部的其他服务用来与其通信的主要方式。
  • DNS 会解析服务的名字为该 ClusterIP，所有请求都会被发送到这个虚拟 IP 地址，并由 kube-proxy 负责分发到具体的 Pod。

场景：

  • 适用于需要负载均衡的普通服务，例如 Web 应用、API 服务等。
  • 它是默认服务类型，用于在集群内部暴露服务，通常不直接面向外部用户。

示例：

yaml
apiVersion: v1
kind: Service
metadata:
  name: my-clusterip-service
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
apiVersion: v1
kind: Service
metadata:
  name: my-clusterip-service
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

2. Headless Service ​

概念：

  • Headless Service 是一种特殊类型的服务，不分配 ClusterIP。通过在 Service 的 spec 中将 clusterIP 字段设置为 None 来创建。
  • 这种服务不会提供负载均衡，也不会有虚拟 IP。相反，Kubernetes DNS 会直接返回与该服务关联的所有 Pod 的 IP 地址。

工作方式：

  • 当创建一个 Headless Service 时，Kubernetes 不会为服务分配一个虚拟 IP 地址。相反，DNS 解析会返回 Pod 的列表（即服务后面的所有 Pod 的 IP 地址）。
  • 客户端可以直接访问这些 Pod，而不经过服务的负载均衡机制。这对于一些需要直接访问每个 Pod 的场景（如 StatefulSets、数据库、服务发现等）非常有用。

场景：

  • Headless Service 常用于需要对每个 Pod 进行直接访问的场景，如数据库集群（如 Kafka、Cassandra、Elasticsearch）或其他需要 StatefulSet 的应用程序。
  • 特别适合 StatefulSet 中的应用，这类应用通常每个 Pod 都有独特的状态，不能简单地负载均衡。

示例：

yaml
apiVersion: v1
kind: Service
metadata:
  name: my-headless-service
spec:
  clusterIP: None
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
apiVersion: v1
kind: Service
metadata:
  name: my-headless-service
spec:
  clusterIP: None
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

区别 ​

  1. 是否分配 ClusterIP：
    • ClusterIP Service：为服务分配一个虚拟 IP 地址，并通过该 IP 地址将流量负载均衡到后端 Pod。
    • Headless Service：不分配虚拟 IP，DNS 直接返回后端 Pod 的 IP 地址，客户端可以直接与 Pod 通信。
  2. 流量分发方式：
    • ClusterIP Service：Kubernetes 提供的负载均衡器（kube-proxy）将流量分发到服务的 Pod。
    • Headless Service：没有负载均衡机制，客户端可以直接与特定 Pod 通信。
  3. 使用场景：
    • ClusterIP Service：适用于普通应用场景，尤其是需要负载均衡的服务。
    • Headless Service：适用于需要直接访问每个 Pod 的场景，特别是在有状态的应用（如数据库、StatefulSet 应用）中。

20. kubernetes Ingress原理☆ ​

21. 容器时区不一致如何解决？ ​

有四种方式解决:

1. 通过挂载宿主机的时区文件 ​

通过hostPath

yaml
spec:
  containers:
  - name: my-container
    image: your-image
    volumeMounts:
    - name: tz-config
      mountPath: /etc/localtime
      readOnly: true
    - name: timezone-config
      mountPath: /etc/timezone
      readOnly: true
  volumes:
  - name: tz-config
    hostPath:
      path: /etc/localtime
  - name: timezone-config
    hostPath:
      path: /etc/timezone
spec:
  containers:
  - name: my-container
    image: your-image
    volumeMounts:
    - name: tz-config
      mountPath: /etc/localtime
      readOnly: true
    - name: timezone-config
      mountPath: /etc/timezone
      readOnly: true
  volumes:
  - name: tz-config
    hostPath:
      path: /etc/localtime
  - name: timezone-config
    hostPath:
      path: /etc/timezone

2. 通过环境变量设置时区 ​

在某些容器镜像中，时区可以通过设置环境变量 TZ 来调整,但是需要确保容器镜像中的软件支持 TZ 变量（如 Alpine、Debian）

yaml
spec:
  containers:
  - name: my-container
    image: your-image
    env:
    - name: TZ
      value: "Asia/Shanghai"  # 设置为你需要的时区
spec:
  containers:
  - name: my-container
    image: your-image
    env:
    - name: TZ
      value: "Asia/Shanghai"  # 设置为你需要的时区

3. 构建自定义镜像修改时区 ​

FROM ubuntu:latest

RUN apt-get update && \
    apt-get install -y tzdata && \
    ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && \
    echo "Asia/Shanghai" > /etc/timezone
FROM ubuntu:latest

RUN apt-get update && \
    apt-get install -y tzdata && \
    ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && \
    echo "Asia/Shanghai" > /etc/timezone

4. 在容器启动脚本中设置时区 ​

bash
ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
echo "Asia/Shanghai" > /etc/timezone
ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
echo "Asia/Shanghai" > /etc/timezone

k8s中Network Policy的设计原理和实现方式 ​

kube-proxy怎么修改ipvs规则 ​

bash
kubectl edit cm kube-proxy -n kube-system


kind: ConfigMap
apiVersion: v1
data:
  config.conf: |
    apiVersion: kubeproxy.config.k8s.io/v1alpha1
    kind: KubeProxyConfiguration
    mode: "ipvs"
    ipvs:
      scheduler: "wrr"  # 修改调度算法为加权轮询
kubectl edit cm kube-proxy -n kube-system


kind: ConfigMap
apiVersion: v1
data:
  config.conf: |
    apiVersion: kubeproxy.config.k8s.io/v1alpha1
    kind: KubeProxyConfiguration
    mode: "ipvs"
    ipvs:
      scheduler: "wrr"  # 修改调度算法为加权轮询

探针有哪些？探测方法有哪些？ ​

探针类型 ​

  • Liveness Probe（存活探针）
    • 主要用于检测容器是否存活。如果探针失败，Kubernetes 会将容器视为已崩溃并进行重启。它确保容器在运行过程中没有卡死或出现无法恢复的故障。
  • Readiness Probe（就绪探针）
    • 用于检测容器是否准备好接收请求。如果探针失败，容器将从服务的负载均衡池中移除，直到它变得“就绪”。
  • Startup Probe（启动探针）
    • 专门用于容器启动期间的探测，适合于启动时间较长的应用程序。它检测容器是否已经启动完成。如果失败，容器会被重启。Startup Probe 主要用于替代 Liveness Probe，当容器需要很长时间才能启动时，可以防止不必要的重启。

探测方法 ​

HTTP GET 请求探测

livenessProbe:
  httpGet:
    path: /healthz       # 访问的路径
    port: 8080           # 容器监听的端口
  initialDelaySeconds: 3  # 延迟 3 秒后开始探测
  periodSeconds: 10       # 每 10 秒探测一次
livenessProbe:
  httpGet:
    path: /healthz       # 访问的路径
    port: 8080           # 容器监听的端口
  initialDelaySeconds: 3  # 延迟 3 秒后开始探测
  periodSeconds: 10       # 每 10 秒探测一次

TCP Socket 探测

livenessProbe:
  tcpSocket:
    port: 8080           # 容器监听的端口
  initialDelaySeconds: 3  # 延迟 3 秒后开始探测
  periodSeconds: 10       # 每 10 秒探测一次
livenessProbe:
  tcpSocket:
    port: 8080           # 容器监听的端口
  initialDelaySeconds: 3  # 延迟 3 秒后开始探测
  periodSeconds: 10       # 每 10 秒探测一次

Exec 命令探测

Kubernetes 在容器内执行指定的命令，并通过命令的退出状态码来判断容器的健康状况。退出状态码为 0 表示探测成功，非 0 表示失败。

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy        # 在容器内运行的命令
  initialDelaySeconds: 3   # 延迟 3 秒后开始探测
  periodSeconds: 10        # 每 10 秒探测一次
livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy        # 在容器内运行的命令
  initialDelaySeconds: 3   # 延迟 3 秒后开始探测
  periodSeconds: 10        # 每 10 秒探测一次

pod健康检查失败可能的原因和排查思路 ​

metrics-server采集指标数据链路 ​

Kubernetes 中的 metrics-server 是一个轻量级的指标收集器，用于从集群中的所有节点和 Pods 中收集资源使用数据（如 CPU、内存等），并将其提供给 Kubernetes API。metrics-server 主要用于支持 Kubernetes 的自动伸缩机制，如Horizontal Pod Autoscaler (HPA) 和Vertical Pod Autoscaler (VPA)

1.kubelet 采集数据：

  • 节点上的 kubelet 定期从容器运行时和 cAdvisor 收集容器的资源使用情况，包括 CPU 和内存的使用率。

2.metrics-server 获取数据：

  • metrics-server 通过 HTTPS 调用每个节点的 kubelet /metrics/resource 端点，获取节点和 Pod 的资源使用数据。

3.汇总数据：

  • metrics-server 收集并汇总所有节点的数据，将其存储在自身的内存中。

4.暴露数据：

  • metrics-server 通过 Kubernetes API Server 暴露这些资源使用数据，供 HPA、kubectl top 等使用。

k8s服务发现有哪些方式？ ​

  1. 环境变量（Environment Variables）
  2. DNS 方式（CoreDNS）

Kubernetes 内部使用 CoreDNS 提供集群内的 DNS 解析，允许 Pod 通过服务名进行访问。这是最常用的服务发现方式。

  • 工作原理
    • 每个服务在 Kubernetes 内部会自动分配一个 DNS 名称，Pod 可以通过这个 DNS 名称访问服务。
    • 服务的 DNS 名称格式通常为 service-name.namespace.svc.cluster.local，也可以简化为 service-name 或 service-name.namespace，在同一 namespace 下访问时，直接使用 service-name 即可。

3.服务的 ClusterIP

  1. 外部负载均衡（External Load Balancer）
  2. Headless Service

在某些情况下，需要绕过 Kubernetes 内置的负载均衡机制，直接与每个 Pod 通信。这时可以使用 Headless Service。

  • 工作原理：
    • 当创建 Service 时，将 spec.clusterIP 字段设置为 None，表示该服务没有 ClusterIP。
    • Kubernetes 不会为无头服务创建负载均衡，DNS 解析会返回 Pod 的 IP 地址，而不是服务的 ClusterIP。
    • 通过 Headless Service，客户端可以直接与每个 Pod 通信，这对于需要对 Pod 进行个性化管理的应用（如数据库主从架构）非常有用。

6.NodePort

7.Ingress

pod几种常用状态 ​

1. Pending（待调度） ​

  • 定义：Pod 已被创建，但尚未被调度到一个节点上，或者已经调度到节点上，但容器还没有开始运行。
  • 可能原因
    • Pod 正在等待调度程序将其分配到一个适当的节点。
    • 节点资源不足，导致 Pod 无法立即调度。
    • 存在调度约束或资源限制，影响 Pod 的调度。

2. Running（运行中） ​

  • 定义：Pod 已经被调度到一个节点上，且容器正在运行中。
  • 子状态
    • Containers Running：Pod 内的所有容器都在运行中。
    • Containers Waiting：Pod 内的某些容器正在等待某些条件（如拉取镜像完成或等待其他容器启动）。

3. Succeeded（成功） ​

  • 定义：Pod 中的所有容器已成功完成执行，并且 Pod 处于正常终止状态。这通常用于短期运行的任务或批处理作业。
  • 特征
    • Pod 的所有容器退出状态码为 0，表明它们的执行是成功的。
    • 在 Job 类型的 Pod 中，当所有容器都成功完成时，Pod 的状态会变为 Succeeded。

4. Failed（失败） ​

  • 定义：Pod 中的一个或多个容器运行失败或退出时，Pod 的状态会变为 Failed。
  • 可能原因
    • 容器退出状态码不是 0。
    • 容器在启动过程中发生错误，无法正常运行。
    • 容器多次重启失败，最终达到失败阈值。

5. Unknown（未知） ​

  • 定义：Pod 的状态无法被确定，通常由于节点失联或无法联系。
  • 可能原因
    • 节点宕机或网络问题导致 Kubernetes 无法获取 Pod 状态。
    • 可能需要调查节点和网络的问题来恢复 Pod 的正常状态。

6. Terminating（终止中） ​

  • 定义：Pod 正在被删除过程中。
  • 特征
    • 当用户发起删除请求时，Pod 的状态会变为 Terminating。
    • 容器会收到终止信号，完成清理工作后才会完全删除 Pod。

Pod 生命周期的钩子函数 ​

允许用户在 Pod 的生命周期的特定阶段执行自定义操作。这些钩子函数用于处理容器的初始化、预停止、和容器的退出等操作

1. PostStart 钩子 ​

  • 定义：PostStart 钩子在容器启动后立即执行，但在容器的 ENTRYPOINT 或 CMD 指令执行之前。
bash
spec:
  containers:
  - name: my-container
    image: my-image
    lifecycle:
      postStart:
        exec:
          command: ["sh", "-c", "echo 'PostStart hook'"]
spec:
  containers:
  - name: my-container
    image: my-image
    lifecycle:
      postStart:
        exec:
          command: ["sh", "-c", "echo 'PostStart hook'"]

2. PreStop 钩子 ​

  • 定义：PreStop 钩子在容器被终止之前执行，允许容器完成清理工作或执行其他操作。
bash
spec:
  containers:
  - name: my-container
    image: my-image
    lifecycle:
      preStop:
        exec:
          command: ["sh", "-c", "echo 'PreStop hook'"]
spec:
  containers:
  - name: my-container
    image: my-image
    lifecycle:
      preStop:
        exec:
          command: ["sh", "-c", "echo 'PreStop hook'"]
  1. 钩子类型

exec：执行命令或脚本

exec:
  command: ["sh", "-c", "echo 'Hello World'"]
exec:
  command: ["sh", "-c", "echo 'Hello World'"]

httpGet：发起 HTTP GET 请求

bash
httpGet:
  path: /healthz
  port: 8080
  host: example.com
httpGet:
  path: /healthz
  port: 8080
  host: example.com

tcpSocket：检查 TCP 端口的连接

bash
tcpSocket:
  port: 8080
tcpSocket:
  port: 8080

ipvs为什么比iptables效率高 ​

1. 专门设计的负载均衡器 ​

  • IPVS：
    • IPVS 是一个专门设计的负载均衡解决方案，旨在处理大规模的流量和提供高效的负载均衡功能。
    • 它基于 Linux 内核中的 netfilter 框架，但独立于 IPTables 之外，作为一个专门的负载均衡模块存在。
    • IPVS 使用高效的数据结构（如哈希表）来存储和管理虚拟服务器和真实服务器的映射。
  • IPTables：
    • IPTables 主要用于网络过滤和防火墙规则的设置，尽管它可以用于负载均衡，但它不是专门为此设计的。
    • 在负载均衡场景中，IPTables 需要处理复杂的规则集，这会导致较高的性能开销。

2. 数据结构和算法 ​

  • IPVS：
    • IPVS 使用了高效的数据结构（如哈希表和循环链表）来存储和管理流量映射。这些数据结构允许快速的查找和更新操作，从而提高了负载均衡的效率。
    • 它使用了专门的负载均衡算法（如轮询、加权轮询、最少连接等），这些算法经过优化以提高性能。
  • IPTables：
    • IPTables 使用链表来管理规则，虽然适用于网络过滤，但在负载均衡场景中，链表的查找和处理速度较慢。
    • 对于每个数据包，IPTables 需要遍历规则链表，这会引入额外的开销，特别是在规则数量较多时。

3. 处理数据包的方式 ​

  • IPVS：
    • IPVS 在内核空间处理流量，能够直接访问网络数据包的低级信息，因此它的处理速度较快。
    • 它支持直接的负载均衡决策，而不需要经过复杂的用户空间逻辑。
  • IPTables：
    • IPTables 的处理过程可能涉及用户空间到内核空间的多次切换，这会增加延迟。
    • 在负载均衡模式下，IPTables 需要通过复杂的规则处理每个数据包，可能导致性能瓶颈。

4. 高并发处理能力 ​

  • IPVS：
    • IPVS 能够处理更高的并发流量，因为它为负载均衡操作优化了内核级别的处理路径。
    • 它通过高效的调度机制和流量管理能力来确保低延迟和高吞吐量。
  • IPTables：
    • IPTables 在高并发流量下可能出现性能下降，因为规则处理的开销会增加，特别是当规则数量较多时。

5. 负载均衡的高级功能 ​

  • IPVS：
    • 提供了多种负载均衡算法，允许在不同的场景中选择最合适的算法。
    • 支持会话保持、健康检查等高级功能，使得在处理复杂流量时更具灵活性。
  • IPTables：
    • 负载均衡功能相对简单，主要依赖于 NAT 和转发规则，功能不如 IPVS 丰富

总结 ​

IPVS 在处理大规模流量和负载均衡时比 IPTables 更高效，主要因为 IPVS 是专门设计的负载均衡解决方案，具有优化的数据结构、高效的算法、低延迟的处理路径以及强大的并发处理能力。IPTables 虽然可以用于负载均衡，但它的设计初衷是网络过滤，因此在负载均衡场景中的性能较低

calico网络原理、组网方式 ​

Network Policy使用场景 ​

kubectl exec 实现的原理 ​

  1. 用户发起命令
bash
kubectl exec -it my-pod -- /bin/bash
kubectl exec -it my-pod -- /bin/bash

2. Kubernetes API Server ​

kubectl 客户端将命令请求发送到 Kubernetes API Server。API Server 是 Kubernetes 的核心组件，负责处理和转发请求。

  • 创建 Exec 请求： kubectl exec 会创建一个新的 API 请求，向 API Server 的 /api/v1/namespaces/{namespace}/pods/{name}/exec 端点发送请求。
  • 请求参数： 请求中包括要执行的命令、容器名称、交互模式（如果有）以及其他相关参数（如输入输出流配置）。

3. API Server 转发请求 ​

API Server 接收到 kubectl exec 请求后，会将请求转发到适当的 kubelet。

  • 验证和授权： API Server 需要验证用户是否有权限在指定 Pod 上执行命令，确保请求的安全性。
  • 调度请求： API Server 通过 kubelet API 将请求转发到 Pod 所在的节点上的 kubelet

4. Kubelet 执行命令 ​

kubelet 是运行在每个节点上的组件，负责管理 Pod 的生命周期和执行容器内的命令。

  • 处理 Exec 请求： kubelet 处理 API Server 转发过来的 Exec 请求，启动一个新的 stdin、stdout 和 stderr 流来执行命令。
  • 创建容器运行时的连接： kubelet 通过容器运行时（如 Docker、containerd）启动命令。通常，kubelet 会通过容器运行时的 API 直接与容器交互。

5. 执行命令 ​

  • 交互模式： 如果 kubectl exec 请求是交互模式的（即使用了 -it 选项），kubelet 会创建一个伪终端（pseudo-TTY）和管道，以便用户可以实时输入命令和查看输出。
  • 非交互模式： 对于非交互模式，kubelet 会直接执行命令并返回输出结果给 kubectl。

6. 数据流 ​

  • 输入输出流： kubectl exec 通过 stdin、stdout 和 stderr 与容器内的命令进行数据交互。数据流在客户端（kubectl）和容器之间进行传输。
  • 实时交互： 如果是交互模式，用户的输入会被实时发送到容器内，容器的输出也会实时返回给用户。

7. 结果返回 ​

  • 获取结果： 命令执行完成后，kubelet 将结果返回给 API Server，然后 API Server 将结果传递给 kubectl 客户端。
  • 显示结果： kubectl 客户端将命令的输出显示在终端上。如果是交互模式，用户可以继续与容器进行交互。

8. 异常处理 ​

  • 错误处理： 如果在命令执行过程中发生错误，kubectl 和 kubelet 会处理这些错误，并将错误信息返回给用户。

cgroup中限制CPU的方式有哪些 ​

kubeconfig存放内容 ​

kubeconfig 文件是 Kubernetes 用于存储集群访问信息的配置文件，它使得 kubectl 和其他 Kubernetes 工具能够连接和操作 Kubernetes 集群。kubeconfig 文件通常位于用户主目录下的 .kube/config 文件中

Harbor有哪些组件 ​

Harbor高可用怎么实现 ​

ETCD调优 ​

假设k8s集群规模上千，需要注意的问题有哪些？ ​

service和endpoints是如何关联的？ ​

Service 定义了如何访问一组 Pods，提供了稳定的访问入口。

Endpoints 列出了与 Service 关联的 Pods 的实际 IP 地址和端口。

Service 和 Endpoints 的关联是通过 Service 的选择器来动态管理的，确保 Service 的访问入口始终反映出实际的后端 Pods

ReplicaSet、Deployment功能是怎么实现的？ ​

scheduler调度流程 ​

helm工作原理是什么？ ​

helm chart rollback实现过程是什么？ ​

velero备份与恢复流程是什么 ​

docker网络模式 ​

如何减⼩dockerfile⽣成镜像体积？ ​

k8s日志采集方案 ​

k8s证书过期怎么更新 ​

k8s节点维护注意事项 ​

Linux容器技术的基础原理 ​

Kubernetes Pod的常见调度方式 ​

Kubernetes各模块如何与API Server通信 ​

kubelet监控worker节点如何实现 ​