K8s-Day10|易北河的个人博客

1. 什么是Headless服务？它与普通Service有什么区别？有什么使用场景

在 Kubernetes 中，Service 是一种抽象，用于定义一组 Pod 的访问策略。根据 Service 的类型不同，其功能和使用场景也有所不同。Headless 服务是一种特殊的 Service 类型，它与普通 Service 最大的区别在于：不分配 ClusterIP。

Headless 服务的定义

Headless 服务是指将 spec.clusterIP 设置为 None 的 Service。它不会通过 Kubernetes 的虚拟 IP（ClusterIP）进行负载均衡，而是直接暴露后端 Pod 的 IP 地址。

kind: Service
apiVersion: v1
metadata:
  name: my-headless-service
spec:
  clusterIP: None   # 关键点：不分配 ClusterIP
  ports:
    - port: 80
      targetPort: 80
  selector:
    app: my-app

Headless 服务与普通 Service 的区别

特性	普通 Service (ClusterIP)	Headless Service
是否分配 ClusterIP	分配	不分配
负载均衡	支持（kube-proxy 实现）	不支持
DNS 解析	返回 Service 的 ClusterIP	返回所有匹配 Pod 的 IP 列表
适用场景	微服务间通信、负载均衡	直接访问 Pod、有状态应用（如 StatefulSet）

使用场景

StatefulSet 应用发现
- 在有状态应用中（如 MySQL 主从、ZooKeeper 集群），每个 Pod 都需要被唯一标识并直接访问。
- Headless Service 可配合 Kubernetes DNS 插件生成稳定的 DNS 名称（如 pod-0.my-headless-svc.namespace.svc.cluster.local）。
客户端自定义负载均衡
- 当客户端希望绕过 kube-proxy 的负载均衡机制，自行控制流量分发逻辑时（例如使用客户端 SDK 实现一致性哈希等算法）。
调试和监控
- 有时为了排查问题或收集指标，需要直接访问某个 Pod 的 IP 地址，而不想经过负载均衡器。
P2P 网络结构
- 在分布式系统中，节点之间需要建立点对点连接（如 Kafka、Redis Cluster 等），Headless Service 可以帮助实现这种网络拓扑。

2. 如何配置Horizontal Pod Autoscaler（HPA）进行自动扩容？它基于哪些指标来决定扩容

在 Kubernetes 中，Horizontal Pod Autoscaler (HPA) 是一种自动扩缩容机制，它可以根据 CPU、内存使用率或其他自定义指标动态调整 Deployment、ReplicaSet 或 StatefulSet 的副本数（Pod 数量），以应对流量波动并保持服务稳定。

如何配置 HPA 进行自动扩容？

前提条件

启用 Metrics Server：HPA 依赖于 metrics-server 来获取 Pod 的资源使用情况。
确保已部署 Deployment/ReplicaSet：HPA 只能作用于控制器管理的资源。
设置资源请求（resources.requests）：HPA 根据资源请求值来计算使用率。

示例配置步骤

1. 创建一个 Deployment（假设你还没有）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"

2. 创建 HPA（基于 CPU 使用率）

你可以通过YAML 文件创建 HPA。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
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

HPA 支持的扩缩容指标类型

HPA 支持以下几类指标：

指标类型	描述	示例
CPU 使用率	基于容器 CPU 请求值的百分比	`averageUtilization: 50`
内存使用率	基于容器内存请求值的百分比	同上，`name: memory`
自定义指标（Custom Metrics）	用户自定义的指标，如 HTTP 请求延迟、队列长度等	Prometheus、KEDA 等提供支持
外部指标（External Metrics）	来自集群外部的指标，如 AWS SQS 队列长度、RabbitMQ 消息数等	结合适配器使用

3. Kubernetes中的集群高可用方案有哪些？如何保证K8s API Server的高可用

在 Kubernetes 中，高可用（High Availability, HA）是保障系统稳定运行的重要机制。Kubernetes 本身提供了多种方式来实现集群和组件的高可用性，尤其是 API Server 的高可用 是整个控制平面稳定性的核心。

Kubernetes 集群高可用方案概述

控制平面组件高可用

Kubernetes 控制平面包含多个关键组件，其中 API Server 是最核心的组件之一。为保证其高可用性，通常需要对以下组件进行冗余部署：

组件	高可用方案
API Server	多节点部署 + 负载均衡（如 Keepalived、HAProxy、云平台 ELB）
etcd	部署为多节点集群（推荐至少 3 节点），使用 Raft 协议保持一致性
Controller Manager	多副本部署，仅一个活跃实例
Scheduler	多副本部署，仅一个活跃实例
Cloud Controller Manager	多副本部署（如果使用云平台）

注意：虽然某些组件支持多副本，但它们默认情况下只有一个处于活跃状态（leader election 机制）。

如何保证 Kubernetes API Server 的高可用？

API Server 是所有操作的入口，包括 kubectl、控制器、调度器等都会与其交互。因此，确保其高可用至关重要。

方法一：多节点部署 + 负载均衡

1. 多个 API Server 实例部署

在多个 Master 节点上部署 API Server；
所有 API Server 实例连接同一个 etcd 集群；
每个 API Server 独立提供服务，互不依赖；

2. 前端负载均衡器配置

使用 HAProxy、Keepalived、Nginx 或云平台提供的 LoadBalancer（如 AWS ELB、GCP LB、阿里云 SLB）；
将客户端请求分发到多个 API Server；
示例架构：

Client → [LoadBalancer] → api-server-01, api-server-02, api-server-03

3. TLS 证书配置

生成 API Server 证书时，需包含负载均衡器地址或 VIP（虚拟 IP）作为 SAN（Subject Alternative Name）；
示例 SAN：

IP.1 = 192.168.1.100 (VIP)
DNS.1 = kubernetes.default
DNS.2 = kubernetes.default.svc
DNS.3 = kubernetes.default.svc.cluster.local

方法二：使用云平台托管控制平面（Managed Control Plane）

如果你使用的是云厂商（如 AWS EKS、Azure AKS、Google GKE、阿里云 ACK），可以直接启用 托管控制平面，由云平台自动管理 API Server、etcd 和其他控制组件的高可用性。

优势：

自动维护、升级；
天然支持多可用区部署；
内置监控与故障恢复；
安全加固（RBAC、审计日志等）；

方法三：使用 Ingress 对外暴露 API Server（可选）

对于开发/测试环境，可以将 API Server 通过 Ingress + TLS 暴露给外部访问，结合 DNS 解析实现统一入口。

注意：生产环境建议直接通过 LoadBalancer 或 BGP 路由方式暴露 API Server。

4. 如何根据Pod的状态信息（如CrashLoopBackOff）来进行故障排查

在 Kubernetes 中，Pod 的状态信息（如 CrashLoopBackOff）是诊断容器启动失败或运行异常的重要线索。下面将详细说明如何根据 Pod 状态进行故障排查，并结合你提供的 Kubernetes 项目规范 和 历史经验教训 提供标准化流程。

一、查看 Pod 状态和事件信息

查看 Pod 状态

kubectl get pods

输出示例：

NAME                             READY   STATUS             RESTARTS   AGE
my-pod                           0/1     CrashLoopBackOff   5          5m

查看 Pod 详细信息

bash

重点关注以下字段：

Status: 当前状态（如 CrashLoopBackOff）
Reason: 失败原因（如 Back-off restarting failed container）
Events: 显示最近的调度、拉取镜像、启动容器等事件日志

二、CrashLoopBackOff 含义及常见原因

CrashLoopBackOff 表示什么？

当容器启动后立即崩溃，kubelet 会尝试重启容器。如果容器反复崩溃，Kubernetes 会进入一个“回退重启”机制，表现为 CrashLoopBackOff 状态。

常见原因包括：

原因	描述
容器镜像问题	镜像不存在、权限不足、命令错误等
应用启动失败	缺少配置文件、端口冲突、数据库连接失败等
资源限制	内存不足被 OOMKilled、CPU 不足导致卡顿
探针失败	livenessProbe 检查失败导致频繁重启
初始化错误	InitContainer 失败，导致主容器无法启动

三、具体排查步骤（推荐顺序）

1. 查看容器日志（包含上一次崩溃的日志）

# 查看当前容器日志
kubectl logs my-pod

# 查看上一次崩溃的日志（非常重要！）
kubectl logs my-pod --previous

2. 查看 Pod 事件日志（用于定位根本原因）

kubectl describe pod my-pod

关注 Events 部分，例如：

Failed to pull image "my-image:latest": rpc error: code = Unknown desc = ...
Back-off restarting failed container

3. 检查资源限制与请求是否合理

kubectl get pod my-pod -o jsonpath='{.spec.containers[*].resources}'

4. 检查健康检查探针（liveness/readiness probe）

kubectl get pod my-pod -o yaml | grep -A 10 'livenessProbe'

5. 检查 InitContainer 是否失败

kubectl describe pod my-pod

5. 如何为K8s中的Pod设置生命周期钩子（Lifecycle Hooks）？有哪些应用场景

在 Kubernetes 中，Pod 生命周期钩子（Lifecycle Hooks） 允许你在容器的生命周期中执行特定的操作。Kubernetes 提供了两个主要的生命周期钩子：

postStart：容器创建后立即执行
preStop：容器终止前执行

这些钩子可用于执行初始化脚本、优雅关闭服务、清理资源等操作。

一、生命周期钩子类型

钩子名称	触发时机	用途
postStart	容器创建完成后立即调用	执行初始化脚本、健康检查准备等
preStop	容器终止前调用	执行优雅退出、数据持久化、资源清理等

二、配置方式

你可以在 Pod 的 YAML 文件中为每个容器定义这两个钩子，它们可以是 exec 命令 或 HTTP 请求。

示例 1：使用 exec 命令设置 postStart 和 preStop

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
    - name: nginx
      image: nginx
      lifecycle:
        postStart:
          exec:
            command: ["sh", "-c", "echo 'Container started' > /tmp/lifecycle.log"]
        preStop:
          exec:
            command: ["sh", "-c", "echo 'Container stopping' >> /tmp/lifecycle.log && sleep 10"]

ostStart 在容器启动后异步执行，不能保证在主进程之前完成。
preStop 必须执行完毕才能进入终止流程，默认等待时间是 30 秒，可通过 terminationGracePeriodSeconds 调整。

6. 如何在K8s集群中进行备份和恢复？常用的备份工具有哪些

在 Kubernetes 集群中进行备份和恢复是保障系统稳定性和灾难恢复能力的重要环节。Kubernetes 本身不提供原生的备份机制，但可以通过第三方工具或自定义脚本实现对集群资源、配置、数据等的完整备份与恢复。

一、K8s 备份的核心内容

内容	描述
ETCD 数据	包含所有集群状态信息（推荐优先备份）
Kubernetes 资源对象	包括 Deployment、Service、ConfigMap、Secret 等
持久化数据（PV/PVC）	如数据库、日志文件、用户上传的数据等
证书与密钥	TLS 证书、kubeconfig 文件、ServiceAccount Token
节点配置	`/etc/kubernetes/manifests` 下的静态 Pod 定义等

二、ETCD 备份与恢复（核心）

ETCD 是 Kubernetes 的“唯一真相来源”，因此必须定期备份。

ETCD 快照备份命令：

ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /backup/etcd-snapshot-$(date +%Y%m%d).db

推荐每天定时执行，并使用 cron 或 systemd timer 自动化。

恢复 ETCD 快照：

ETCDCTL_API=3 etcdctl \
snapshot restore /backup/etcd-snapshot.db \
--data-dir=/var/lib/etcd-from-backup

三、常用 Kubernetes 备份工具

工具名称	功能特点	是否支持 PV 数据	是否支持集群迁移	适用场景
Velero	支持全量备份（资源+PV）、远程存储支持良好	是	是	生产环境首选
Heptio Ark（旧版 Velero）	已被 Velero 替代	-	-	不再推荐
etcdctl	仅备份 etcd 数据	否	否	基础维护用途
Kasten K10	图形界面、策略驱动、支持多种云平台	是	是	企业级灾备
Stash (AppsCode)	支持备份到 S3、GCS、Azure Blob 等	是	是	云厂商友好
Arkade Backup	简单易用、适合中小规模集群	是	是	快速部署
Restic	用于备份容器文件系统，常与 Velero 结合使用	是	是	文件级备份
Kubeadm + etcd static pod	手动备份 etcd 静态 Pod	否	否	单节点测试环境

7. 集群中的服务有哪几种方式暴露，提供给集群外使用

在 Kubernetes 中，将服务暴露给集群外部访问是实现对外服务提供能力的关键步骤。Kubernetes 提供了多种方式来实现服务的外部暴露，每种方式适用于不同的场景和需求。

一、Kubernetes 中服务暴露的常见方式

类型	描述	使用场景
ClusterIP（默认）	在集群内部提供一个虚拟 IP，仅限集群内访问	微服务之间通信（不对外暴露）
NodePort	在每个 Node 上开放一个固定端口，集群外可通过 `<NodeIP>:<NodePort>` 访问	开发测试环境快速暴露服务
LoadBalancer	基于 NodePort，在云平台自动创建外部负载均衡器（如 AWS ELB、阿里云 SLB）	生产环境对外暴露服务
Ingress	提供基于 HTTP/HTTPS 的路由规则，统一入口管理多个 Service	多个服务共享一个公网 IP，支持路径/域名路由
ExternalName	将服务映射到外部 DNS 名称（如 `api.example.com`）	引用集群外部服务

二、详细说明与配置示例

1. NodePort

特点：

在所有节点上开放指定端口；
集群外通过任意节点 IP + NodePort 访问；
不依赖云平台，适用于本地或私有部署环境；

示例 YAML：

kind: Service
apiVersion: v1
metadata:
  name: my-service-nodeport
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
      nodePort: 30080   # 可选：若不指定，系统自动分配

注意：nodePort 范围默认为 30000-32767，可在 kube-apiserver 中修改。
2. LoadBalancer

特点：

适用于云厂商（如 AWS、GCP、阿里云等）；
自动创建云平台提供的负载均衡器；
提供固定的公网 IP 和负载均衡能力；

示例 YAML：

kind: Service
apiVersion: v1
metadata:
  name: my-service-lb
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

云平台会自动分配一个公网 IP，并创建对应的负载均衡器资源。

3. Ingress

特点：

提供基于 HTTP/HTTPS 的路由控制；
支持多域名、路径转发；
通常配合 Ingress Controller（如 Nginx Ingress、Traefik）使用；
是对外暴露 Web 服务的推荐方式；

示例 YAML（Ingress）：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - http:
        paths:
          - path: /app
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

必须确保集群中已部署 Ingress Controller（如 nginx-ingress-controller）。

4. ExternalName

特点：

将 Service 映射到外部 DNS 名称；
不进行代理或转发，仅做 DNS 解析；
用于引用集群外部的服务；

示例 YAML：

kind: Service
apiVersion: v1
metadata:
  name: external-service
spec:
  type: ExternalName
  externalName: api.example.com
  ports:
    - port: 80

该方式不会创建 Endpoints 或 Proxy 规则，仅作为 DNS 别名使用。

8. Ingress是什么？有哪些功能，常用的Ingress都有哪些

在 Kubernetes 中，Ingress 是一种用于管理外部访问的 API 对象，主要用于将集群内部的多个服务（Service）通过 HTTP/HTTPS 协议暴露给外部网络。它是对外提供 Web 服务的标准方式，具有路径路由、域名路由、SSL 终止等功能。

一、Ingress 的定义

Ingress 是一组规则的集合，用于控制从集群外部到 Service 的 HTTP 路由。它本身不提供路由功能，需要依赖 Ingress Controller（如 Nginx、Traefik、HAProxy 等）来实现具体的流量转发逻辑。

注意：Ingress 只负责 L7（HTTP/HTTPS）层路由，不能处理 TCP/UDP 流量。

二、Ingress 的核心功能

功能	描述
基于路径的路由	根据请求路径将流量转发到不同后端服务（如 `/app1` → service-a, `/app2` → service-b）
基于主机名的虚拟主机	同一个 IP 支持多个域名访问（如 `app1.example.com` 和 `app2.example.com`）
SSL/TLS 加密支持	提供 HTTPS 访问能力，支持证书配置（Secret）
负载均衡	将请求分发到多个 Pod 实例
路径重写与注解扩展	支持 URL 重写、限流、认证等高级功能（通过 Ingress 注解实现）

三、Ingress 控制器（Controller）

Ingress 控制器是实际处理流量的组件，常见的有：

控制器	特点	使用场景
Nginx Ingress Controller	基于 Nginx 实现，社区广泛使用	通用 Web 服务、API 网关
Traefik	支持自动发现服务，集成 Let's Encrypt 自动签发证书	微服务架构、快速部署
HAProxy Ingress	高性能 TCP/HTTP 负载均衡器	大规模高并发场景
Istio Gateway	基于 Istio 的网关机制，支持 mTLS、流量控制	服务网格环境
阿里云 ALB Ingress	云厂商提供的托管 Ingress，集成 SLB	生产环境云平台部署
Contour + Envoy	基于 Envoy 实现，适用于高性能边缘网关	高性能边缘服务、API 网关

四、常用 Ingress 类型（Class）

类型	描述
nginx	默认类型，使用 Nginx Ingress Controller
traefik	使用 Traefik 作为控制器
alb	使用阿里云应用型负载均衡器（Application Load Balancer）
istio	使用 Istio 的 Gateway 资源实现路由
contour	使用 Contour + Envoy 架构

你可以通过 ingressClassName 字段指定使用的 Ingress 类型：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  ingressClassName: nginx

9. 为什么本地创建的k8s无法使用LoadBalancer，如何解决

在本地 Kubernetes 集群（如 Minikube、Kind、K3s 或 Docker Desktop）中，无法使用 LoadBalancer 类型的 Service 是一个常见问题。这是因为：

🚫 一、为什么本地集群不能使用 LoadBalancer？

LoadBalancer 的工作原理：

LoadBalancer 是 Kubernetes 中的一种 Service 类型；
它依赖于云平台（如 AWS、GCP、阿里云等）自动为其分配公网 IP 和负载均衡器；
在云环境中，Kubernetes 控制器会调用云厂商 API 自动创建 ELB/NLB；

本地环境的问题：

本地集群没有对接任何云厂商；
没有内置的负载均衡控制器；
因此 LoadBalancer 类型的服务会一直处于 Pending 状态，无法获得外部 IP。

二、验证方法

你可以运行以下命令查看服务状态：

kubectl get svc <service-name>

10. 搭建MetalLB ，为service分配一个本地IP

在本地 Kubernetes 集群中，由于没有云厂商提供的负载均衡器支持，Service 的 LoadBalancer 类型通常会处于 <pending> 状态。为了解决这个问题，我们可以使用 MetalLB 来为集群提供网络负载均衡功能，并为每个 LoadBalancer 类型的 Service 分配一个本地 IP。

一、安装 MetalLB（Layer2 模式）

前提条件：

已部署本地 Kubernetes 集群（如 Kind、Minikube、K3s 或 Docker Desktop）
集群节点具备二层网络可达性
可用的 IP 地址池用于分配

步骤 1：部署 MetalLB 控制器

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.3/config/manifests/metallb-native.yaml

步骤 2：创建配置文件 `metallb-config.yaml`

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: default-pool
spec:
  addresses:
    - 192.168.1.200-192.168.1.250

---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertisement
spec:
  ipAddressPools:
    - default-pool

步骤 3：应用配置

kubectl apply -f metallb-config.yaml

此时 MetalLB 已部署完成，并准备好为 LoadBalancer 类型的 Service 分配 IP。

二、为 Service 分配本地 IP

示例：定义 LoadBalancer 类型 Service

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

应用该 YAML 后，你将看到服务获得来自指定 IP 池中的地址：

kubectl get svc nginx-service

11. helm是什么，主要为了解决什么问题

Helm 是什么？

Helm 是 Kubernetes 的一个开源包管理工具，被誉为“Kubernetes 的 apt/yum”，用于简化在 Kubernetes 上部署和管理应用程序的过程。

它通过 Chart（一种打包格式）来定义、安装和升级复杂的 Kubernetes 应用程序。Chart 是一组预先配置的 Kubernetes 资源模板，支持参数化配置，使得同一个应用可以在不同环境中灵活部署。

主要为了解决哪些问题？

问题	Helm 如何解决
应用部署复杂性高	提供预定义模板（Chart），一键部署多个资源（Deployment、Service、ConfigMap 等）
版本管理和回滚困难	支持版本控制与升级历史记录，可轻松回滚到任意版本
配置参数不统一	支持 `values.yaml` 配置文件，实现环境差异化配置（开发/测试/生产）
依赖管理复杂	支持 Chart 依赖（subcharts），自动处理组件依赖关系
重复部署效率低	声明式部署，避免手动编写大量 YAML 文件
调试与维护困难	提供 lint、template、upgrade、rollback 等调试与维护命令

12. Helm Chart 是什么？一个典型的 Chart 目录结构包含哪些主要文件或目录？它们各自的作用是什么

Helm Chart 是什么？

Helm Chart 是 Helm 的应用程序打包格式，它是一组预先定义的 Kubernetes 资源模板和配置文件，用于描述一个应用在 Kubernetes 中所需的全部资源（如 Deployment、Service、ConfigMap 等）。Chart 支持参数化配置，使得同一个应用可以在不同环境中灵活部署。

一个典型的 Helm Chart 目录结构如下：

my-chart/
├── Chart.yaml              # Chart 元数据信息（名称、版本、描述等）
├── values.yaml             # 默认配置值，用于模板渲染
├── charts/                 # 子 Chart（依赖项）
├── templates/              # Kubernetes YAML 模板文件
│   ├── deployment.yaml     # 应用部署模板
│   ├── service.yaml        # 服务暴露模板
│   ├── ingress.yaml        # Ingress 配置模板（可选）
│   ├── configmap.yaml      # 配置文件模板（可选）
│   └── _helpers.tpl        # 可复用的模板函数（如命名、标签生成）
└── README.md               # 文档说明（可选）

13. 当我执行 kubectl apply -f <file>.yaml 后，Pod 的整个生命周期是如何管理的？具体发生了哪些步骤，每个步骤中要描述，谁（xx组件）做了哪些事情（操作）。

在 Kubernetes 中，当你执行 kubectl apply -f <file>.yaml 命令后，Kubernetes 会根据你提供的 YAML 文件创建或更新资源对象，并按照声明式管理方式来控制这些资源的最终状态。这个过程涉及多个核心组件协同工作，确保 Pod 按照预期启动、运行并保持健康。

一、整个流程概述（从 `kubectl apply` 到 Pod Running）

阶段	描述
1. 客户端提交配置	用户使用 `kubectl apply` 提交资源配置到 API Server
2. API Server 接收请求	校验资源合法性，写入 etcd
3. 控制器监听变更	Deployment/ReplicaSet 控制器检测到配置变化，触发副本同步
4. 调度器分配节点	Scheduler 为 Pod 分配合适的 Node
5. Kubelet 创建容器	Node 上的 kubelet 创建 Pod 和容器
6. 状态同步与健康检查	kubelet 上报 Pod 状态，探针监控容器健康

二、详细步骤及各组件职责

步骤 1：客户端提交配置（kubectl）

谁：用户
做了什么：
- 使用 kubectl apply 将 YAML 文件发送到 Kubernetes API Server；
- 该命令是声明式的，表示“期望状态”，而非直接操作集群；

kubectl apply -f my-deployment.yaml

步骤 2：API Server 接收请求

谁：kube-apiserver
做了什么：
- 校验 YAML 文件格式是否合法；
- 根据 RBAC 权限判断用户是否有权限操作资源；
- 如果合法，将资源信息写入 etcd 存储；
- 向客户端返回响应，确认资源已接收；

示例日志片段（伪代码）：

[INFO] Received request to create Deployment "my-app"
[INFO] Validating against OpenAPI schema
[INFO] Authorization check passed for user "admin"
[INFO] Writing object to etcd under key "/registry/deployments/default/my-app"

步骤 3：控制器监听变更（Deployment Controller）

谁：kube-controller-manager（Deployment Controller）
做了什么：
- 监听 etcd 中 Deployment 的变化；
- 检查当前 ReplicaSet 是否匹配目标副本数；
- 若不匹配，创建新的 ReplicaSet 并设置期望副本数；

示例行为：

[INFO] Detected new deployment "my-app"
[INFO] Creating new ReplicaSet "my-app-789dfc6789"
[INFO] Setting replicas=3 in ReplicaSet

步骤 4：调度器分配节点（Scheduler）

谁：kube-scheduler
做了什么：
- 监听到新 Pod 创建事件；
- 根据资源需求、节点标签、亲和性等条件选择一个合适节点；
- 将 Pod 绑定到选定的节点上；

示例行为：

[INFO] Scheduling Pod "my-app-789dfc6789-abcde"
[INFO] Filtering nodes by resource availability...
[INFO] Selected node "worker-node-01" as target
[INFO] Binding Pod to worker-node-01

步骤 5：Kubelet 创建容器（Kubelet）

谁：kubelet（运行在目标节点上）
做了什么：
- 收到 API Server 下发的 Pod 创建指令；
- 与容器运行时（如 containerd、docker）交互，拉取镜像并创建容器；
- 初始化 Pause 容器（Pod 的基础网络命名空间）；
- 启动 InitContainer（如有）；
- 启动主容器；
- 执行 postStart 生命周期钩子（如有）；

示例行为：

[INFO] Starting pod "my-app-789dfc6789-abcde"
[INFO] Pulling image "nginx:latest" from registry
[INFO] Creating pause container (infrastructure container)
[INFO] Running init containers if defined
[INFO] Starting main container "nginx"
[INFO] Executing postStart hook command

步骤 6：状态同步与健康检查（Kubelet + Controller）

谁：kubelet、kube-controller-manager、kube-proxy
做了什么：

A. kubelet 上报 Pod 状态

更新 Pod 状态为 Running；
上报容器 IP 地址；
检测容器健康状态（liveness/readiness probe）；

B. Service Endpoints 更新

kube-proxy 检测到 Pod 变化；
自动更新对应 Service 的 Endpoints；
更新 iptables/IPVS 规则实现负载均衡；

C. Readiness Probe 成功

Pod 进入 Ready 状态；
开始接收流量；

示例行为：

[INFO] Container "nginx" is running
[INFO] Readiness probe succeeded, marking Pod as Ready
[INFO] Updating endpoints for service "my-service"
[INFO] Adding endpoint "10.244.1.10:80" to service

三、完整流程图解（文字版）

kubectl apply -f deploy.yaml
        ↓
   kube-apiserver（验证 & 写入 etcd）
        ↓
Deployment Controller（创建 ReplicaSet）
        ↓
  ReplicaSet Controller（设定副本数）
        ↓
     Scheduler（选择 Node）
        ↓
    kubelet（创建 Pod & 容器）
        ↓
         → Pause 容器创建
         → InitContainer 启动（可选）
         → 主容器启动
         → postStart 钩子执行
        ↓
      livenessProbe / readinessProbe
        ↓
 Pod Ready，加入 Service Endpoints
        ↓
开始接收来自 Service 的流量

1. 什么是Headless服务？它与普通Service有什么区别？有什么使用场景

Headless 服务的定义

Headless 服务与普通 Service 的区别

使用场景

2. 如何配置Horizontal Pod Autoscaler（HPA）进行自动扩容？它基于哪些指标来决定扩容

如何配置 HPA 进行自动扩容？

前提条件

示例配置步骤

1. 创建一个 Deployment（假设你还没有）

2. 创建 HPA（基于 CPU 使用率）

HPA 支持的扩缩容指标类型

3. Kubernetes中的集群高可用方案有哪些？如何保证K8s API Server的高可用

Kubernetes 集群高可用方案概述

控制平面组件高可用

如何保证 Kubernetes API Server 的高可用？

方法一：多节点部署 + 负载均衡

1. 多个 API Server 实例部署

2. 前端负载均衡器配置

3. TLS 证书配置

方法二：使用云平台托管控制平面（Managed Control Plane）

方法三：使用 Ingress 对外暴露 API Server（可选）

4. 如何根据Pod的状态信息（如CrashLoopBackOff）来进行故障排查

一、查看 Pod 状态和事件信息

查看 Pod 状态

查看 Pod 详细信息

二、CrashLoopBackOff 含义及常见原因

CrashLoopBackOff 表示什么？

常见原因包括：

三、具体排查步骤（推荐顺序）

1. 查看容器日志（包含上一次崩溃的日志）

2. 查看 Pod 事件日志（用于定位根本原因）

3. 检查资源限制与请求是否合理

5. 检查 InitContainer 是否失败

5. 如何为K8s中的Pod设置生命周期钩子（Lifecycle Hooks）？有哪些应用场景

一、生命周期钩子类型

二、配置方式

示例 1：使用 exec 命令设置 postStart 和 preStop

6. 如何在K8s集群中进行备份和恢复？常用的备份工具有哪些

一、K8s 备份的核心内容

二、ETCD 备份与恢复（核心）

ETCD 快照备份命令：

恢复 ETCD 快照：

三、常用 Kubernetes 备份工具

7. 集群中的服务有哪几种方式暴露，提供给集群外使用

一、Kubernetes 中服务暴露的常见方式

二、详细说明与配置示例

1. NodePort

特点：

示例 YAML：

特点：

示例 YAML：

3. Ingress

特点：

示例 YAML（Ingress）：

4. ExternalName

特点：

示例 YAML：

8. Ingress是什么？有哪些功能，常用的Ingress都有哪些

一、Ingress 的定义

二、Ingress 的核心功能

三、Ingress 控制器（Controller）

四、常用 Ingress 类型（Class）

9. 为什么本地创建的k8s无法使用LoadBalancer，如何解决

🚫 一、为什么本地集群不能使用 LoadBalancer？

LoadBalancer 的工作原理：

本地环境的问题：

二、验证方法

10. 搭建MetalLB ，为service分配一个本地IP

一、安装 MetalLB（Layer2 模式）

前提条件：

步骤 1：部署 MetalLB 控制器

步骤 2：创建配置文件 metallb-config.yaml

步骤 3：应用配置

二、为 Service 分配本地 IP

示例：定义 LoadBalancer 类型 Service

11. helm是什么，主要为了解决什么问题

Helm 是什么？

主要为了解决哪些问题？

12. Helm Chart 是什么？一个典型的 Chart 目录结构包含哪些主要文件或目录？它们各自的作用是什么

Helm Chart 是什么？

步骤 2：创建配置文件 `metallb-config.yaml`

一、整个流程概述（从 `kubectl apply` 到 Pod Running）