Kubernetes in action的示例分析

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

VM vs Docker

• 運行在容器中的進程實際上像其他進程一樣運行在宿主機操作系統中（不像 VM，進程運行在獨立的操作系統中）。但是容器中的進程仍然與其他進程隔離。

• 虛擬機的主要優點在于它提供了完全的隔離，因為每個 VM 運行在自己的 Linux 內核，然而所有容器運行在同樣的內核，這可能會存在潛在的安全風險。

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

Docker

• Dockerfile 中 ENTRYPOINT vs CMD。

• ENTRYPOINT 的兩種執行方式：shell vs exec。

容器

• 容器技術的基礎，Linux Namespace 和 Linux Control Groups。

• 一個進程并不是屬于一個命名空間，而是屬于一組命名空間。

• 實現進程隔離的并不是 Docker，Docker 只是使這些特性更易用。

• 進程在容器中的 PID 與宿主機中的不同。

Pod

• 包含一個或多個緊密聯系的容器。

• 總是運行在同一個 worker 節點上。

• 屬于同一個 namespace。

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

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

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

• 退出碼的涵義：128+x，x 為發送到進程的信號值。

ReplicaSet

• ReplicaSet 的標簽選擇器更靈活，與 ReplicationController 相比。

DaemonSet

• DaemonSet 會繞過 Scheduler！！！

Service

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

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

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

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

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

Ingress

• LoadBalancer 與 Ingress 的一個區別在于，每個 LoadBalancer 都需要一個外網 IP，而 Ingress 只需要一個。

• Ingress 可以處理應用層的 HTTP 網絡堆棧，故能提供基于 cookie 的會話一致性，而 Service 不能。

• Ingress 直接轉發流量到 Pod，并不經過 Service。

Volumes

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

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

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

kubectl

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

基礎組件

etcd

• etcd 是 Kubernetes 存儲集群狀態和元數據的唯一位置。

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

• ectd 使用了 RAFT 算法實現分布式一致性。

• etcd 的實例數量為什么是奇數？

Scheduler

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

Controller Manager

• Controller Manager 包含多個 Controller。

• Controllers 實現系統的期望狀態。

• Controller Manager （Replication、ReplicaSet、StatefulSet）通過創建新的 Pod 清單，POST 到 API server，并通知 Scheduler 和 Kubelet 實現調度和運行 Pod。

• Namespace controller 實現了刪除 Namespace 資源時，同步刪除 Namespace 中的所有資源。

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

Kubelet

• Kubelet 負責運行在 worker 節點的一切活動。

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

kube-proxy

• kube-proxy 負責將到達 service IP 與 port 的流量轉發到后端的 Pod。

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