Kubernetes === ###### tags: `Orchestration` `pod` `node` :::info 先讚嘆一下 [邱大神](https://www.slideshare.net/hongweiqiu?utm_campaign=profiletracking&utm_medium=sssite&utm_source=ssslideview) 本魯的觀念與新知都來自此大師 ::: :::success 俗稱K8s(k{ubernete共8個}s) ::: # Abstract 1. Kubernetes is an open source system for managing containerized applications across multiple hosts; providing basic mechanisms for deployment, maintenance, and scaling of applications. 2. Kubernetes builds upon a decade and a half of experience at Google running production workloads at scale using a system called Borg, combined with best-of-breed ideas and practices from the community. 3. Kubernetes is hosted by the Cloud Native Computing Foundation (CNCF). If you are a company that wants to help shape the evolution of technologies that are container-packaged, dynamically-scheduled and microservices-oriented, consider joining the CNCF. For details about who's involved and how Kubernetes plays a role, read the CNCF announcement. # Architecture 1. k8s Cluster  * The Kubernetes master runs the Scheduler, Controller Manager, API Server and etcd components and is responsible for managing the Kubernetes cluster. * Master(api-server、etcd、RC、Scheduler)、Node(kubelet、Kube-Proxy)、Pod 2. Master & Node  * [CNI](https://hackmd.mcl.math.ncu.edu.tw/-XBve0P6RSOUHxwcB0DQpQ) * [CRI](https://github.com/kubernetes/kubernetes/blob/242a97307b34076d5d8f5bbeb154fa4d97c9ef1d/docs/devel/container-runtime-interface.md) * [OCI](https://www.imooc.com/article/39491?block_id=tuijian_wz) * [Protobuf](https://yami.io/protobuf/) * [gRPC](https://ithelp.ithome.com.tw/articles/10207405) # [Orchestration(Controller/Master)](https://medium.com/jorgeacetozi/kubernetes-master-components-etcd-api-server-controller-manager-and-scheduler-3a0179fc8186) ## UML:  :::success 1. kubectl writes to the API Server. 2. API Server validates the request and persists it to etcd. 3. etcd notifies back the API Server. 4. API Server invokes the Scheduler. 5. Scheduler decides where to run the pod on and return that to the API Server. 6. API Server persists it to etcd. 7. etcd notifies back the API Server. 8. API Server invokes the Kubelet in the corresponding node. 9. Kubelet talks to the Docker daemon using the API over the Docker socket to create the container. 10. Kubelet updates the pod status to the API Server. 11. API Server persists the new state in etcd. ::: * 只有API-Server會負責與etcd還有Scheduler等model交互作用，API-Server提供了資源對象唯一操作的入口，所有的模組必須通過他所提供的API來操作 他提供各類資源對象(Pod,RC,Service)的增刪改查及watch等HTTP Rest接口，是整個系統的中心。 :::warning The API Server is the only Kubernetes component that connects to etcd; all the other components must go through the API Server to work with the cluster state. ::: ## API-Server ### Synopsis * When you interact with your Kubernetes cluster using the kubectl command-line interface, you are actually communicating with the master API Server component. * API-Server的默認端口為Master的6443 Port * API-Server提供的驗證與授權保證整個群集的安全 * The API Server also implements a watch mechanism (similar to etcd) for clients to watch for changes. This allows components such as the Scheduler and Controller Manager to interact with the API Server in a loosely coupled manner. ## Etcd ### Synopsis * Etcd是被API-Server用來存放key還有認證的地方，他會紀錄所有pod在cluster內的狀態ex:此pod是存在在哪個node還有這些node是否存活。 :::warning 所有Cluster的data都是存在etcd，所以可能會有需要備援的情況， ::: * etcd是由Go還有[Raft演算法](https://zh.wikipedia.org/wiki/Raft)去管理高可用的replicated log. ## Controller Manager ### Synopsis * Kubernetes Controller Manager是一個[daemon](https://zh.wikipedia.org/wiki/DAEMON_Tools)也是在K8s核心的control loop。 * 一般來說controller會透過API-Server去查看cluster的狀態，並企圖依據現行設計的狀態去做一些必要的改變ex:有pod死掉要回復、pod要求要減少、pod要求要增加。 ## Scheduler ### Synopsis * Scheduler會找到未佈署的pod並將他們通過/binding pod subresource API去bind到仍有足夠資源的node上，一旦node接受那就會激發Kubelet 並創建pod與他的container :::info [Kubernetes Master Components: Etcd, API Server, Controller Manager, and Scheduler](https://medium.com/jorgeacetozi/kubernetes-master-components-etcd-api-server-controller-manager-and-scheduler-3a0179fc8186) ::: # [Node Components](https://www.jorgeacetozi.com/single-post/kubernetes-node-components-service-proxy-kubelet-and-cadvisor) 基本上kubernetes的node會跑兩個重要的components: * Kubelet * Service Proxy * Basically, the Kubernetes node runs the Kubelet and Service Proxy components as well as a container engine such as Docker or Rocket, which in turns run your containerized applications ## Service Proxy  ### Synopsis * 每個node上都會有一個Service Proxy主要負責去維護還有幫api-server在service還有pod上要做一些改變時去看整個網路的配置 確保每個pod能夠與其他的pod做溝通 他暴露kubernetes的service還有依據iptable的rule去跳到應對service在重新導向到正確的位置 這提供了HA的load balancing * 有兩種角色會透過 Service 存取其他的 Pod，分別是 Kubernetes 集群外部使用者以及集群內部其他 Pod。儘管兩種路徑的結果都相同，但之間仍存在一個關鍵差異在於: 存取 IP 不同。   * 實際上在 Kubernetes 內共有三種 IP 存在 - External IP: 裸露的網路位址，供外部使用者連線 - Cluster IP: 叢集內部的網路位址，在 Cluster 內的 Pod 可以透過此位址存取該服務 - Pod IP: 每個 Pod 獨有的網路位址，只有叢集內可連線 * 三者關係  * 路徑 1 -> 2: 外部使用者連線到時的 destination 為 External IP，當使用者請求送到 Service 時會經由 iptables NAT 將 destination 替換成 Pod IP。 * 路徑 3 -> 2: 內部 Pod存取服務時的 destination 為 Cluster IP，當使用者請求送到 Service 時會經由 iptables NAT 將 destination 替換成 Pod IP。 :::warning * Q:Pod 之間是否能夠直接使用彼此 IP 溝通，而無需 Service 存在？ * A:可以，但不建議這種作法。Kubernetes Service 用意在於將背後實際運作的細節隱藏、抽象化，讓開發者在撰寫程式時只需透過該服務的 DNS 便能查詢到該服務的 Cluster IP，如此不僅能降低程式複雜度，也可以確保運作過程中能正常存取服務，意即確保大部分情況下的服務高可用性。 * 在少數情況下 (比如說 AKKA Cluster) 的確需要讓 Pod 可以知道彼此位址，仍然建議透過 Service 取得 Pod IP (非 Cluster IP)。只要在設定 Service 時指定 clusterIP: None，DNS 查詢時 Kubernetes DNS 會找出正在運作 Pod 並將回傳其 IP 位址。如此一來，即便該 Pod 意外重啟、刪除，仍然有辦法透過 Service 找到新的對口 Pod 存取服務。 ::: * 解法1: Sidecar Container 優點: 延遲低 (同個 Pod 內的容器都處在同個 network namespace 及運算節點上) 未來擴展性較佳 缺點: 根據不同應用情境，必須適當修改整體系統架構，建議農閒期間進行(?) 解法2: DNS Load Balancing 透過新增多筆 DNS A record 指向到多群 Kubernetes，避免單一叢集過多運算節點。 * 解法2: DNS Load Balancing 優點: 立竿見影 (新增 DNS 紀錄即可) 缺點: Operation 負擔大，需要同時處理兩個叢集的資訊同步 (Kubernetes Federation 穩定後可能會有所改善) :::info - [Kubernetes Service 深度剖析 - 存取路徑差異](https://tachingchen.com/tw/blog/kubernetes-service-in-detail-1/) ::: ## Kubelet ### Synopis * Kubelet負責每個節點的運行狀態（即確保節點上的所有容器都正常運行）。它按照控制面板的指示來處理啟動，停止和維護應用程式容器（按組織到pod中） * Kubelet會監視pod的狀態，如果不處於所需狀態，則pod將被重新部署到同一個節點。節點狀態每隔幾秒就會傳遞消息至中繼主機。主控器檢測到節點故障後，複製控制器將觀察此狀態更改，並在其他健康節點上啟動pod :::info [Kubernetes Node Components](https://www.jorgeacetozi.com/single-post/kubernetes-node-components-service-proxy-kubelet-and-cadvisor) ::: ## [cAdvisor](https://www.google.com/search?q=cadvisor&oq=cAdvi&aqs=chrome.2.69i57j69i60j0l4.6318j0j1&sourceid=chrome&ie=UTF-8) ### Synopis * The Kubelet ships with built-in support for cAdvisor, which collects, aggregates, processes and exports metrics (such as CPU, memory, file and network usage) about running containers on a given node. * Advisor includes a built-in web interface available on port 4194 (just open your browser and navigate to http://<node-ip>:4194/). * 簡而言之就是Google自行開發的資源監控器 # [Pod](https://tachingchen.com/tw/blog/kubernetes-pod/) * 在 Kubernetes 中最小的部署單位 Pod 係由一至多個容器所組成，而在一般應用層面上由於下述幾點原因，使其較接近於一般使用的VM - 共享同樣的 IP 位址及 Port space - 共享儲存空間 (volumes) - 耦合性較高之應用 * 共享同樣的 IP 位址及 Port space - 相較於 Docker 中每個容器會擁有各自獨立的 IP，Kubernetes 則是每個在 Pod 內的容器會共享同樣的 IP address 以及 Port space。最直接的好處就是同個 Pod 內的容器可以透過 localhost 來互相溝通。這點和我們在使用一般虛擬機是相同的情況: one prcoess find others with localhost:port - 由於擁有各自 IP 位址，因此每個位處於同樣 Kubernetes 集群內的 Pod 可以直接透過該 IP 和其他 Pod 進行聯繫，但一般而言我們會透過 service 來取代直接 Pod 存取，這其中表明一件很重要的事情: 在 Cloud 環境中有人做比起誰做來得重要。 * 共享儲存空間 (volumes) - Kubernetes 支援許多不同種類的 Volumes，舉例來說 emptyDir 會在 Pod 建立時一併建立起來、Pod 結束時刪除，Pod 內的容器可以自由儲存所有放在該 volume 內的檔案。 - 試想當我們同時執行一個應用程式以及一個 Log parser 在同個 Pod 內時，應用程式只要把生成的日誌放置到 volume 內，然後由 Log parser 來讀取並監控異常狀況，達到分工的效果。由於兩者的容器映像檔是完全獨立的，因此在大型團隊進行開發時，在格式保持相同的狀況下，兩個映像檔可以獨立升級而不必影響彼此，讓團隊能夠專心在各自的業務範圍內全速衝刺。 * 一般來說會建立一個含有兩個容器: backend、frontend 的 pod - 可以將image還有一個DataBase包成一個Docker在部署 # [kube-DNS](https://www.hwchiu.com/kubernetes-dns.html) # feature: [How to use Open Virtual Networking with Kubernetes](https://github.com/openvswitch/ovn-kubernetes)