Kubernetes in action的示例分析

這篇文章主要為大家展示了“Kubernetes in action的示例分析”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“Kubernetes in action的示例分析”這篇文章吧。

VM vs Docker

• 運(yùn)行在容器中的進(jìn)程實際上像其他進(jìn)程一樣運(yùn)行在宿主機(jī)操作系統(tǒng)中（不像 VM，進(jìn)程運(yùn)行在獨立的操作系統(tǒng)中）。但是容器中的進(jìn)程仍然與其他進(jìn)程隔離。

• 虛擬機(jī)的主要優(yōu)點在于它提供了完全的隔離，因為每個 VM 運(yùn)行在自己的 Linux 內(nèi)核，然而所有容器運(yùn)行在同樣的內(nèi)核，這可能會存在潛在的安全風(fēng)險。

• 基于 Docker 的容器鏡像與 VM 鏡像的一個顯著區(qū)別：容器鏡像是分層的，可以由多個鏡像共享和重用。

Docker

• Dockerfile 中 ENTRYPOINT vs CMD。

• ENTRYPOINT 的兩種執(zhí)行方式：shell vs exec。

容器

• 容器技術(shù)的基礎(chǔ)，Linux Namespace 和 Linux Control Groups。

• 一個進(jìn)程并不是屬于一個命名空間，而是屬于一組命名空間。

• 實現(xiàn)進(jìn)程隔離的并不是 Docker，Docker 只是使這些特性更易用。

• 進(jìn)程在容器中的 PID 與宿主機(jī)中的不同。

Pod

• 包含一個或多個緊密聯(lián)系的容器。

• 總是運(yùn)行在同一個 worker 節(jié)點上。

• 屬于同一個 namespace。

• 為什么需要 Pod？為什么不能直接使用容器？為什么需要運(yùn)行多個容器？為什么不能將所有進(jìn)程放在同一個容器中？

• 注解也是引入新特性的一種過渡手段。

• Pod 的終止過程：SIGTERM，等待 30s，SIGKILL。

• 退出碼的涵義：128+x，x 為發(fā)送到進(jìn)程的信號值。

ReplicaSet

• ReplicaSet 的標(biāo)簽選擇器更靈活，與 ReplicationController 相比。

DaemonSet

• DaemonSet 會繞過 Scheduler?。。?/p>

Service

• 使用一個不變的 IP 和 Port 來暴露多個不斷變化 IP 的 Pod。

• 會話一致性，Kubernetes 只支持基于 ClientIP，不支持基于 Cookie。

• 你不能 ping 一個 Service IP，因為它是一個虛擬 IP，只有和 Port 一起使用才有效。

• ExternalName 類型經(jīng)常被忽略，實際上它只是一個 CNAME。

• LoadBalancer 是 NodePort 類型的擴(kuò)展，如果不支持 LoadBalancer 仍然會開啟 NodePort 類型。

Ingress

• LoadBalancer 與 Ingress 的一個區(qū)別在于，每個 LoadBalancer 都需要一個外網(wǎng) IP，而 Ingress 只需要一個。

• Ingress 可以處理應(yīng)用層的 HTTP 網(wǎng)絡(luò)堆棧，故能提供基于 cookie 的會話一致性，而 Service 不能。

• Ingress 直接轉(zhuǎn)發(fā)流量到 Pod，并不經(jīng)過 Service。

Volumes

• volumes 是 Pod 的一部分，并非 Kubernetes 頂級資源。

• emptyDir 是用于 Pod 中多個容器共享文件的一種臨時磁盤。

• hostPath 類型的常見場景是收集 node 節(jié)點的日志。

kubectl

• 雙短線（--）表示命令的結(jié)束，防止后面命令的參數(shù)無效。

基礎(chǔ)組件

etcd

• etcd 是 Kubernetes 存儲集群狀態(tài)和元數(shù)據(jù)的唯一位置。

• Kubernetes API server 是與 etcd 直接交互的唯一組件。

• ectd 使用了 RAFT 算法實現(xiàn)分布式一致性。

• etcd 的實例數(shù)量為什么是奇數(shù)？

Scheduler

• Scheduler 并不負(fù)責(zé)指定選定的 node 去運(yùn)行 Pod，而是通過 API server 更新 Pod 定義并存儲在 etcd 中，API server 來通知 Kubelet 運(yùn)行 Pod。

Controller Manager

• Controller Manager 包含多個 Controller。

• Controllers 實現(xiàn)系統(tǒng)的期望狀態(tài)。

• Controller Manager （Replication、ReplicaSet、StatefulSet）通過創(chuàng)建新的 Pod 清單，POST 到 API server，并通知 Scheduler 和 Kubelet 實現(xiàn)調(diào)度和運(yùn)行 Pod。

• Namespace controller 實現(xiàn)了刪除 Namespace 資源時，同步刪除 Namespace 中的所有資源。

• 所有的 Contoller 通過 API server 實現(xiàn)操作，并不直接與 Kubelet 或其他組件交流。

Kubelet

• Kubelet 負(fù)責(zé)運(yùn)行在 worker 節(jié)點的一切活動。

• Kubelet 既可以從 Kubernetes API server 獲取 Pod 清單，也可以從指定的本地目錄獲取 Pod 清單（用于運(yùn)行控制平面的組件）來運(yùn)行 Pod。

kube-proxy

• kube-proxy 負(fù)責(zé)將到達(dá) service IP 與 port 的流量轉(zhuǎn)發(fā)到后端的 Pod。

以上是“Kubernetes in action的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注億速云行業(yè)資訊頻道！