k8s运维面试总结(持续更新)
文章目录
- 一、你使用的promethues监控pod的哪些指标？
- 二、如果想对Pod本身调大内存参数 有几种方法？
- 三、Kubernetes 中扩容节点的步骤是什么？
- 四、k8s的组件有哪些？作用是什么？
- 五、案例分析
- 六、k8s的日常工作内容
- 七、对k8s集群做过哪些安全策略
- 八、空网关和istio的Gateway区别？
- 九、如果流水线不能自动发布了，怎么处理？
- 十、k8s中的控制器有哪些？作用是什么？
- 十一、在Kubernetes中，除了通过 Ingress Controller 和 Istio 实现流量负载均衡外，应用层面负载均衡怎么实现？
- 十二、怎么将包含DDL（数据定义语言）和DML（数据操作语言）语句的应用打包成Docker镜像并部署到其他服务器执行？
- 十三、tcp的握手和挥手是怎样的？
- 十四、k8s生产环境怎么处理资源限制的问题？
- 十五、pod CrashLoopBackOff怎么处理？
- 十六、calico和fannel的区别
- 十七、pod service endpoint三者的关系？
- 十八、pod 容器 node的关系？
- 十九、istio都有用到哪些功能？
- 二十、Helm目录结构及本地部署chart主要步骤？
- 二十一、pod怎么访问apiserver的？
- 二十二、Ingress Controller 和service的联系？
- 二十三、coredns解析流程？
- 二十四、pod与pod建立不了联系，什么原因造成？
- 二十五、kubectl怎么跟apiserver进行交互？
- 二十六、pod的异常有那些 怎么排查及解决？
- 二十七、pod的就绪探针有几种,工作方式是什么？
- 二十八、dockfile的常用命令
- 二十九、docke file copy 和add的区别？
- 三十、CMD和ENTRYPOINT的区别？
- 三十一、用shell怎么删除某一个路径下10天前的日志？
- 三十二、ExternalName是什么?作用是什么?
- 三十三、什么是 Ingress Controller？它的作用是什么及工作原理？
- 三十四、Ingress 和 Ingress Controller 的区别是什么？
- 三十五、secret和configmap的区别？
- 三十六、自定义endpion的过程
- 三十七、nginx调优你会怎么处理？
- 三十八、mysql脏读是什么情况下造成的？
- 三十九、elk的数据流向？
- 四十、es集群一般几个节点？
- 四十一、怎么理解pod的亲和性和反亲和性？
- 四十二、目前有一个机器要重启，里面有核心应用的pod，你会怎么处理？
- 四十三、docker制作镜像的步骤？
- 四十四、docker基本命令和containerd的基本命令有什么区别?
- 四十五、containerd除了ctr还有什么工具对镜像管理？
- 四十六、什么是pod？
- 四十七 pod里面的容器是怎么通信的？
- 四十八、不同宿主机上的pod是怎么通信的？
- 四十八、pvc的状态是pending的，怎么处理？
- 四十九、pod calico一直处于未就绪状态 怎么排查？
- Specify interface
一、你使用的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 etcd
API 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-quota
namespace: production
spec:
hard:
requests.cpu: "20" # 总 CPU 请求不超过 20 核
requests.memory: "64Gi" # 总内存请求不超过 64GB
limits.cpu: "40" # 总 CPU 限制不超过 40 核
limits.memory: "128Gi" # 总内存限制不超过 128GB
2.设置限制范围（Limit Ranges）
作用：为命名空间中的 Pod 设置默认资源请求/限制。
配置示例：
apiVersion: v1
kind: LimitRange
metadata:
name: default-limits
namespace: 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-ingress
annotations:
nginx.ingress.kubernetes.io/rate-limit: "10r/s"
spec:
rules:
- host: example.com
http:
paths:
- path: /app
pathType: Prefix
backend:
service:
name: my-service
port:
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-app
ingress:
- 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 {} ;
三十二、ExternalName是什么?作用是什么?
ExternalName 是 Kubernetes 中 Service 的一种类型，主要用于将 Kubernetes 集群内的服务通过一个固定的 DNS 名称映射到集群外部的服务地址。其作用是通过 DNS 名称解析，将集群内部的服务调用透明地转发到外部服务，而无需直接暴露外部服务的 IP 地址或域名。
ExternalName 的作用
服务映射：
将 Kubernetes 集群内的服务名称映射到外部服务（如外部数据库、API 服务等）的域名或 IP 地址。
例如，将集群内的服务 my-external-service 映射到外部域名 example.com。
简化服务调用：
集群内的 Pod 可以通过服务名称（如 my-external-service）访问外部服务，而无需直接使用外部服务的域名或 IP 地址。
这使得服务调用更加简洁和灵活，特别是在外部服务地址发生变化时，只需修改 Service 的配置，而无需修改调用方的代码。
支持 DNS 解析：
ExternalName 类型的 Service 通过 DNS 解析将服务名称映射到外部地址，因此需要 Kubernetes 集群的 DNS 服务（如 CoreDNS）支持。
三十三、什么是 Ingress Controller？它的作用是什么及工作原理？
概念：Ingress Controller 是 Kubernetes 集群中的一个核心组件，用于管理和实现 Ingress 资源的流量路由规则。它的主要作用是将外部 HTTP/HTTPS 请求根据定义的规则转发到集群内部的服务（Service）上，从而实现集群内服务的外部暴露和流量管理
Ingress Controller 的核心作用
实现 Ingress 规则
Ingress 资源是 Kubernetes 中的一种 API 对象，用于定义集群外部流量如何路由到内部服务（Service）。
Ingress Controller 负责监听 Ingress 资源的变更，并根据规则动态配置反向代理或负载均衡器（如 Nginx、HAProxy、Traefik 等），将流量转发到对应的服务。
提供反向代理和负载均衡
作为反向代理服务器，Ingress Controller 接收外部请求，并根据请求的域名、路径、头信息等匹配 Ingress 规则，将流量分发到后端服务。
支持多种负载均衡算法（如轮询、IP 哈希等），确保流量均匀分布。
支持 HTTPS 和 SSL/TLS 终止
可以集成证书管理工具（如 cert-manager），自动为域名申请和更新 SSL/TLS 证书，实现 HTTPS 加密通信。
在 Ingress Controller 层面终止 SSL/TLS，减轻后端服务的加密解密负担。
提供高级流量管理功能
基于路径或域名的路由：根据请求的 URL 路径或域名将流量转发到不同的服务。
访问控制：支持基于 IP、用户认证、请求速率限制等策略，保护后端服务。
重写和重定向：修改请求头、路径或响应状态码，实现灵活的流量处理。
会话保持：确保同一客户端的请求始终路由到同一后端实例。
统一入口管理
为多个服务提供单一的外部访问入口，简化集群外部的流量管理。
支持多租户场景，通过命名空间或注解隔离不同团队的 Ingress 规则。
Ingress Controller 的工作原理
(1)监听 Ingress 资源
Ingress Controller 通过 Kubernetes API 服务器持续监听 Ingress 资源的创建、更新和删除事件。
(2)生成配置
根据 Ingress 规则动态生成反向代理或负载均衡器的配置文件（如 Nginx 配置文件）。
(3)应用配置
重新加载或热更新反向代理的配置，使新的路由规则立即生效。
(4)处理流量
接收外部请求，根据规则匹配后端服务，并将请求转发到相应的 Pod。
三十四、Ingress 和 Ingress Controller 的区别是什么？
Ingress：
是一个 Kubernetes API 对象，用于定义路由规则（如域名、路径到服务的映射）。
Ingress Controller：
是一个独立的组件，负责监听 Ingress 资源的变化，并将规则转换为实际的负载均衡配置（如 Nginx 配置文件）。
关系：
Ingress 是规则定义，Ingress Controller 是规则的实现者。
三十五、secret和configmap的区别？
核心区别
ConfigMap：用途 存储非敏感的配置数据（如环境变量、配置文件）、 数据以明文形式存储（可被有权限的用户查看）、单个键值对最大 1MB，总大小无明确限制
Secret：存储敏感信息（如密码、令牌、密钥）、数据以 Base64 编码存储（仍可通过解码查看)、单个键值对最大 1MB，总大小无明确限制
使用场景
ConfigMap：
用于存储非敏感的配置信息，例如：
应用程序的环境变量。
配置文件内容（如 Nginx 配置）。
启动参数。
Secret：
用于存储敏感信息，例如：
数据库密码。
API 密钥。
TLS 证书。
安全性
ConfigMap：
数据以明文形式存储在 etcd 中，集群中的有权限用户可以查看。
适合存储非敏感数据。
Secret：
数据以 Base64 编码存储，但 Base64 不是加密方式，仅是编码方式，解码后仍为明文。
尽管如此，Secret 的设计初衷是提醒开发者避免将敏感数据以明文形式存储在 ConfigMap 中。
数据大小限制
ConfigMap 和 Secret 的数据大小限制相同：
单个键值对的值最大为 1MB。
整个对象的总大小没有明确限制，但过大的对象可能导致性能问题。
默认权限
ConfigMap 和 Secret 的默认权限相同：
默认情况下，集群中的有权限用户（如具有 view 角色的用户）可以读取。
可以通过 RBAC（基于角色的访问控制）限制访问权限。
三十六、自定义endpion的过程
在 Kubernetes 中，自定义 Endpoint（Endpoint） 通常指的是手动创建或修改 Endpoint 对象，以实现服务发现或负载均衡功能，而不是依赖 Kubernetes Service 自动生成 Endpoint。以下是围绕“自定义 Endpoint 过程”的详细说明：
什么是 Endpoint？
Endpoint 是 Kubernetes 中的一种资源对象，用于存储服务（Service）后端 Pod 的 IP 地址和端口信息。
默认情况下，当创建一个 Service 时，Kubernetes 会根据 Service 的 selector 自动关联匹配的 Pod，并生成对应的 Endpoint。
自定义 Endpoint：手动创建或修改 Endpoint 对象，用于覆盖或扩展默认的 Service-Endpoint 关联逻辑。
为什么需要自定义 Endpoint？
非 Pod 后端：服务需要访问外部资源（如数据库、外部 API、物理服务器），这些资源没有对应的 Pod。
多集群或混合云：服务需要访问其他 Kubernetes 集群或云服务中的资源。
特殊负载均衡需求：需要手动控制后端节点的 IP 和端口。
三十七、nginx调优你会怎么处理？
(1)优化基本配置
调整工作进程和连接数
worker_processes：设置为 CPU 核心数，或 auto，以充分利用多核 CPU。
worker_connections：根据业务负载调整，通常每个 worker 进程可处理数千连接
默认值
worker_processes
默认值为 1，表示 Nginx 只启动一个工作进程。
推荐调整：根据服务器的 CPU 核心数设置，通常设置为 CPU 核心数 或 auto（自动检测核心数）。例如，4 核 CPU 可设置为 4 或 auto。
worker_connections
默认值为 512，表示每个工作进程最多可同时处理 512 个连接。
推荐调整：根据服务器的内存和预期并发量设置，通常可调整为 1024~65535。例如，16GB 内存的服务器可设置为 16384 或更高。
(2)压缩与缓存
启用 Gzip 压缩
减少传输数据量，提升加载速度。
启用浏览器缓存
通过 expires 和 cache-control 头减少重复请求。
(3)负载均衡与反向代理
配置负载均衡
使用 upstream 模块分发请求到多个后端服务器。
启用健康检查
结合第三方模块（如 nginx_upstream_check_module）实现后端健康检查。
三十八、mysql脏读是什么情况下造成的？
脏读（Dirty Read） 是指一个事务读取了另一个未提交事务的修改数据。这种问题通常发生在 事务隔离级别较低 的情况下，例如 读未提交（Read Uncommitted） 隔离级别。
步骤说明：
事务 A 启动并修改了一条数据（如将用户余额从 100 改为 200），但尚未提交。
事务 B 在事务 A未提交的情况下，读取了这条被修改的数据（读取到 200）。
事务 A 由于某种原因回滚（Rollback），数据恢复到原始值 100。
事务 B 读取到的 200 是无效的“脏数据”，因为事务 A 的修改从未真正生效。
如何避免脏读
提高事务隔离级别：
将隔离级别设置为 读已提交（Read Committed） 或更高。
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
使用锁机制：
读取数据时加锁（如 SELECT … FOR UPDATE），防止其他事务修改数据。
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;
– 执行其他操作
COMMIT;
三十九、elk的数据流向？
数据采集（Logstash 或 Filebeat)> 数据传输与处理（Logstash）>传输到 Elasticsearch存储为索引>Kibana（数据可视化）
四十、es集群一般几个节点？
主节点（Master Node）：
集群元数据管理，不存储数据。
推荐奇数个（如3、5），确保选举稳定性。
数据节点（Data Node）：
存储和索引数据，处理读写请求。
数量根据数据量动态扩展。
协调节点（Coordinating Node）：
接收客户端请求，分发到数据节点。
可缓解数据节点压力，提升查询性能。
摄取节点（Ingest Node）：
预处理数据（如格式转换、字段提取）。
适合数据清洗需求高的场景。
四十一、怎么理解pod的亲和性和反亲和性？
Pod 的基本概念
在 Kubernetes 中，Pod 是最小的调度单元，通常包含一个或多个容器（如应用容器和 Sidecar 容器）。Pod 的设计理念是“共存”，即 Pod 内的容器共享网络命名空间、存储卷和资源，协同完成特定任务。
类比：
Pod 就像一个“集装箱”，容器是集装箱内的“货物”。货物之间通过集装箱共享资源（如网络、存储），而 Kubernetes 负责将集装箱调度到合适的节点上
亲和性和反亲和性是 Kubernetes 调度器（Scheduler）的规则，用于控制 Pod 如何分配到节点上。
亲和性（Affinity）
定义：让 Pod 倾向于调度到特定条件的节点上。
作用：实现资源优化、性能提升或业务需求。
类型：
节点亲和性（Node Affinity）：基于节点的标签（Label）选择。
Pod 亲和性（Pod Affinity）：基于其他 Pod 的标签选择。
例：
将需要高性能计算的 Pod 调度到带有 gpu=true 标签的节点上。
将需要低延迟通信的 Pod 调度到与数据库 Pod 同一节点的 Pod 上。
反亲和性（Anti-Affinity）
定义：让 Pod 避免调度到特定条件的节点或与其他 Pod 共存。
作用：提高可用性、避免资源争用或满足合规要求。
类型：
节点反亲和性（Node Anti-Affinity）：避免调度到特定标签的节点。
Pod 反亲和性（Pod Anti-Affinity）：避免与其他特定 Pod 共存。
示例：
避免将同一应用的多个副本调度到同一节点，防止单点故障。
避免将需要高磁盘 I/O 的 Pod 与数据库 Pod 调度到同一节点。
亲和性与反亲和性的配置方式
通过 affinity 字段在 Pod 规范中配置，支持两种规则：
requiredDuringSchedulingIgnoredDuringExecution：
必须满足的规则，否则 Pod 无法调度。
preferredDuringSchedulingIgnoredDuringExecution：
优先满足的规则，调度器会尽量满足，但不保证。
四十二、目前有一个机器要重启，里面有核心应用的pod，你会怎么处理？
(1)评估影响范围
确认 Pod 类型：
StatefulSet：有状态应用（如数据库），需特别关注数据持久性。
Deployment：无状态应用（如 Web 服务），可通过副本重启恢复。
DaemonSet：节点本地服务（如日志收集），需确保其他节点能接管
(2)检查副本数：
若Pod 有多个副本，可通过滚动更新（Rolling Update）避免服务中断。
若为单副本，需优先扩容或迁移。
(3)分析依赖关系：
确认 Pod 是否依赖其他服务（如数据库、缓存），避免级联故障。
临时应急方案
1.立即保护服务
驱逐策略（Eviction Policy）：
修改节点的 taints，临时阻止新 Pod 调度到该节点：
kubectl taint nodes node.kubernetes.io/unschedulable:NoSchedule
等待现有 Pod 迁移到其他节点（需确保集群有足够资源）。
手动迁移 Pod：
若集群资源紧张，可手动删除 Pod，触发 Deployment 控制器在其他节点重新调度：
kubectl delete pod --grace-period=0 --force
2.快速扩容
临时增加副本数，确保服务可用性：
kubectl scale deployment --replicas=
重启后缩减副本数，避免资源浪费。
长期优化方案
1.节点维护策略
启用 Kubernetes 节点维护模式：
使用 kubectl drain 优雅驱逐 Pod，确保数据一致性：
kubectl drain --ignore-daemonsets --delete-emptydir-data
重启后重新标记节点为可调度：
kubectl uncordon
自动化维护窗口：
配置 Kubernetes 节点自动升级（如通过 Cluster Autoscaler 或 Operator），减少人工干预。
2.高可用性设计
Pod 反亲和性：
配置 Pod 反亲和性，避免同一应用的多个副本调度到同一节点：
yaml
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- my-app
topologyKey: kubernetes.io/hostname
跨区域部署：
将 Pod 分布到不同可用区（AZ），防止单节点或单区域故障。
3.数据持久化
PVC 快照：
在重启前创建 PersistentVolumeClaim（PVC）的快照，防止数据丢失。
StatefulSet 配置：
确保 StatefulSet 的 volumeClaimTemplates 配置正确，支持数据持久化。
监控与恢复
实时监控：
使用 Prometheus 或 Grafana 监控 Pod 状态、节点负载和应用性能。
自动恢复：
配置 Kubernetes 的 Pod Disruption Budget（PDB），确保关键服务在节点重启期间可用副本数不低于阈值：
yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: my-app-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: my-app
日志分析：
检查 Pod 和节点的日志，定位重启过程中是否出现异常：
bash
kubectl logs -p # 查看上一个容器的日志
四十三、docker制作镜像的步骤？
1.安装docker
2.基于 Dockerfile 创建镜像
编写 Dockerfile
创建一个 Dockerfile 文件，定义镜像的构建步骤
FROM nginx:latest
COPY index.html /usr/share/nginx/html/
EXPOSE 80
构建镜像
docker build -t my-image:1.0 .
-t：指定镜像名称和标签。
.：表示当前目录为构建上下文
验证镜像
查看镜像列表
使用以下命令查看已创建的镜像：
docker images
运行镜像
docker run -d -p 8080:80 my-image:1.0
推送镜像到仓库（可选）
登录 Docker Hub
docker login
标记镜像
为镜像添加仓库标签：
docker tag my-image:1.0 your-username/my-image:1.0
推送镜像
docker push your-username/my-image:1.0
四十四、docker基本命令和containerd的基本命令有什么区别?
| 说明 | docker命令 | containerd命令 |
|---|---|---|
| 查看本地镜像 | docker images | ctr images ls |
| 拉取镜像 | docker pull imagename | ctr images pull imagename |
| 推送镜像 | docker push imagename | ctr images push imagename |
| 给镜像打标签 | docker tag imagename tagname | ctr images tag imagename tagname |
| 导出镜像 | docker save filename imagename | ctr images export filename imagename |
| 导入镜像 | docker load filename | ctr image import filename |
| 运行并创建容器 | docker run [options] | ctr run [options] imagename |
| containername | ||
| 进入容器 | docker exec [options] names commond | ctr task exec [options] names commond |
| 进入容器 | docker exec [options] names commond | ctr task exec [options] names commond |
| 查看运行的容器 | docker ps | ctr task list |
| 删除容器 | docker rm [options] names | ctr task rm -f names |
四十五、containerd除了ctr还有什么工具对镜像管理？
| 工具 | 主要用途 | 与 Docker CLI 的兼容性 | 与 Kubernetes 的集成 |
|---|---|---|---|
| ctr | containerd 的原生 CLI | 不兼容 | 不直接集成 |
| nerdctl | 提供类似 Docker 的体验 | 兼容 | 不直接集成，但可管理 Kubernetes 资源 |
| crictl | Kubernetes CRI 的 CLI | 不兼容 | 紧密集成 |
总结
如果需要直接与 containerd 交互并使用其原生功能，选择 ctr。
如果需要类似 Docker CLI 的体验，选择 nerdctl。
如果在 Kubernetes 环境中管理容器运行时，选择 crictl。
四十六、什么是pod？
在 Kubernetes（简称 K8s）中，Pod 是最小的可部署单元，也是 Kubernetes 集群中资源分配和调度的基本单位。它可以将一个或多个容器（Container）打包在一起，作为一个整体进行管理、调度和部署。
Pod 的核心概念
容器封装：
一个 Pod 可以包含一个或多个紧密耦合的容器，这些容器共享相同的网络命名空间（IP 地址、端口）和存储卷（Volume）。
容器之间通过 localhost 通信，适合需要协作的微服务架构。
共享资源：
网络：Pod 内的所有容器共享同一个网络命名空间，拥有相同的 IP 地址和端口空间。
存储：Pod 内的所有容器可以挂载相同的存储卷（Volume），实现数据共享。
生命周期：Pod 的生命周期是短暂的，当 Pod 被删除或重新调度时，其内的容器也会被销毁和重建。
调度单位：
Kubernetes 调度器以 Pod 为单位进行资源分配和调度，确保 Pod 被分配到合适的节点（Node）上运行。
抽象层次：
Pod 是对容器的一种更高层次的抽象，简化了容器编排的复杂性。
Pod 的使用场景
单一容器场景：
如果一个应用只需要一个容器，那么可以直接将其封装在 Pod 中。
多容器场景：
边车模式（Sidecar）：在主容器旁边运行一个辅助容器，例如日志代理、监控代理等。
适配器模式（Adapter）：对主容器的输出进行格式化或转换。
代理模式（Ambassador）：为主容器提供网络代理服务。
Pod 的生命周期
Pod 的生命周期包括以下几个阶段：
Pending（挂起）：
Pod 已被创建，但尚未分配到节点上运行。
Running（运行中）：
Pod 已被分配到节点上，并且所有容器都已启动并正在运行。
Succeeded（成功）：
Pod 内的所有容器都已成功终止，并且不会重启。
Failed（失败）：
Pod 内的至少一个容器以非零状态退出，并且不会重启。
Unknown（未知）：
由于某种原因，无法获取 Pod 的状态。
Pod 的示例
以下是一个简单的 Pod 定义文件（YAML 格式）：
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx:latest
ports:
- containerPort: 80
解释：
定义了一个名为 my-pod 的 Pod。
Pod 内包含一个名为 my-container 的容器，使用 nginx:latest 镜像。
容器暴露了 80 端口。
Pod 与容器的关系
容器 是运行应用程序的最小单位，而 Pod 是对容器的封装和管理。
Pod 提供了容器之间的协作机制，例如共享网络和存储，使得多个容器可以作为一个整体进行调度和管理。
总结
Pod 是 Kubernetes 中的核心概念，是容器编排的基础。
Pod 提供了一种将多个容器组合在一起的方式，使得它们可以共享资源并协同工作。
理解 Pod 的概念对于掌握 Kubernetes 的工作原理至关重要。
通过 Pod，Kubernetes 提供了一种灵活且强大的方式来管理和部署容器化应用，使得开发者可以专注于应用逻辑，而无需关心底层的资源调度和管理。
四十七 pod里面的容器是怎么通信的？
通信方式
（1）通过 localhost 通信
原理：
Pod 内的所有容器共享同一个 网络命名空间，因此它们拥有相同的 IP 地址 和 端口范围。
容器之间可以通过 localhost 和目标容器的端口号直接通信。
示例：
Pod 内有两个容器：
容器 A 监听端口 8080。
容器 B 通过 http://localhost:8080 访问容器 A。
优势：
低延迟、高性能，无需网络跳转。
（2）通过共享存储通信
原理：
Pod 内的容器可以挂载相同的 存储卷（如 EmptyDir、ConfigMap、Secret 等）。
容器 A 将数据写入存储卷，容器 B 从存储卷读取数据。
示例：
容器 A 是一个日志生成器，将日志写入 EmptyDir 卷。
容器 B 是一个日志收集器，从 EmptyDir 卷读取日志。
优势：
适用于需要共享文件的场景，如日志、配置文件等。
通过环境变量或命令行参数
原理：
在 Pod 的定义中，可以通过环境变量或命令行参数将信息（如地址、端口）传递给容器。
示例：
在 Pod 的 YAML 中定义：
env:
- name: TARGET_SERVICE
value: "http://localhost:8080"
容器 B 使用 TARGET_SERVICE 环境变量访问容器 A。
优势：
适用于动态配置或需要传递少量信息的场景。
四十八、不同宿主机上的pod是怎么通信的？
Pod 间通信：
每个 Pod 分配一个唯一的 Cluster IP，Pod 可以通过 Cluster IP 直接通信。
例如，Pod A（IP: 10.244.1.2）向 Pod B（IP: 10.244.2.3）发送请求，数据包通过底层网络直接路由到目标 Pod。
Service 通信：
Service 提供稳定的虚拟 IP 和端口，通过 kube-proxy 或 IPVS 转发请求到后端 Pod。
例如，Service 虚拟 IP 为 10.96.0.1，Pod A 通过该 IP 访问 Service，kube-proxy 将请求负载均衡到后端 Pod。
（2）跨集群通信
联邦集群（Kubernetes Federation）：
通过 Federation v2 或其他多集群管理工具，实现跨集群的 Service 和 Pod 通信。
Ingress/Egress 网关：
使用 Istio、Linkerd 等服务网格，或自定义网关（如 NGINX、Envoy），实现跨集群的流量路由。
（3）外部访问
NodePort：
将 Service 暴露为宿主机上的端口，外部客户端通过宿主机 IP 和端口访问 Pod。
LoadBalancer：
依赖云服务商的负载均衡器，将流量分发到后端 Pod。
Ingress：
通过 HTTP/HTTPS 路由规则，将外部请求转发到集群内的 Service。
四十八、pvc的状态是pending的，怎么处理？
(1)检查 StorageClass
kubectl get sc
确保默认的 StorageClass 配置正确。如果未配置或配置错误，需要更新或创建一个新的 StorageClass
(2)检查存储后端、
存储后端状态：
确保存储后端（如 NFS、Ceph、EBS 等）已正确配置并运行正常。
日志检查：
检查存储后端的日志，确定是否存在任何问题。
(3)检查 PV 和 PVC 的匹配性
资源匹配：
确保 PVC 请求的存储大小和访问模式与 PV 匹配。例如，如果 PVC 请求 100Gi 的存储空间，但只有一个 50Gi 的 PV 可用，PVC 将处于 Pending 状态。
访问模式一致性：
检查 PV 和 PVC 的访问模式是否一致（如 ReadWriteOnce、ReadOnlyMany 等）。
(4)检查节点资源
资源使用情况：
检查节点上的 CPU、内存和存储资源是否足够
kubectl describe node
(5)检查 Kubernetes 集群状态
集群健康检查：
确保集群中没有其他错误或问题。
bash
kubectl get pods --all-namespaces
四十九、pod calico一直处于未就绪状态 怎么排查？
1.查看未就绪的calico pod 状态
kubectl describe pod calico-node-vjchp -n kube-system
ip a 查看k8s集群的ip是哪个网卡
在calico 的containers -> env 中修改如下内容
Specify interface
- name: IP_AUTODETECTION_METHOD
value: "interface=eth1"
重启calico，问题解决
2.NetworkManager 与 Calico 冲突
NetworkManager 默认可能会管理所有网络接口，包括 Calico 创建的虚拟接口（如 tunl0）。如果 NetworkManager 试图接管这些接口，可能会导致接口状态异常或无法正确工作。
解决方法：
确保 NetworkManager 不管理 tunl0 接口。可以通过配置 /etc/NetworkManager/NetworkManager.conf 文件，添加以下内容：
[keyfile]
unmanaged-devices=interface-name:tunl0
然后重启 NetworkManager 服务
sudo systemctl restart NetworkManager
3.Calico 版本与 Kubernetes/内核版本不兼容
问题描述：
Calico 的不同版本对 Kubernetes 和内核版本有特定要求。如果版本不匹配，可能会导致 tunl0 接口无法创建或功能异常。
解决方法：
检查 Calico 的版本与 Kubernetes 的兼容性：
参考 Calico 官方文档 查看支持的版本。
如果版本不兼容，考虑升级或降级 Calico 或 Kubernetes。
本文地址：https://www.vps345.com/15464.html
