k8s运维面试总结(持续更新)

一、你使用的promethues监控pod的哪些指标？
CPU使用率
内存使用率
网络吞吐量
磁盘I/O
资源限制和配额：Prometheus可以监控Pod的资源请求和限制，确保它们符合预设的配额，防止资源过度使用。具体指标如container_spec_cpu_quota用于表示容器的CPU配额。
健康检查：存活探针（Liveness Probe）和就绪探针（Readiness Probe）的状态对于评估Pod的健康状况至关重要。Prometheus通过监控这些探针的成功或失败状态来了解Pod的健康情况。

重启次数：
节点指标：Prometheus通过kube-state-metrics监控Kubernetes资源对象如Pod、Deployment、Service等的状态
监控工具：Prometheus通过Exporter如node-exporter和cAdvisor来采集节点和容器的指标数据。这些Exporter将监控数据转换为Prometheus可以理解的格式。

二、如果想对Pod本身调大内存参数 有几种方法？
(1) 直接修改Pod定义文件（推荐）
编辑 Pod 的 YAML 文件：
在 Pod 的定义文件中，找到 resources 字段，调整 limits.memory（内存上限）和 requests.memory（内存请求）的值

(2)使用kubectl edit 命令（快速调整）
kubectl edit pod

三、Kubernetes 中扩容节点的步骤是什么？
1.准备工作
1.1 硬件/虚拟机准备
配置要求：确保新节点满足 Kubernetes 的最低要求（如 CPU、内存、磁盘）。
网络配置：
与主节点网络互通。
关闭防火墙或开放必要端口（如 6443、2379-2380、10250 等）。

1.2 操作系统配置
安装依赖：

# Ubuntu 示例
sudo apt-get update
sudo apt-get install -y docker.io kubelet kubeadm kubectl

配置容器运行时：如 Docker、containerd（需与集群一致）。

关闭 swap：
bash
sudo swapoff -a  # 临时关闭
# 永久关闭需编辑 将其注释 /etc/fstab

2.加入集群
2.1 从主节点获取加入命令
生成 token（若默认 token 过期）：

kubeadm token create --print-join-command

获取命令：

# 输出示例（替换为实际值）
kubeadm join <主节点IP:端口> --token <token> --discovery-token-ca-cert-hash <hash>

2.2 在新节点执行加入命令
执行命令：

sudo kubeadm join 192.168.1.100:6443 --token abcdef.0123456789abcdef --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

验证节点状态
查看节点列表：

kubectl get nodes

Ready 状态：新节点状态应为 Ready（可能需要几分钟初始化）。

四、k8s的组件有哪些？作用是什么？

控制平面组件：
kube-apiserver：作为Kubernetes集群的核心，负责处理API请求，是集群内外通信的枢纽。
kube-controller-manager：运行控制器进程，如节点控制器、副本控制器等，确保集群状态符合预期。
kube-scheduler：负责将Pod调度到合适的节点上运行，考虑资源需求和节点状态。
etcd：作为键值存储系统，保存集群的配置和状态数据。

节点组件：
kubelet：运行在每个节点上，负责Pod的生命周期管理，与kube-apiserver通信。
kube-proxy：维护节点上的网络规则，实现Pod的通信和网络服务。
容器运行时（如Docker、containerd）：负责容器的运行和管理。

五、案例分析
(1)收到研发反馈，在pod（容器）上查不到redis数据， 但是业务正常（有历史数据）。 （提示：1、redis刚开始使用deployment部署，后续有过调整变动； 2、从service方向多考虑)
请给出分析，结合所掌握的相关知识和命令 判断 可能的原因

1.Service与Pod标签不匹配（最常见原因）
现象：Deployment调整后，Pod标签可能发生变化，但Service的Selector未同步更新，导致Service无法关联到正确Pod。

2.Service DNS解析失败
现象：Pod通过Service名称访问Redis时，DNS解析异常。

3.Endpoints未更新
现象：Service关联的Endpoints未更新，仍指向旧Pod。

4.网络策略拦截
现象：NetworkPolicy阻止了Pod与Redis Service的通信。

(2) 在k8s中部署mysqld ， mysqld 容器启动始终失败，提示数据目录非空. 请给出解决办法 (提示： mount 新创建的pv也报相同错误)

解决方案
1.确保PV/PVC目录绝对干净、清空数据目录、重新部署MySQL
2. 修复目录权限问题，可能PV目录权限非mysql:mysql（如root:root），导致MySQL无法初始化
3 避免子目录挂载冲突：PV挂载到子目录（如/data/mysql），但该子目录已存在文件。
4 使用初始化容器（Init Container）现象：动态环境或CI/CD流程中需自动化清理

六、k8s的日常工作内容
集群管理
监控集群状态，确保节点、Pod和网络等组件正常运行。
管理集群资源，如CPU、内存和存储，确保资源合理分配和利用。
执行集群升级和维护，包括节点软件更新和安全补丁应用。

应用部署
使用Kubernetes部署和管理容器化应用程序，包括滚动更新和回滚。
配置和管理应用程序的服务、副本集和部署策略

监控与日志
设置和监控性能指标：使用Prometheus和Grafana等工具监控集群和应用程序的性能
收集和分析日志：使用Fluentd和Elasticsearch等工具收集和分析日志

故障排查
快速响应和解决故障：使用kubectl describe和kubectl logs等命令排查故障。

安全管理
管理安全策略：使用RBAC和网络策略等工具管理集群和应用程序的安全
定期审计和检查安全性：定期进行安全审计和检查，确保符合安全标准和最佳实践

持续集成与交付
实现CI/CD流程：使用Jenkins、GitLab CI等工具实现持续集成和持续交付。

七、对k8s集群做过哪些安全策略
用户访问api策略
Secret管理加密敏感数据：
etcd策略

如：TLS 加密 
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \-config=ca-config.json -profile=etcd etcd-csr.json | cfssljson -bare etcdAPI Server 连接 etcd 时强制使用证书：
# api-server 启动参数
--etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
--etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
--etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key

网络隔离：
通过防火墙限制 etcd 端口（默认 2379-2380）仅允许 API Server 和 etcd 节点访问。

备份与加密
定期备份与加密

api审计
启用审计日志：配置审计策略、启动 API Server 时加载策略

八、空网关和istio的Gateway区别？
1.空网关（Empty Gateway）
定义：指未配置任何路由规则或服务的 Ingress 控制器（如 Nginx Ingress Controller），通常作为占位符存在。
特点：
无实际流量路由功能。
可能返回默认的 404 页面或空响应。
典型场景：
预留 Ingress 资源名称，后续再配置。
测试 Ingress 控制器的网络连通性。
开发环境中临时用于服务调试。

2.Istio Gateway
定义：Istio 服务网格中用于管理入站（Ingress）和出站（Egress）流量的核心组件。
特点：
通过 Gateway 资源定义流量入口（如端口、协议）。
结合 VirtualService 配置流量路由规则（如路径匹配、流量拆分）。
支持高级流量管理功能（熔断、负载均衡、TLS 终止）。
典型场景：
生产环境中管理微服务间的流量。
实现金丝雀发布、A/B 测试等策略。
统一处理南北向流量（如外部用户访问集群服务）。

核心区别
空网关：简单的 Ingress 占位符、技术实现：基于 Ingress Controller 的空配置、 流量处理：无实际流量路由 使用场景：开发、测试

Istio Gateway：Istio 服务网格的流量入口控制器、技术实现：Istio 控制平面 + Envoy Sidecar 流量处理：支持复杂流量规则（路由、拆分等） 使用场景：生产级流量管理、微服务治理

如何选择？
用空网关：仅需简单的 Ingress 占位，或快速验证网络基础功能。
用 Istio Gateway：需实现生产级流量管理（如金丝雀发布、熔断）、或集成 Istio 的安全、监控功能。

总结
空网关是轻量级的网络入口占位工具，而 Istio Gateway 是 Istio 服务网格中用于管理复杂流量的核心组件。选择取决于具体需求：简单场景用空网关，生产级流量治理用 Istio Gateway。

九、如果流水线不能自动发布了，怎么处理？
1.获取构建产物
从流水线获取：
如果流水线已完成构建阶段，从流水线的工作目录或存储库中获取构建产物（如 Docker 镜像、JAR/WAR 包、静态文件）。

手动构建：
如果流水线未构建成功，在本地或构建服务器上手动执行构建命令：
示例：Maven 构建 Java 项目
mvn clean package

示例：npm 构建前端项目
npm install
npm build

2.部署应用
手动操作 Kubernetes：
使用 kubectl 手动部署

更新镜像版本
kubectl set image deployment/my-app my-app=registry.example.com/my-app:1.2.3

或直接应用 YAML 文件
kubectl apply -f deployment.yaml

验证部署
检查应用状态：
确认应用 Pod/容器已启动且无报错（如 kubectl get pods）。
检查服务是否正常运行（如 curl http://app-service）。
检查日志是否有异常（如 kubectl logs ）。

十、k8s中的控制器有哪些？作用是什么？

• Deployment 无状态应用管理、滚动更新、自动扩缩容 Web 服务、API 网关等无状态服务

• StatefulSet 有状态应用管理、稳定网络标识、顺序部署 数据库集群、消息队列等有状态服务 DaemonSet 每节点部署一个

• Pod（或指定节点） 日志收集、监控代理等节点级系统服务 Job 执行一次性任务，支持并行处理 批处理作业（如数据清洗）

• CronJob 按 cron 表达式定时执行任务 定时任务（如备份、报告生成）

• ReplicaSet 确保指定数量的 Pod副本运行（通常作为 Deployment 的后端 直接使用较少，多用于底层控制逻辑

十二、在Kubernetes中，除了通过 Ingress Controller 和 Istio 实现流量负载均衡外，应用层面负载均衡怎么实现？
Ribbon、loalbalance
原理：
在应用代码中显式实现负载均衡逻辑（如选择后端服务实例）。
实现方式：
自定义负载均衡算法：
如轮询（Round Robin）、加权轮询（Weighted Round Robin）、随机（Random）、最少连接（Least Connections）。
示例代码（伪代码）：

示例：轮询算法

def select_instance(instances):current_index = (current_index + 1) % len(instances)return instances[current_index]

十三、怎么将包含DDL（数据定义语言）和DML（数据操作语言）语句的应用打包成Docker镜像并部署到其他服务器执行？
1.准备SQL脚本
将DDL/DML语句保存为.sql文件（如init.sql），例如：
– init.sql
CREATE TABLE users (id INT PRIMARY KEY, name VARCHAR(50));
INSERT INTO users VALUES (1, ‘Alice’), (2, ‘Bob’);

2.编写Dockerfile
创建一个Dockerfile，使用包含数据库客户端的基础镜像（如MySQL客户端）：
使用官方MySQL客户端镜像
FROM mysql:8.0
将SQL脚本复制到镜像中
COPY init.sql /docker-entrypoint-initdb.d/
设置容器启动命令（按需调整）
CMD [“mysql”, “-h”, “your-db-host”, “-u”, “user”, “-p密码”, “数据库名”, “<”, “/docker-entrypoint-initdb.d/init.sql”]

docker build -t my-sql-app:1.0

.十四、tcp的握手和挥手是怎样的？

一、TCP三次握手（建立连接）
第一次握手
客户端发送 SYN（同步）报文，附带随机初始序列号 seq=x。
目的：客户端表明自己已准备好通信，请求建立连接。
第二次握手
服务器响应 SYN-ACK（同步-确认）报文，包含：
对客户端 SYN 的确认号 ack=x+1。
自己的初始序列号 seq=y。
目的：服务器确认客户端请求，并告知自己已准备好。
第三次握手
客户端发送 ACK（确认）报文，确认号 ack=y+1。
目的：客户端确认服务器已就绪，连接正式建立。
握手核心逻辑：双方通过交换序列号确认彼此收发能力，防止历史连接干扰。

二、TCP四次挥手（关闭连接）
第一次挥手
客户端发送 FIN（结束）报文，序列号 seq=u。
目的：客户端声明数据已发送完毕，请求关闭连接。
第二次挥手
服务器响应 ACK 报文，确认号 ack=u+1。
目的：服务器确认客户端的关闭请求，但可能还有数据未发送。
第三次挥手
服务器发送 FIN 报文，序列号 seq=v。
目的：服务器声明数据已全部发送，请求关闭连接。
第四次挥手
客户端响应 ACK 报文，确认号 ack=v+1。
目的：客户端确认服务器的关闭请求，连接完全终止。
挥手核心逻辑：确保双向数据均传输完毕，避免数据丢失。

十五、k8s生产环境怎么处理资源限制的问题？

1.限制命名空间（Namespace）级别的总资源使用量。
配置示例：

yaml
apiVersion: v1
kind: ResourceQuota
metadata:name: prod-quotanamespace: production
spec:hard:requests.cpu: "20"       # 总 CPU 请求不超过 20 核requests.memory: "64Gi"  # 总内存请求不超过 64GBlimits.cpu: "40"         # 总 CPU 限制不超过 40 核limits.memory: "128Gi"   # 总内存限制不超过 128GB

2.设置限制范围（Limit Ranges）
作用：为命名空间中的 Pod 设置默认资源请求/限制。
配置示例：

apiVersion: v1
kind: LimitRange
metadata:name: default-limitsnamespace: production
spec:limits:- default:cpu: "1"memory: "512Mi"defaultRequest:cpu: "0.5"memory: "256Mi"type: Container

3.动态调整资源限制
手动调整：
kubectl edit deployment/ -n
修改 containers 部分的 resources.limits 和 resources.requests

自动化调整：
Vertical Pod Autoscaler (VPA)：自动推荐并调整 Pod 资源限制。
Horizontal Pod Autoscaler (HPA)：根据资源使用率自动扩缩容副本数

4.存储资源限制
使用 PersistentVolumeClaims (PVC)：

kind: PersistentVolumeClaim
apiVersion: v1
metadata:name: mysql-storage
spec:accessModes: [ "ReadWriteOnce" ]resources:requests:storage: 100Gi  # 最小存储需求limits:storage: 200Gi  # 最大存储限制（可选）

5.网络带宽限制（实验性）
使用 Linux TC 规则：
#在节点上通过 tc 命令限制带宽

tc qdisc add dev eth0 root handle 1: htb default 12
tc class add dev eth0 parent 1: classid 1:1 htb rate 1000Mbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 500Mbps  # 限制到 500Mbps 

十六、pod CrashLoopBackOff怎么处理？
1.查看Pod状态：
使用kubectl get pods命令检查Pod的状态，确认其是否处于CrashLoopBackOff状态。

2.获取Pod日志：
通过kubectl logs 命令查看Pod的日志，寻找错误信息或异常堆栈，这有助于确定崩溃的原因。

3.描述Pod详情：
使用kubectl describe pod 命令获取Pod的详细信息，包括事件记录，这可能提供关于崩溃的更多线索。

4.检查Pod配置：
确认Pod的配置文件（如YAML）是否正确，特别是资源限制、环境变量和卷挂载等部分

5.检查资源使用情况：
使用kubectl top pod 命令查看Pod的资源使用情况，确认是否由于资源不足导致崩溃

6.回滚或重新部署：
如果最近对Pod进行了更改，考虑回滚到之前的稳定版本。
尝试重新部署Pod，有时这可以解决临时性的问题

7.监控与告警
配置 Prometheus + Grafana 监控 Pod 资源使用。
设置 Alertmanager 告警规则（如连续崩溃超过 3 次触发告警）。

8.若仍无法解决，结合日志和事件信息，联系应用开发者。

十七、calico和fannel的区别

特性	Calico	Flannel
网络模型	三层路由（BGP）	叠加网络（VxLAN/host-gw）
网络策略	原生支持（细粒度	需依赖第三方工具
性能	高（无隧道开销）	（无隧道开销）
复杂度	较高（需配置 BGP）	低（简单易用）
适用场景	大规模	中小型、快速部署场景

十八、pod service endpoint三者的关系？
Pod 是服务实例
Pod 是实际运行服务的容器组（如 Nginx、API 服务）。

Service 是抽象入口
Service 通过标签选择器（selector）匹配一组 Pod（如 app: nginx）。
用户或外部系统通过 Service 的 IP/DNS 访问服务，无需关心具体 Pod。

Endpoint 是动态映射
Kubernetes 自动为每个 Service 创建一个同名的 Endpoint 资源。
Endpoint 列表中的 IP 和端口指向当前健康的 Pod。
若 Pod 崩溃或删除，Endpoint 会自动移除其条目，Service 将流量路由到其他可用 Pod。

示例流程
部署一个 Nginx Pod（标签 app: nginx）。
创建 Service，通过 selector: app=nginx 关联到该 Pod。
Kubernetes 自动创建 Endpoint，记录 Pod 的 IP 和端口（如 10.244.0.5:80）。
其他 Pod 或外部请求通过 Service 的 IP/DNS 访问 Nginx，流量被路由到 Endpoint 中记录的 Pod。

十九、pod 容器 node的关系？
三者关系
Pod：定义容器的运行环境和调度单元。
容器：实际执行业务逻辑，依赖 Pod 的网络和存储。
Node：提供计算资源，运行 Pod 和容器。

二十、istio都有用到哪些功能？

1.流量管理

• 金丝雀发布：逐步将流量从旧版本切换到新版本。
• A/B 测试：将流量路由到不同版本的服务。

熔断机制：自动屏蔽故障服务，防止级联故障。

2.安全通信

• mTLS：服务间自动加密通信（双向 TLS）。
• RBAC：基于角色的访问控制（如限制服务调用权限）。
  可根据自己经验回答

二十一、Helm目录结构及本地部署chart主要步骤？
Helm目录结构：

• Chart.yaml：定义Chart的元数据，如名称、版本和依赖关系。

• values.yaml：包含Chart的默认配置值，用户可以在安装时覆盖这些值

• templates/：存放Kubernetes资源模板，如Deployment、Service等。

• templates/NOTES.txt：安装后显示的使用说明。

• _helpers.tpl：存放可重用的模板片段。

• charts/：存放依赖的Chart。

mychart/
├── Chart.yaml          # Chart 的元数据（名称、版本、依赖等）
├── values.yaml         # 默认配置值，可覆盖
├── charts/             # 依赖的子 Chart（可手动或动态链接）
├── templates/          # Kubernetes 资源模板（YAML 文件）
│   ├── deployment.yaml # 定义 Deployment
│   ├── service.yaml    # 定义 Service
│   ├── _helpers.tpl    # 可复用的模板片段
│   └── NOTES.txt       # 安装后的使用说明
└── .helmignore         # 打包时忽略的文件列表

1.初始化 Helm 客户端
下载并安装 Helm：

wget https://get.helm.sh/helm-v3.12.3-linux-amd64.tar.gz
tar -zxvf helm-v3.12.3-linux-amd64.tar.gz
mv linux-amd64/helm /usr/local/bin/helm

验证安装：

helm version

2.创建命名空间（可选）
在 Kubernetes 中创建命名空间（如 my-namespace）：

kubectl create namespace my-namespace

3.手动打包 Chart（如果未打包）
如果 Chart 是目录形式，需先打包成 .tgz 文件：
helm package mychart
生成文件：mychart-0.1.0.tgz

4.安装 Chart
使用 helm install 命令安装：

helm install my-release mychart-0.1.0.tgz -n my-namespace

参数说明：
my-release：自定义的 Release 名称（唯一标识）。
mychart-0.1.0.tgz：Chart 包路径。
-n my-namespace：指定命名空间。

5.验证部署状态
查看已安装的 Release：

helm list -n my-namespace

检查 Kubernetes 资源状态：

kubectl get all -n my-namespace

二十二、pod怎么访问apiserver的？
在命名空间的kube-system命名空间里，有一个名称为kube-api-master的pod，这个pod就是运行着kube-api-server进程，它绑定了master主机的ip地址和6443端口，但是在default命名空间下，存在一个叫kubernetes的服务，该服务对外暴露端口为443，目标端口6443，这个服务的ip地址是ClusterIP地址池里面的第一个地址，同时这个服务的yaml定义里面并没有指定标签选择器，也就是说这个kubernetes服务所对应的endpoint是手动创建的，该endpoint也是名称叫做kubernetes，该endpoint的yaml定义里面代理到master节点的6443端口，也就是kube-api-server的ip和端口。这样一来，其他pod访问kube-api-server的整个流程就是：pod创建后嵌入了环境变量，pod获取到了kubernetes这个服务的ip和443端口，请求到kubernetes这个服务其实就是转发到了master节点上的6443端口的kube-api-server这个pod里面。

二十三、Ingress Controller 和service的联系？
在 Kubernetes 中，Ingress Controller 和 Service 是协同工作的组件，共同管理外部流量到集群内部服务的路由。以下是它们之间的联系和协作机制：

核心作用
Service：
定义一组 Pod 的逻辑抽象，通过标签选择器（selector）确定访问的 Pod 集合。
提供稳定的访问地址（如 ClusterIP、NodePort、LoadBalancer）。
例如：my-service 指向运行 my-app 的 Pod 集合。
Ingress Controller：
根据 Ingress 规则（Ingress 资源）将外部 HTTP/HTTPS 流量路由到集群内的 Service。
支持基于域名、路径、TLS 等规则进行流量分发。
例如：将 example.com/app 的流量路由到 my-service:80。

关联方式
Ingress 规则定义：
在 Ingress 资源中，通过 serviceName 和 servicePort 指定目标 Service 和端口：

yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: my-ingressannotations:nginx.ingress.kubernetes.io/rate-limit: "10r/s"
spec:rules:- host: example.comhttp:paths:- path: /apppathType: Prefixbackend:service:name: my-serviceport:number: 80

流量路径：
外部请求 → Ingress Controller → Service → Pod
Ingress Controller 监听外部流量（如通过 LoadBalancer 或 NodePort 暴露）。
根据 Ingress 规则匹配域名和路径，将请求转发到对应的 Service。
Service 再将请求分发到后端的 Pod。

二十四、coredns解析流程？
在 Kubernetes 集群中，CoreDNS 是默认的 DNS 服务器，负责将服务名称（如 my-service.my-namespace.svc.cluster.local）解析为对应的 ClusterIP 或 PodIP。以下是 CoreDNS 解析的详细机制：

CoreDNS 解析流程
Pod 发起 DNS 请求：
Pod 通过 /etc/resolv.conf 配置文件（由 kubelet 自动注入）使用 CoreDNS 作为 DNS 服务器。
例如，Pod 执行 nslookup my-service 时，请求会被发送到 CoreDNS。
CoreDNS 查询 Kubernetes API：
CoreDNS 向 Kubernetes API 服务器发送请求，查询服务 my-service 的信息。
API 服务器返回服务的 ClusterIP、端口、关联的 Pod 列表等信息。
CoreDNS 返回解析结果：
A 记录：将服务名称解析为 ClusterIP（如 my-service.my-namespace.svc.cluster.local → 10.96.0.1）。
SRV 记录（可选）：提供服务的端口信息（较少直接使用）。
Pod IP 列表：如果服务配置了选择器（selector），CoreDNS 还会返回匹配的 Pod IP 列表。

二十五、pod与pod建立不了联系，什么原因造成？
(1).检查网络策略（NetworkPolicy）
原因：如果集群启用了网络策略（如 Calico、Cilium），可能限制了 Pod 间的通信。
排查：
查看命名空间是否有默认拒绝所有流量的策略：
kubectl describe networkpolicy -n

检查目标 Pod 是否被策略允许

示例：允许来自特定 Pod 的流量

spec:podSelector:matchLabels:app: my-appingress:- from:- podSelector:matchLabels:app: allowed-app

(2).服务发现与 DNS 解析
原因：Pod 通过服务名称（如 my-svc.my-namespace.svc.cluster.local）通信，若 DNS 解析失败或 CoreDNS 异常，会导致无法发现服务
排查：
检查服务是否存在且 Endpoints 正确：
kubectl get svc -n
kubectl describe svc -n # 查看 Endpoints 列表

在 Pod 内测试 DNS 解析
kubectl exec -it -n – nslookup

检查 CoreDNS 日志：
kubectl logs -l k8s-app=kube-dns -n kube-system

(3).CNI 插件与网络配置
原因：Pod 网络由 CNI 插件（如 Calico、Flannel）管理，若插件异常或配置错误，会导致 Pod 无法通信。
排查：
检查 Pod 的 IP 地址分配
kubectl get pods -o wide -n # 查看 Pod IP

确认 Pod 之间可以路由
kubectl exec -it – ping
kubectl exec -it – telnet

检查 CNI 插件状态：
kubectl get pods -n kube-system -l app=calico-node # 以 Calico 为例

(4).防火墙与安全组
原因：节点或云平台的防火墙规则可能阻止 Pod 间的流量。
排查：
检查节点防火墙（如 iptables、ufw）

iptables -L -n -v # 查看规则

(5).Pod 状态与日志
原因：目标 Pod 可能未正常运行，或日志中有错误提示。
排查：
检查 Pod 状态
kubectl get pods -n

查看 Pod 日志
kubectl logs -n

二十六、kubectl怎么跟apiserver进行交互？
交互原理
API Server 作为核心枢纽：
所有对 Kubernetes 集群的操作（如创建 Pod、查询资源）都必须通过 API Server。
API Server 提供了 REST API 接口，kubectl 通过发送 HTTP 请求调用这些接口。
kubeconfig 文件：
kubectl 默认读取 ~/.kube/config 文件（可通过 KUBECONFIG 环境变量指定其他路径）。
该文件包含集群地址、认证信息（如证书、Token）、上下文（Cluster + User + Namespace）等。
通信流程：
kubectl 解析命令（如 kubectl get pods）。
根据 kubeconfig 中的配置，选择集群和上下文。
向 API Server 发送 HTTP 请求（如 GET /api/v1/namespaces/{namespace}/pods）。
API Server 验证请求身份和权限，处理请求并返回响应。
kubectl 解析响应并输出结果。

二十七、pod的异常有那些 怎么排查及解决？
一、常见 Pod 异常类型
Pending
原因：Pod 未被调度到节点，可能由于资源不足、节点选择器不匹配、污点（Taint）与容忍（Toleration）不匹配等。
排查：
kubectl describe pod 查看 Events 部分。
检查节点资源（CPU、内存）是否充足。
确认 nodeSelector、affinity 等配置是否匹配节点标签。
解决：
调整资源请求（resources.requests）。
修改节点选择器或添加容忍。
扩容集群或删除无用 Pod 释放资源。

CrashLoopBackOff
原因：容器反复崩溃重启，可能由于应用错误、配置问题（如环境变量、挂载卷）、资源限制（内存不足）等。
排查：
kubectl logs --previous 查看崩溃前的日志。
检查容器启动命令、环境变量、配置文件。
查看资源使用情况（kubectl top pod ）。
解决：
修复应用代码或配置错误。
调整资源限制（resources.limits）。
检查健康探针（Liveness Probe）配置是否合理。

Error
原因：Pod 启动失败，可能由于镜像拉取失败、权限问题、探针失败等。
排查：
kubectl describe pod 查看 Events 中的错误详情。
检查镜像名称和标签是否正确。
确认 ServiceAccount 权限是否足够。
解决：
修正镜像名称或标签。
检查私有镜像仓库的密钥（imagePullSecrets）。
调整探针配置或修复应用启动逻辑。

ImagePullBackOff
原因：镜像拉取失败，可能由于镜像不存在、权限不足、网络问题或镜像仓库配置错误。
排查：
kubectl describe pod 查看镜像拉取错误信息。
确认镜像仓库地址和标签是否正确。
检查 imagePullSecrets 是否配置。
解决：
修正镜像名称或标签。
配置正确的 imagePullSecrets。
检查网络策略是否允许访问镜像仓库

二十八、pod的就绪探针有几种,工作方式是什么？
当一个pod启动后，就会立即加入service的endpoint ip列表中，并开始接收到客户端的链接请求，假若此时pod中的容器的业务进程还没有初始化完毕，那么这些客户端链接请求就会失败，为了解决这个问题，kubernetes提供了就绪探针来解决这个问题的
在pod中的容器定义一个就绪探针，就绪探针周期性检查容器，如果就绪探针检查失败了，说明该pod还未准备就绪，不能接受客户端链接，则该pod将从endpoint列表中移除，被剔除了service就不会把请求分发给该pod，然后就绪探针继续检查，如果随后容器就绪，则再重新把pod加回endpoint列表。

HTTP 探针：向容器发送 HTTP 请求，根据响应状态码判断容器是否就绪。
命令探针：在容器内执行一个命令，根据命令的退出状态码（0 表示成功）判断容器是否就绪。
TCP 探针：尝试与容器指定端口建立 TCP 连接，根据连接是否成功判断容器是否就绪。

二十九、dockfile的常用命令
基础镜像指令：如FROM，用于指定基础镜像。
文件操作指令：如COPY和ADD，用于将文件复制到镜像中。
环境设置指令：如ENV、WORKDIR、EXPOSE，分别用于设置环境变量、工作目录和暴露端口。
构建过程指令：如RUN，用于执行命令。
启动指令：如CMD和ENTRYPOINT，用于定义容器启动时的行为。
其他实用指令：如VOLUME、USER、ARG等，用于挂载卷、指定用户、传递构建参数等。

三十、docke file copy 和add的区别？
COPY: 不支持解压压缩包，从 URL 下载文件
ADD: 支持本地解压 .tar、.tar.gz 等，不支持从 URL 下载文件

三十一、CMD和ENTRYPOINT的区别？
CMD 指令
功能：定义容器启动时默认执行的命令。
特点：
如果 Dockerfile 中有多个 CMD，只有最后一个生效。
容易被覆盖：执行 docker run 时，命令行参数会覆盖 CMD。
通常用于设置默认参数或启动脚本。
示例：
dockerfile
CMD [“python”, “app.py”]
运行 docker run my-image 会执行 python app.py。
运行 docker run my-image ls / 会覆盖 CMD，执行 ls /。

ENTRYPOINT 指令
功能：定义容器启动时的入口命令（主进程）。
特点：
不易被覆盖：除非使用 --entrypoint 参数强制覆盖。
可以与 CMD 结合使用：CMD 提供的参数会传递给 ENTRYPOINT。
通常用于设置容器的主要命令（如固定执行某个二进制文件）。
示例：
dockerfile
ENTRYPOINT [“python”]
CMD [“app.py”]
运行 docker run my-image 会执行 python app.py。
运行 docker run my-image script.py 会执行 python script.py（CMD 被覆盖，但 ENTRYPOINT 保留）。

核心区别总结
特性 CMD ENTRYPOINT
覆盖性 容易被覆盖 不易被覆盖
参数传递 独立命令 可与 CMD 参数结合
典型场景 默认启动命令或参数 固定入口命令（如主进程）

使用场景建议
用 CMD：当需要灵活覆盖默认命令时（如调试或临时任务）。
用 ENTRYPOINT：当需要固定容器的主进程（如必须运行某个服务）。
组合使用：ENTRYPOINT 定义主命令，CMD 定义默认参数。

三十二、用shell怎么删除某一个路径下10天前的日志？
find /path/to/logs -name “*.log” -mtime +10 -exec rm {} ;