50 個你必須掌握的 Kubernetes 面試題

運維之美2019-08-18 02:26:29

Kubernetes 一直是當今業界的流行語,也是最好的編排工具。它吸引了許多想要提升自己職業生涯的經驗豐富的專業人士。

Huwaei、Pokemon、Box、eBay、Ing、Yahoo Japan、SAP、紐約時報、Open AI、Sound Cloud 等跨國公司也使用 Kubernetes。我相信你已經知道這些事實,這也是促使你打開這個 Kubernetes 面試問題文章原因。

在這篇關於 Kubernetes 面試問題的文章中,我將討論在面試中提出的與 Kubernetes 相關的最重要問題。因此,為了您的理解,我將此文內容分為以下 4 個部分:

  • Kubernetes 基本面試問題

  • 基於架構的面試問題

  • 基於場景的面試問題

  • 多項選擇題

現在,讓我們開始吧!

基本的 Kubernetes 面試問題

這部分問題將包含您需要了解的與 Kubernetes 工作相關的所有基本問題。

Q1、Kubernetes 與 Docker Swarm 的區別如何?

Q2、什麼是 Kubernetes?

Kubernetes 是一個開源容器管理工具,負責容器部署,容器擴縮容以及負載平衡。作為 Google 的創意之作,它提供了出色的社區,並與所有云提供商合作。因此,我們可以説 Kubernetes 不是一個容器化平台,而是一個多容器管理解決方案。

Q3、Kubernetes 與 Docker 有什麼關係?

眾所周知,Docker 提供容器的生命週期管理和 Docker 鏡像構建運行時容器。但是,由於這些單獨的容器有時必須跨主機通信,這時我們需要使用 Kubernetes 來解決這個問題。

因此,我們説 Docker 構建容器,但這些容器通過 Kubernetes 來進行跨主機相互通信。我們還可以使用 Kubernetes 手動關聯和編排在多個主機上運行的容器。

Q4、在主機和容器上部署應用程序有什麼區別?

請參考上圖。左側架構表示在主機上部署應用程序。因此,這種架構將具有操作系統,然後操作系統將具有內核,該內核將在應用程序所需的操作系統上安裝各種庫。因此,在這種框架中,您可以擁有 N 個應用程序,並且所有應用程序將共享該操作系統中存在的庫,而在容器中部署應用程序時,體系結構則略有不同。

這種架構將有一個內核,這是唯一一個在所有應用程序之間唯一共同的東西。因此,如果有一個需要 Java 的特定應用程序,那麼我們將獲得訪問 Java 的特定應用程序,如果有另一個需要 Python 的應用程序,則只有該特定應用程序才能訪問 Python。

您可以在圖表右側看到的各個塊基本上是容器化的,並且這些塊與其他應用程序隔離。因此,應用程序具有與系統其餘部分隔離的必要庫和二進制文件,並且不能被任何其他應用程序侵佔。

Q5、什麼是 Container Orchestration?

考慮一個應用程序有 5-6 個微服務的場景。

現在,這些微服務被放在單獨的容器中,但如果沒有容器編排就無法進行通信。因此,由於編排意味着所有樂器在音樂中和諧共處,所以類似的容器編排意味着各個容器中的所有服務協同工作以滿足單個服務器的需求。

Q6、Container Orchestration 需要什麼?

考慮到你有 5-6 個微服務用於執行各種任務的單個應用程序,所有這些微服務都放在容器中。現在,為了確保這些容器彼此通信,我們需要容器編排。

正如您在上圖中所看到的,在沒有使用容器編排的情況下,還存在許多挑戰。因此,為了克服這些挑戰,容器編排就到位了。

Q7、Kubernetes 有什麼特點?

Kubernetes 的功能如下:

Q8、Kubernetes 如何簡化容器化部署?

由於典型應用程序將具有跨多個主機運行的容器集羣,因此所有這些容器都需要相互通信。因此,要做到這一點,你需要一些能夠負載均衡、擴展和監控容器的東西。

由於 Kubernetes 與雲無關並且可以在任何公共/私有提供商上運行,因此必須是您簡化容器化部署的選擇。

Q9、您對 Kubernetes 的集羣瞭解多少?

Kubernetes 背後的基礎是我們可以實施所需的狀態管理,我的意思是我們可以提供特定配置的集羣服務,並且集羣服務將在基礎架構中運行並運行該配置。

因此,正如您在上圖中所看到的,部署文件將具有提供給集羣服務所需的所有配置。

現在,部署文件將被提供給 API,然後由集羣服務決定如何在環境中安排這些 Pod,並確保正確運行的 Pod 的數量。

因此,位於服務前面的 API,工作節點和節點運行的 Kubelet 進程,共同構成了 Kubernetes 集羣。

Q10、什麼是 Google 容器引擎?

Google Container Engine(GKE)是 Docker 容器和集羣的開源管理平台。這個基於 Kubernetes 的引擎僅支持在 Google 的公共雲服務中運行的羣集。

Q11、什麼是 Heapster?

Heapster 是由每個節點上運行的 Kubelet 提供的集羣範圍的數據聚合器。

此容器管理工具在 Kubernetes 集羣上本機支持,並作為 Pod 運行,就像集羣中的任何其他 Pod 一樣。因此,它基本上可以發現集羣中的所有節點,並通過本機上 Kubernetes 代理查詢集羣中 Kubernetes 節點的使用信息。

Q12、什麼是 Minikube?

Minikube 是一種工具,可以在本地輕鬆運行 Kubernetes 集羣。它是在虛擬機中運行一個單節點 Kubernetes 羣集。

Q13、什麼是 Kubectl?

Kubectl 是一個命令行工具,您可以使用該工具將命令傳遞給集羣。

因此,它基本上為 CLI 提供了針對 Kubernetes 集羣運行命令的方法,以及創建和管理 Kubernetes 組件的各種方法。

Q14、什麼是 Kubelet?

這是一個代理服務,它在每個節點上運行,並使從服務器與主服務器通信。因此,Kubelet 處理 PodSpec 中提供給它的容器的描述,並確保 PodSpec 中描述的容器運行正常。

Q15、你對 Kubernetes 的一個節點有什麼瞭解?

基於 Kubernetes 架構的問題

這部分問題將涉及到與 Kubernetes 架構相關的問題。

Q1、Kubernetes Architecture 的不同組件有哪些?

Kubernetes Architecture 主要有兩個組件:主節點和工作節點。

如下圖所示,Master 和 Worker 節點中包含許多內置組件。主節點具有 kube-controller-manager、kube-apiserver、kube-scheduler 等。而工作節點具有在每個節點上運行的 kubelet 和 kube-proxy。

Q2、你對 Kube-proxy 有什麼瞭解?

Kube-proxy 可以在每個節點上運行,並且可以跨後端網絡服務進行簡單的 TCP/UDP 數據包轉發。

基本上,它是一個網絡代理,它反映了每個節點上 Kubernetes API 中配置的服務。因此,Docker 可鏈接的兼容環境變量由代理打開的羣集 IP 和端口提供。

Q3、您能否介紹一下 Kubernetes 中主節點的工作情況?

Kubernetes master 控制器存在的節點和節點內部。現在,這些單獨的容器包含在容器內部和每個容器內部,您可以根據配置和要求擁有不同數量的容器。

因此,如果必須部署 Pod,則可以使用用户界面或命令行界面部署它們。然後,在節點上調度這些 Pod,並根據資源需求將 Pod 分配給這些節點。

Kube-apiserver 確保在 Kubernetes 節點和主要組件之間建立通信。

Q4、Kube-apiserver 和 Kube-scheduler 的作用是什麼?

Kube-apiserver 遵循橫向擴展架構,是主節點控制面板的前端。這將公開 Kubernetes 主節點組件的所有 API,並負責在 Kubernetes 節點和 Kubernetes 主組件之間建立通信。

kube-scheduler 負責工作節點上工作負載的分配和管理。因此,它根據資源需求選擇最合適的節點來運行未調度的 Pod,並跟蹤資源利用率。它確保不在已滿的節點上調度工作負載。

Q5、你能簡要介紹一下 Kubernetes 控制管理器嗎?

多個控制器進程在主節點上運行,但是一起編譯為單個進程運行,即 Kubernetes 控制器管理器。因此,Controller Manager 是一個嵌入控制器並執行命名空間創建和垃圾收集的守護程序。它擁有與 API 服務器通信以管理端點的責任。

因此,主節點上運行的不同類型的控制器管理器是:

Q6、什麼是 Etcd?

Etcd 是用 Go 編程語言編寫的一個分佈式鍵值存儲,用於協調分佈式工作的軟件。因此,Etcd 用來存儲 Kubernetes 集羣的配置數據,這些數據代表在任何給定時間點的集羣狀態。

Q7、Kubernetes 有哪些不同類型的服務?

以下是使用的不同類型的服務:

Q8、你對 Kubernetes 的負載均衡器有什麼瞭解?

負載均衡器是暴露服務的最常見和標準方式之一。

根據工作環境使用兩種類型的負載均衡器,即內部負載均衡器或外部負載均衡器。內部負載均衡器自動平衡負載並使用所需配置分配容器,而外部負載均衡器將流量從外部負載引導至後端容器。

Q9、什麼是 Ingress 網絡,它是如何工作的?

Ingress 網絡是一組規則,充當 Kubernetes 集羣的入口點。

這允許入站連接,可以將其配置為通過可訪問的 URL 負載平衡流量或通過提供基於名稱的虛擬主機從外部提供服務。因此,Ingress 是一個API對象,通常通過 HTTP 管理集羣中服務的外部訪問,是暴露服務的最有效方式。

現在,讓我以一個例子向您解釋 Ingress 網絡的工作。

有 2 個節點具有帶有 Linux 橋接器的 Pod 和根網絡命名空間。除此之外,還有一個名為 flannel0(網絡插件)的新虛擬以太網設備被添加到根網絡中。

現在,假設我們希望數據包從 Pod1 流向 Pod4。請參閲下圖:

  • 因此,數據包將 Pod1 的網絡保留在 eth0,並進入 veth0 的根網絡。

  • 然後它被傳遞給 cbr0,這使得 ARP 請求找到目的地,並且發現該節點上沒有人具有目的地 IP 地址。

  • 因此,橋接器將數據包發送到 flannel0,因為節點的路由表配置了 flannel0。

  • 現在,flannel 守護程序與 Kubernetes 的 API 服務器通信,以瞭解所有 Pod IP 及其各自的節點,以創建 Pods IP 到節點 IP 的映射。

  • 網絡插件將此數據包封裝在 UDP 數據包中,其中額外的標頭將源和目標 IP 更改為各自的節點,並通過 eth0 發送此數據包。

  • 現在,由於路由表已經知道如何在節點之間路由流量,因此它將數據包發送到目標節點2。

  • 數據包到達 node2 的 eth0 並返回到 flannel0 以解封裝並在根網絡命名空間中將其發回。

  • 同樣,數據包被轉發到 Linux 網橋以發出 ARP 請求以找出屬於 veth1 的 IP。

  • 數據包最終穿過根網絡併到達目標 Pod4。

Q10、您對雲控制器管理器有何瞭解?

Cloud Controller Manager 負責持久存儲、網絡路由,從核心 Kubernetes 特定代碼中抽象出特定於雲的代碼,以及管理與底層雲服務的通信。

它可能會分成幾個不同的容器,具體取決於您運行的是哪個雲平台,然後它可以使雲供應商和 Kubernetes 代碼在沒有任何相互依賴的情況下開發。因此,雲供應商開發他們的代碼並在運行 Kubernetes 時與 Kubernetes 雲控制器管理器連接。

各種類型的雲控制器管理器如下:


Q11、什麼是 Container 資源監控?

對於用户而言,瞭解應用程序的性能和所有不同抽象層的資源利用率非常重要,Kubernetes 通過在容器、Pod、服務和整個集羣等不同級別創建抽象來考慮集羣的管理。現在,可以監視每個級別,這只是容器資源監視。

各種容器資源監控工具如下:

Q12、Replica Set 和 Replication Controller 之間有什麼區別?

Replica Set 和 Replication Controller 幾乎完全相同。它們都確保在任何給定時間運行指定數量的 Pod 副本。不同之處在於複製 Pod 使用的選擇器。Replica Set 使用基於集合的選擇器,而 Replication Controller 使用基於權限的選擇器。

  • Equity-Based 選擇器:這種類型的選擇器允許按標籤鍵和值進行過濾。因此,在外行術語中,基於 Equity 的選擇器將僅查找與標籤具有完全相同短語的 Pod。示例:假設您的標籤鍵表示 app = nginx,那麼使用此選擇器,您只能查找標籤應用程序等於 nginx 的那些 Pod。

  • Selector-Based 選擇器:此類型的選擇器允許根據一組值過濾鍵。因此,換句話説,基於 Selector 的選擇器將查找已在集合中提及其標籤的 Pod。示例:假設您的標籤鍵在(nginx、NPS、Apache)中顯示應用程序。然後,使用此選擇器,如果您的應用程序等於任何 nginx、NPS或 Apache,則選擇器將其視為真實結果。

Q13、什麼是 Headless Service?

Headless Service 類似於 “普通” 服務,但沒有羣集 IP。此服務使您可以直接訪問 Pod,而無需通過代理訪問它。

Q14、使用 Kubernetes 時可以採取哪些最佳安全措施?

以下是使用 Kubernetes 時可以遵循的最佳安全措施:

Q15、什麼是集羣聯邦?

在聯邦集羣的幫助下,可以將多個 Kubernetes 集羣作為單個集羣進行管理。因此,您可以在數據中心/雲中創建多個 Kubernetes集羣,並使用聯邦來在一個位置控制/管理它們。

聯邦集羣可以通過執行以下兩項操作來實現此目的。請參考下圖。

基於場景的面試問題

這部分問題將包含您在面試中可能遇到的各種基於場景的問題。

場景1

假設一家基於單一架構的公司處理眾多產品。現在,隨着公司在當今的擴展行業的擴展,他們的單一架構開始引發問題。

您如何看待公司從單一服務轉向微服務並部署其服務容器?

解:由於公司的目標是從單一應用程序轉向微服務,它們最終可以逐個構建,並行構建,只需在後台切換配置。然後他們可以將這些內置微服務放在 Kubernetes 平台上。因此,他們可以從一次或兩次遷移服務開始,並監控它們以確保一切運行穩定。一旦他們覺得一切順利,他們就可以將其餘的應用程序遷移到他們的 Kubernetes 集羣中。

場景2

考慮一家擁有分佈式系統的跨國公司,擁有大量數據中心,虛擬機和許多從事各種任務的員工。

您認為這樣的公司如何以 Kubernetes 一致的方式管理所有任務?

解:正如我們所有人都知道 IT 部門推出了數千個容器,其任務在分佈式系統中遍佈全球眾多節點。在這種情況下,公司可以使用能夠為基於雲的應用程序提供敏捷性,橫向擴展功能和 DevOps 實踐的東西。因此,該公司可以使用 Kubernetes 來定製他們的調度架構並支持多種容器格式。這使得容器任務之間的親和性成為可能,從而提供更高的效率,併為各種容器網絡解決方案和容器存儲提供廣泛支持。

場景3

考慮一種情況,即公司希望通過維持最低成本來提高其效率和技術運營速度。您認為公司將如何實現這一目標?

解:公司可以通過構建 CI/CD 管道來實現 DevOps 方法,但是這裏可能出現的一個問題是配置可能需要一段時間才能啟動並運行。因此,在實施 CI/CD 管道之後,公司的下一步應該是在雲環境中工作。一旦他們開始處理雲環境,他們就可以在集羣上安排容器,並可以在 Kubernetes 的幫助下進行協調。這種方法將有助於公司縮短部署時間,並在各種環境中加快速度。

場景4

假設一家公司想要修改它的部署方法,並希望建立一個更具可擴展性和響應性的平台。您如何看待這家公司能夠實現這一目標以滿足客户需求?

解:為了給數百萬客户提供他們期望的數字體驗,公司需要一個可擴展且響應迅速的平台,以便他們能夠快速地將數據發送到客户網站。現在,要做到這一點,公司應該從他們的私有數據中心(如果他們使用任何)轉移到任何雲環境,如 AWS。不僅如此,他們還應該實現微服務架構,以便他們可以開始使用 Docker 容器。一旦他們準備好基礎框架,他們就可以開始使用最好的編排平台,即 Kubernetes。這將使團隊能夠自主地構建應用程序並快速交付它們。

場景5

考慮一家擁有非常分散的系統的跨國公司,期待解決整體代碼庫問題。您認為公司如何解決他們的問題?

解:那麼,為了解決這個問題,我們可以將他們的單片代碼庫轉移到微服務設計,然後每個微服務都可以被視為一個容器。因此,所有這些容器都可以在 Kubernetes 的幫助下進行部署和協調。

場景6

我們所有人都知道,從單片到微服務的轉變解決了開發方面的問題,但卻增加了部署方面的問題。公司如何解決部署方面的問題?

解:團隊可以試驗容器編排平台,例如:Kubernetes,並在數據中心運行。因此,通過這種方式,公司可以生成模板化應用程序,在五分鐘內部署它,並在此時將實際實例集中在暫存環境中。這種 Kubernetes 項目將有數十個並行運行的微服務,以提高生產率,即使節點出現故障,也可以立即重新安排,而不會影響性能。

場景7

假設一家公司希望通過採用新技術來優化其工作負載的分配。公司如何有效地實現這種資源分配?

解:這個問題的解決方案就是 Kubernetes。Kubernetes 確保資源得到有效優化,並且只使用特定應用程序所需的那些資源。因此,通過使用最佳容器編排工具,公司可以有效地實現資源分配。

場景8

考慮一家拼車公司希望通過同時擴展其平台來增加服務器數量。您認為公司如何處理服務器及其安裝?

解:公司可以採用集裝箱化的概念。一旦他們將所有應用程序部署到容器中,他們就可以使用 Kubernetes 進行編排,並使用像 Prometheus 這樣的容器監視工具來監視容器中的操作。因此,利用容器的這種使用,在數據中心中為它們提供更好的容量規劃,因為它們現在將受到更少的限制,因為服務和它們運行的硬件之間存在抽象。

場景9

考慮一種情況,公司希望向具有各種環境的客户提供所有必需的分發。您認為他們如何以動態的方式實現這一關鍵目標?

解:該公司可以使用 Docker環境,組建一個橫截面團隊,使用 Kubernetes 構建 Web 應用程序。這種框架將幫助公司實現在最短的時間內將所需產品投入生產的目標。因此,在這樣的機器運行的情況下,公司可以向所有具有各種環境的客户發放電子郵件。

場景10

假設公司希望在不同的雲基礎架構上運行各種工作負載,從裸機到公共雲。公司將如何在不同界面的存在下實現這一目標?

解:該公司可以將其基礎設施分解為微服務,然後採用 Kubernetes。這將使公司在不同的雲基礎架構上運行各種工作負載。

多項選擇面試問題

這部分問題將包括多項選擇面試問題,這些問題在面試中經常被問到。

Q1、什麼是 Kubernetes 集羣中的 minions?

  1. 它們是主節點的組件。

  2. 它們是集羣的工作節點。[答案]

  3. 他們正在監控 Kubernetes 中廣泛使用的引擎。

  4. 他們是 Docker 容器服務。

Q2、Kubernetes 集羣數據存儲在以下哪個位置?

  1. KUBE-API服務器

  2. Kubelet

  3. ETCD [答案]

  4. 以上都不是

Q3、哪個是 Kubernetes 控制器?

  1. ReplicaSet

  2. Deployment

  3. Rolling Updates

  4. ReplicaSet和Deployment [答案]

Q4、以下哪個是核心 Kubernetes 對象?

  1. Pods

  2. Services

  3. Volumes

  4. 以上所有[答案]

Q5、Kubernetes Network 代理在哪個節點上運行?

  1. Master Node

  2. Worker Node

  3. 所有節點[答案]

  4. 以上都不是

Q6、節點控制器的職責是什麼?

  1. 將 CIDR 塊分配給節點

  2. 維護節點列表

  3. 監視節點的運行狀況

  4. 以上所有[答案]

Q7、Replication Controller 的職責是什麼?

  1. 使用單個命令更新或刪除多個 Pod

  2. 有助於達到理想狀態

  3. 如果現有 Pod 崩潰,則創建新 Pod

  4. 以上所有[答案]

Q8、如何在沒有選擇器的情況下定義服務?

  1. 指定外部名稱[答案]

  2. 指定具有 IP 地址和端口的端點

  3. 只需指定 IP 地址即可

  4. 指定標籤和 API 版本

Q9、1.8 版本的 Kubernetes 引入了什麼?

  1. Taints and Tolerations [答案]

  2. Cluster level Logging

  3. Secrets

  4. Federated Clusters

Q10、Kubelet 調用的處理檢查容器的 IP 地址是否打開的程序是?

  1. HTTPGetAction

  2. ExecAction

  3. TCPSocketAction [答案]

  4. 以上都不是

譯者注

這篇文章不僅僅適合相關的面試者,也非常推薦 Kubernetes 的初學者或者想要了解 Kubernetes 技術的產品或管理者閲讀。但是這裏面還存在幾點不足,例如覆蓋的內容較淺顯,沒有非常具體的技術點,缺少大規模的經驗和技術點考察等,有機會後面的文章會補充下!

來源:知乎

原文:http://t.cn/Ailr1R3L

譯文:http://t.cn/Ailr1BxT

題圖:來自谷歌圖片搜索

版權:本文版權歸原作者所有

投稿:歡迎投稿,郵箱:[email protected]


你可能還喜歡

點擊下方圖片即可閲讀

淺析從外部訪問 Kubernetes 集羣中應用的幾種方式


https://hk.wxwenku.com/d/201171349