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

.