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