娄底北京网站建设,网站架构分类,企业黄页88网,车佣做汽车网站怎么样一、你使用的promethues监控pod的哪些指标#xff1f; CPU使用率 内存使用率 网络吞吐量 磁盘I/O 资源限制和配额#xff1a;Prometheus可以监控Pod的资源请求和限制#xff0c;确保它们符合预设的配额#xff0c;防止资源过度使用。具体指标如container_spec_cpu_quota用于…一、你使用的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/fstab2.加入集群 2.1 从主节点获取加入命令 生成 token若默认 token 过期
kubeadm token create --print-join-command获取命令
# 输出示例替换为实际值
kubeadm join 主节点IP:端口 --token token --discovery-token-ca-cert-hash hash2.2 在新节点执行加入命令 执行命令
sudo kubeadm join 192.168.1.100:6443 --token abcdef.0123456789abcdef --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx验证节点状态 查看节点列表
kubectl get nodesReady 状态新节点状态应为 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 -caca.pem -ca-keyca-key.pem \-configca-config.json -profileetcd 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 GatewayIstio 服务网格的流量入口控制器、技术实现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-appregistry.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同步报文附带随机初始序列号 seqx。 目的客户端表明自己已准备好通信请求建立连接。 第二次握手 服务器响应 SYN-ACK同步-确认报文包含 对客户端 SYN 的确认号 ackx1。 自己的初始序列号 seqy。 目的服务器确认客户端请求并告知自己已准备好。 第三次握手 客户端发送 ACK确认报文确认号 acky1。 目的客户端确认服务器已就绪连接正式建立。 握手核心逻辑双方通过交换序列号确认彼此收发能力防止历史连接干扰。
二、TCP四次挥手关闭连接 第一次挥手 客户端发送 FIN结束报文序列号 sequ。 目的客户端声明数据已发送完毕请求关闭连接。 第二次挥手 服务器响应 ACK 报文确认号 acku1。 目的服务器确认客户端的关闭请求但可能还有数据未发送。 第三次挥手 服务器发送 FIN 报文序列号 seqv。 目的服务器声明数据已全部发送请求关闭连接。 第四次挥手 客户端响应 ACK 报文确认号 ackv1。 目的客户端确认服务器的关闭请求连接完全终止。 挥手核心逻辑确保双向数据均传输完毕避免数据丢失。
十五、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 # 总内存限制不超过 128GB2.设置限制范围Limit Ranges 作用为命名空间中的 Pod 设置默认资源请求/限制。 配置示例
apiVersion: v1
kind: LimitRange
metadata:name: default-limitsnamespace: production
spec:limits:- default:cpu: 1memory: 512MidefaultRequest:cpu: 0.5memory: 256Mitype: Container3.动态调整资源限制 手动调整 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的区别
特性CalicoFlannel网络模型三层路由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: appnginx 关联到该 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 version2.创建命名空间可选 在 Kubernetes 中创建命名空间如 my-namespace
kubectl create namespace my-namespace3.手动打包 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.tgzChart 包路径。 -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 列表如果服务配置了选择器selectorCoreDNS 还会返回匹配的 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-appkube-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 appcalico-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.pyCMD 被覆盖但 ENTRYPOINT 保留。
核心区别总结 特性 CMD ENTRYPOINT 覆盖性 容易被覆盖 不易被覆盖 参数传递 独立命令 可与 CMD 参数结合 典型场景 默认启动命令或参数 固定入口命令如主进程
使用场景建议 用 CMD当需要灵活覆盖默认命令时如调试或临时任务。 用 ENTRYPOINT当需要固定容器的主进程如必须运行某个服务。 组合使用ENTRYPOINT 定义主命令CMD 定义默认参数。
三十二、用shell怎么删除某一个路径下10天前的日志 find /path/to/logs -name “*.log” -mtime 10 -exec rm {} ;
