容器化和Docker相關(guān)的問題
選擇題
- Docker命令的參數(shù)中，哪個是指定容器環(huán)境變量的參數(shù)？
A：-t
*B：-e
C：-i
D：-v - Docker下列哪個不是Docker技術(shù)實現(xiàn)的基礎(chǔ)
A：UnionFS
B：Cgroup
C：Namespace
*D：etcd
問答題
- 簡單說一下你對docker的理解/優(yōu)點
（這是一道開放性題目，可以一次性挖出面試者對于docker的理解，然后針對他所了解的部分進行深挖，然后針對沒有涉及的問題進行橫向擴展）
Docker是一個開源的應(yīng)用容器引擎，是容器虛擬化的一種實現(xiàn)方式，他是基于庫的虛擬化，讓開發(fā)/運維人員把程序所需要的依賴全部打包在一個鏡像中，具有一次打包，到處運行的特點，體積小且啟動快
- Dockerfile中的RUN, CMD和ENTRYPOINT的區(qū)別
RUN命令執(zhí)行命令并創(chuàng)建新的鏡像層，通常用于安裝軟件包
CMD命令設(shè)置容器啟動后默認執(zhí)行的命令及其參數(shù)，但CMD設(shè)置的命令能夠被docker run命令后面的命令行參數(shù)替換
ENTRYPOINT配置容器啟動時的執(zhí)行命令（不會被忽略，一定會被執(zhí)行，即使運行 docker run時指定了其他命令）
- 簡述Docker技術(shù)三大要點:cgroup, namespace和unionFS實現(xiàn)方式
-- cgroup：Linux CGroupCgroup 可???讓???您???為???系???統(tǒng)???中???所???運???行???任???務(wù)???（進???程???）的???用???戶???定???義???組???群???分???配???資???源??? — 比???如??? CPU 時???間???、???系???統(tǒng)???內(nèi)???存???、???網(wǎng)???絡(luò)???帶???寬???或???者???這???些???資???源???的???組???合???。???您???可???以???監(jiān)???控???您???配???置???的??? cgroup，拒???絕??? cgroup 訪???問???某???些???資???源???，甚???至???在???運???行???的???系???統(tǒng)???中???動???態(tài)???配???置???您???的??? cgroup
-- namespace：
PID NameSpace：Linux 2.6.24 ，PID隔離
Network NameSpace：Linux 2.6.29，網(wǎng)絡(luò)設(shè)備、網(wǎng)絡(luò)棧、端口等網(wǎng)絡(luò)資源隔離
User NameSpace：Linux 3.8，用戶和用戶組資源隔離
IPC NameSpace：Linux 2.6.19，信號量、消息隊列和共享內(nèi)存的隔離
UTS NameSpace：Linux 2.6.19，主機名和域名的隔離；
Mount NameSpace：Linux 2.4.19，掛載點（文件系統(tǒng)）隔離；
-- AUFS：
UnionFS：把不同的物理位置的目錄合并到同一個目錄中。
Device mapper/OverlayFS：由于Redhat并不原生支持AUFS，但是為了適應(yīng)Docker技術(shù)，在RHEL6中引進的文件系統(tǒng)，也可以使用OverlayFS，但是需要額外的配置
-
在主機和容器上部署應(yīng)用程序有什么區(qū)別？
image.png
請參考上圖。左側(cè)架構(gòu)表示在主機上部署應(yīng)用程序。因此，這種架構(gòu)將具有操作系統(tǒng)，然后操作系統(tǒng)將具有內(nèi)核，該內(nèi)核將在應(yīng)用程序所需的操作系統(tǒng)上安裝各種庫。因此，在這種框架中，您可以擁有n個應(yīng)用程序，并且所有應(yīng)用程序?qū)⒐蚕碓摬僮飨到y(tǒng)中存在的庫，而在容器中部署應(yīng)用程序時，體系結(jié)構(gòu)則略有不同。
這種架構(gòu)將有一個內(nèi)核，這是唯一一個在所有應(yīng)用程序之間唯一共同的東西。因此，如果有一個需要Java的特定應(yīng)用程序，那么我們將獲得訪問Java的特定應(yīng)用程序，如果有另一個需要Python的應(yīng)用程序，則只有該特定應(yīng)用程序才能訪問Python。
您可以在圖表右側(cè)看到的各個塊基本上是容器化的，并且這些塊與其他應(yīng)用程序隔離。因此，應(yīng)用程序具有與系統(tǒng)其余部分隔離的必要庫和二進制文件，并且不能被任何其他應(yīng)用程序侵占。
Kubernetes基本面試問題
選擇題
- Kubernetes集群數(shù)據(jù)存儲在以下哪個位置？
A. kube-apiserver
B. Kubelet
*C. etcd
D. promethues - 哪個是Kubernetes的Pod控制器?
*A. ReplicaSet
*B. Deployment
C. kube-controller-manager
D. Service - 以下哪個是核心Kubernetes對象？
*A. Pods
*B. Services
*C. Volumes
D. ReplicaSet - Kubernetes Network代理在哪個節(jié)點上運行？
A. Master Node
B. Worker Node
*C. 所有節(jié)點
D. 以上都不是 - Controller-Manager的職責(zé)是什么？
*A. 將CIDR塊分配給節(jié)點
*B. 維護節(jié)點列表
*C. 監(jiān)視節(jié)點的運行狀況
D. 監(jiān)控文件大小 - Replication Controller的職責(zé)是什么？
*A. 使用單個命令更新或刪除多個pod
*B. 有助于達到理想狀態(tài)
*C. 如果現(xiàn)有Pod崩潰，則創(chuàng)建新Pod
D. 維護節(jié)點列表 - 如何在沒有選擇器的情況下定義服務(wù)？
*A. 指定外部名稱
B. 指定具有IP地址和端口的端點
C. 只需指定IP地址即可
D. 指定標簽和api版本
問答題
- 簡單說一下你對Kubernetes的了解
Kubernetes是一個開源容器管理工具，負責(zé)容器部署，容器擴縮容以及負載平衡。作為Google的創(chuàng)意之作，它提供了出色的社區(qū)，并與所有云提供商合作（如果可以說的CNCF的話證明經(jīng)常關(guān)注社區(qū)）。因此，我們可以說Kubernetes不是一個容器化平臺，而是一個多容器管理解決方案。
-
Kubernetes的基本組成以及他們的作用，組件之間是如何交互的
image.png
Master
-- kube-apiserver：Api Server 是唯一可以操作etcd 數(shù)據(jù)庫的組件，并提供了認證、授權(quán)等機制。它嚴格遵守了REST規(guī)范，去操作這些資源，具有CRUD特性。它是Kubernetes控制的前端工程，它能夠水平擴展，可以通過部署多個實例來達到高可用的目的。
-- kube-scheduler：通過API Server的watch接口監(jiān)聽新建Pod副本信息，并通過算法為該pod選擇一個合適的node。調(diào)度器可用選擇合適的策略，策略的考慮包括個人和集體資源的情況，軟件、硬件條件的影響，親和性和反親和性的規(guī)范等因素。調(diào)度器是可插拔的，并且我們期待支持多集群的調(diào)度，未來甚至希望可以支持用戶自定義的調(diào)度器。
-- kube-controller-manager：集群內(nèi)各種資源controller 的核心管理者。針對于每一種具體的資源，都有相應(yīng)的Controller，保證其下管理的每個Controller所對應(yīng)的資源始終處于“期望的狀態(tài)”。從邏輯上講，每個控制器都是一個單獨的過程，但為了降低復(fù)雜性，它們都被編譯成單個二進制文件并在單個進程中運行。
--- etcd：用于存儲集群中所有對象產(chǎn)生的數(shù)據(jù)。etcd是Coreos開源的（Apache 2.0協(xié)議）一個分布式鍵值存儲數(shù)據(jù)庫，它提供了一種在一組機器上存儲數(shù)據(jù)的可靠方法。 etcd采用了master-slave架構(gòu)，在網(wǎng)絡(luò)分區(qū)期間優(yōu)雅地處理Leader選舉，并且可以容忍機器故障，包括Leader。
Worker
-- kubelet：用于和Master節(jié)點交互，運行了node上的Service進程
它位于集群中每個 node上非容器形式的服務(wù)進程組件，是Master和node之間的橋梁。處理Master下發(fā)到本Node上的pod創(chuàng)建、啟停等管理任務(wù)，向API server注冊Node信息。監(jiān)控本Node上容器和節(jié)點資源情況，并定期向Master匯報節(jié)點資源占用情況。它還會向Master匯報容器運行的健康情況。
-- kube-proxy：Service抽象概念的實現(xiàn)，將到service的請求按策略（負載均衡算法分發(fā)到后端的pod ）上，默認使用iptables mode實現(xiàn)；支持nodeport模式，實現(xiàn)從外部訪問集群內(nèi)的service。
- k8s的pause容器有什么用
Pause容器，又叫Infra容器。在pod中擔(dān)任Linux命名空間共享的基礎(chǔ)。
PID命名空間：Pod中的不同應(yīng)用程序可以看到其他應(yīng)用程序的進程ID。
網(wǎng)絡(luò)命名空間：Pod中的多個容器能夠訪問同一個IP和端口范圍。
IPC命名空間：Pod中的多個容器能夠使用SystemV IPC或POSIX消息隊列進行通信。
UTS命名空間：Pod中的多個容器共享一個主機名；Volumes（共享存儲卷）：
Pod中的各個容器可以訪問在Pod級別定義的Volumes。
一個pod的創(chuàng)建過程
Pod是Kubernetes的基礎(chǔ)單元，了解其創(chuàng)建的過程，更有助于理解系統(tǒng)的運作。
①用戶通過kubectl或其他API客戶端提交Pod Spec給API Server。
②API Server嘗試將Pod對象的相關(guān)信息存儲到etcd中，等待寫入操作完成，API Server返回確認信息到客戶端。
③API Server開始反映etcd中的狀態(tài)變化。
④所有的Kubernetes組件通過"watch"機制跟蹤檢查API Server上的相關(guān)信息變動。
⑤kube-scheduler（調(diào)度器）通過其"watcher"檢測到API Server創(chuàng)建了新的Pod對象但是沒有綁定到任何工作節(jié)點。
⑥kube-scheduler為Pod對象挑選一個工作節(jié)點并將結(jié)果信息更新到API Server。
⑦調(diào)度結(jié)果新消息由API Server更新到etcd，并且API Server也開始反饋該Pod對象的調(diào)度結(jié)果。
⑧Pod被調(diào)度到目標工作節(jié)點上的kubelet嘗試在當前節(jié)點上調(diào)用docker engine進行啟動容器，并將容器的狀態(tài)結(jié)果返回到API Server。
⑨API Server將Pod信息存儲到etcd系統(tǒng)中。
⑩在etcd確認寫入操作完成，API Server將確認信息發(fā)送到相關(guān)的kubelet。詳述kube-proxy原理，一個請求是如何經(jīng)過層層轉(zhuǎn)發(fā)落到某個pod上的整個過程。請求可能來自pod也可能來自外部。
kube-proxy其實就是管理service的訪問入口，包括集群內(nèi)Pod到Service的訪問和集群外訪問service。 kube-proxy管理sevice的Endpoints，該service對外暴露一個Virtual IP，也成為Cluster IP, 集群內(nèi)通過訪問這個Cluster IP:Port就能訪問到集群內(nèi)對應(yīng)的serivce下的Pod。 service是通過Selector選擇的一組Pods的服務(wù)抽象，其實就是一個微服務(wù)，提供了服務(wù)的LB和反向代理的能力，而kube-proxy的主要作用就是負責(zé)service的實現(xiàn)。 service另外一個重要作用是，一個服務(wù)后端的Pods可能會隨著生存滅亡而發(fā)生IP的改變，service的出現(xiàn)，給服務(wù)提供了一個固定的IP，而無視后端Endpoint的變化。
kube-proxy當前實現(xiàn)了兩種proxyMode：userspace和iptables。其中userspace mode是v1.0及之前版本的默認模式，從v1.1版本中開始增加了iptables mode，在v1.2版本中正式替代userspace模式成為默認模式。最新版本中iptables已經(jīng)改成了LVS。
一個最小的可以運行容器的K8S平臺應(yīng)該包含哪些組件
除了Master和Worker節(jié)點上運行的組件之外還需要安裝下面的組件才可以正常部署容器
-- CNI（網(wǎng)絡(luò)方案calico、flannel、canel、weaver）
-- DNS（CoreDNS、dnsmasq）-
什么是Ingress網(wǎng)絡(luò)，它是如何工作的？
Ingress網(wǎng)絡(luò)是一組規(guī)則，充當Kubernetes集群的入口點。這允許入站連接，可以將其配置為通過可訪問的URL，負載平衡流量或通過提供基于名稱的虛擬主機從外部提供服務(wù)。因此，Ingress是一個API對象，通常通過HTTP管理集群中服務(wù)的外部訪問，是暴露服務(wù)的最有效方式。
現(xiàn)在，讓我以一個例子向您解釋Ingress網(wǎng)絡(luò)的工作。
有2個節(jié)點具有帶有Linux橋接器的pod和根網(wǎng)絡(luò)命名空間。除此之外，還有一個名為flannel0（網(wǎng)絡(luò)插件）的新虛擬以太網(wǎng)設(shè)備被添加到根網(wǎng)絡(luò)中。
現(xiàn)在，假設(shè)我們希望數(shù)據(jù)包從pod1流向pod 4.請參閱下圖。
image.png
因此，數(shù)據(jù)包將pod1的網(wǎng)絡(luò)保留在eth0，并進入veth0的根網(wǎng)絡(luò)。
然后它被傳遞給cbr0，這使得ARP請求找到目的地，并且發(fā)現(xiàn)該節(jié)點上沒有人具有目的地IP地址。
因此，橋接器將數(shù)據(jù)包發(fā)送到flannel0，因為節(jié)點的路由表配置了flannel0。
現(xiàn)在，flannel守護程序與Kubernetes的API服務(wù)器通信，以了解所有pod IP及其各自的節(jié)點，以創(chuàng)建pods IP到節(jié)點IP的映射。
網(wǎng)絡(luò)插件將此數(shù)據(jù)包封裝在UDP數(shù)據(jù)包中，其中額外的標頭將源和目標IP更改為各自的節(jié)點，并通過eth0發(fā)送此數(shù)據(jù)包。
現(xiàn)在，由于路由表已經(jīng)知道如何在節(jié)點之間路由流量，因此它將數(shù)據(jù)包發(fā)送到目標節(jié)點2。
數(shù)據(jù)包到達node2的eth0并返回到flannel0以解封裝并在根網(wǎng)絡(luò)命名空間中將其發(fā)回。
同樣，數(shù)據(jù)包被轉(zhuǎn)發(fā)到Linux網(wǎng)橋以發(fā)出ARP請求以找出屬于veth1的IP。
數(shù)據(jù)包最終穿過根網(wǎng)絡(luò)并到達目標Pod4。 Replica Set 和 Replication Controller之間有什么區(qū)別？
Replica Set 和 Replication Controller幾乎完全相同。它們都確保在任何給定時間運行指定數(shù)量的pod副本。不同之處在于復(fù)制pod使用的選擇器。Replica Set使用基于集合的選擇器，而Replication Controller使用基于權(quán)限的選擇器。
-- Equity-Based選擇器：這種類型的選擇器允許按標簽鍵和值進行過濾。因此，在外行術(shù)語中，基于Equity的選擇器將僅查找與標簽具有完全相同短語的pod。 示例：假設(shè)您的標簽鍵表示app = nginx，那么，使用此選擇器，您只能查找標簽應(yīng)用程序等于nginx的那些pod。
-- Selector-Based選擇器：此類型的選擇器允許根據(jù)一組值過濾鍵。因此，換句話說，基于Selector的選擇器將查找已在集合中提及其標簽的pod。 示例：假設(shè)您的標簽鍵在（nginx，NPS，Apache）中顯示應(yīng)用程序。然后，使用此選擇器，如果您的應(yīng)用程序等于任何nginx，NPS或Apache，則選擇器將其視為真實結(jié)果。
基礎(chǔ)產(chǎn)品的面試問題
除了Kubernetes，你還知道哪些容器編排工具，說說他們的優(yōu)缺點。
Kubernetes與Docker Swarm的區(qū)別
你還了解哪些Devops相關(guān)的產(chǎn)品。
Devops產(chǎn)品：Openshift，AWS EKS
CI產(chǎn)品：Jenkins，rundeck
CD產(chǎn)品：Spinnaker，JenkinsX
Docker倉庫：Vmware Harbor
GIT倉庫：GitLab，BitBucket
Agile工具：JIRA
自動化工具：ansible，chef，puppet
