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 {} ;