K8s 常見面試題,讓你求職不迷路
前段時間在這個視頻中分享了 https://github.com/bregman-arie/devops-exercises 這個知識倉庫。
這次繼續分享里面的內容,本次主要以 k8s 相關的問題為主。
k8s 是什么,為什么企業選擇使用它
k8s 是一個開源應用,給用戶提供了管理、部署、擴展容器的能力,以下幾個例子更容易理解:
- 你可以將容器運行在不同的機器或節點中,并且可以將一些變化同步給這些容器,簡單來說我們只需要編寫 yaml 文件,告訴 k8s 我的預期是什么,其中同步變化的過程全部都交給 k8s 去完成。
其實就是我們常說的聲明式 API
- 第二個特點剛才已經提到了,它可以幫我們一鍵管理多個容器,同步所有的變更。
- 可以根據當前的負載調整應用的副本數,負載高就新創建幾個應用實例,低就降低幾個,這個可以手動或自動完成。
什么時候使用或者不使用 k8s
- 如果主要還是使用物理機這種低級別的基礎設施的話,不太建議使用 k8s,這種情況通常是比較傳統的業務,沒有必要使用 k8s。
- 第二種情況是如果是小團隊,或者容器規模較小時也不建議使用,除非你想使用 k8s 的滾動發布和自擴容能力,
不過這些功能運維自己寫工具也能實現。
k8s 有哪些特性
- 是自我修復,k8s 對容器有著健康檢測,比如使用啟動探針、存活探針等,或者是容器 OOM 后也會重啟應用嘗試修復。
- 自帶負載均衡,使用 service 可以將流量自動負載到后續 Pod 中,如果 Pod 提供的是 http 服務這個夠用了,但如果是 grpc 這樣的長鏈接,就需要使用 istio 這類服務網格,他可以識別出協議類型,從而做到請求級別的負載均衡。
- Operator 自動運維能力:k8s 可以根據應用的運行情況自動調整當前集群的 Pod 數量、存儲等,拿 Pulsar 舉例,當流量激增后自動新增 broker,磁盤不足時自動擴容等。
- 滾動更新能力:當我們發版或者是回滾版本的時候,k8s 會等待新的容器啟動之后才會將流量切回來,同時逐步停止老的實例。
- 水平擴展能力:可以靈活的新增或者是減少副本的數量,當然也可以自動控制。
- 數據加密:使用 secret 可以保存一些敏感的配置或者文件。
k8s 有著哪些對象
這個就是考察我們對 k8s 是否是熟悉了,常用的有:
- Pod
- Service
- ReplicationController
- DaemonSet
- namespace
- ConfigMap 這個其實知道沒有太多作用,主要還是得知道在不同場景如何使用不同的組件。
哪些字段是必須的
這個問題我也覺得意義不大,只要寫過 yaml 就會知道了,metadata, kind, apiVersion。
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: app
name: app
kubectl 是什么
其實就是一個 k8s 的 命令行客戶端。
當你部署應用的時候哪些對象用的比較多
- 第一個肯定是 deployment,這應該是最常見的部署方式。
- service: 可以將流量負載到 Pod 中。
- Ingress: 如果需要從集群外訪問 Pod 就得需要 Ingress 然后 配合域名訪問。
為什么沒有 k get containers 這個命令
這個問題主要是看對 Pod 的理解,因為在 k8s 中 Pod 就是最小的單位了,如果想要訪問容器可以在 Pod 中訪問。
我們可以加上 -c 參數進入具體的容器。
kubectl exec -it app -c istio-proxy
你認為使用使用 k8s 的最佳實踐是什么
這個主要是看日常使用時有沒有遇到什么坑了:
- 第一個就是要驗證 yaml 內容是否正確,這個確實很重要,一旦執行錯了后果很嚴重,比如使用 helm 的時候最好豈容 dry-run 和 debug,先看看生成的 yaml 是否是預期想要的。
helm upgrade app --dry-run --debug
- 第二個限制資源的使用,比如 CPU 和 內存,這個也很重要,如果不設置一旦應用出現 bug 可能導致整個 k8s 集群都受到影響。
- 為 Pod,deployment 指定標簽,用于分組。
# 資源限制
resources:
limits:
cpu: 200m
memory: 200Mi
requests:
cpu: 100m
memory: 100Mi
參考來源:https://github.com/bregman-arie/devops-exercises/blob/master/topics/kubernetes/README.md#kubernetes-101。