node作為集群中的工作節點，執行真正的應用程式，在node上kubernetes管理的最小執行單元是pod。node上執行著kubernetes的kubelet、kube-proxy服務程序，這些服務程序負責pod的建立、啟動、監控、重啟、銷毀、以及實現軟體模式的負載均衡。
node包含的資訊：
node的執行狀態：pending、running、terminated三種狀態。
node condition：…
node系統容量：描述node可用的系統資源，包括cpu、記憶體、最大可排程pod數量等。
其他：核心版本號、kubernetes版本等。
檢視node資訊：
kubectl describe node同乙個pod裡的容器之間僅需通過localhost就能互相通訊。
乙個pod中的應用容器共享同一組資源：
pid命名空間：pod中的不同應用程式可以看到其他應用程式的程序id；
網路命名空間：pod中的多個容器能夠訪問同乙個ip和埠範圍；
ipc命名空間：pod中的多個容器能夠使用systemv ipc或posix訊息佇列進行通訊；
uts命名空間：pod中的多個容器共享乙個主機名；
volumes（共享儲存卷）：pod中的各個容器可以訪問在pod級別定義的volumes；
pod的生命週期通過replication controller來管理；通過模板進行定義，然後分配到乙個node上執行，在pod所包含容器執行結束後，pod結束。
在kubernetes的世界裡，雖然每個pod都會被分配乙個單獨的ip位址，但這個ip位址會隨著pod的銷毀而消失，這就引出乙個問題：如果有一組pod組成乙個集群來提供服務，那麼如何來訪問它呢？service！
乙個service可以看作一組提供相同服務的pod的對外訪問介面，service作用於哪些pod是通過label selector來定義的。
擁有乙個指定的名字（比如my-mysql-server）；
擁有乙個虛擬ip（cluster ip、service ip或vip）和埠號，銷毀之前不會改變，只能內網訪問；
能夠提供某種遠端服務能力；
被對映到了提供這種服務能力的一組容器應用上；
如果service要提供外網服務，需指定公共ip和nodeport，或外部負載均衡器；
系統會在kubernetes集群中的每個node上開啟乙個主機的真實埠，這樣，能夠訪問node的客戶端就能通過這個埠訪問到內部的service了
volume是pod中能夠被多個容器訪問的共享目錄。
label以key/value的形式附加到各種物件上，如pod、service、rc、node等，以識別這些物件，管理關聯關係等，如service和pod的關聯關係。
目標pod的定義；
目標pod需要執行的副本數量；
要監控的目標pod標籤（lable）；
kubernetes通過rc中定義的lable篩選出對應的pod例項，並實時監控其狀態和數量，如果例項數量少於定義的副本數量（replicas），則會根據rc中定義的pod模板來建立乙個新的pod，然後將此pod排程到合適的node上啟動執行，直到pod例項數量達到預定目標。
kubernetes將集群中的機器劃分為乙個master節點和一群工作節點（node）。其中，master節點上執行著集群管理相關的一組程序etcd、api server、controller manager、scheduler，後三個元件構成了kubernetes的總控中心，這些程序實現了整個集群的資源管理、pod排程、彈性伸縮、安全控制、系統監控和糾錯等管理功能，並且全都是自動完成。在每個node上執行kubelet、proxy、docker daemon三個元件，負責對本節點上的pod的生命週期進行管理，以及實現服務**的功能。
通過kubectl提交乙個建立rc的請求，該請求通過api server被寫入etcd中，此時controller manager通過api server的監聽資源變化的介面監聽到這個rc事件，分析之後，發現當前集群中還沒有它所對應的pod例項，於是根據rc裡的pod模板定義生成乙個pod物件，通過api server寫入etcd，接下來，此事件被scheduler發現，它立即執行乙個複雜的排程流程，為這個新pod選定乙個落戶的node，然後通過api server講這一結果寫入到etcd中，隨後，目標node上執行的kubelet程序通過api server監測到這個「新生的」pod，並按照它的定義，啟動該pod並任勞任怨地負責它的下半生，直到pod的生命結束。
隨後，我們通過kubectl提交乙個新的對映到該pod的service的建立請求，controller manager會通過label標籤查詢到相關聯的pod例項，然後生成service的endpoints資訊，並通過api server寫入到etcd中，接下來，所有node上執行的proxy程序通過api server查詢並監聽service物件與其對應的endpoints資訊，建立乙個軟體方式的負載均衡器來實現service訪問到後端pod的流量**功能。
etcd
用於持久化儲存集群中所有的資源物件，如node、service、pod、rc、namespace等；api server提供了操作etcd的封裝介面api，這些api基本上都是集群中資源物件的增刪改查及監聽資源變化的介面。
api server
提供了資源物件的唯一操作入口，其他所有元件都必須通過它提供的api來操作資源資料，通過對相關的資源資料「全量查詢」+「變化監聽」，這些元件可以很「實時」地完成相關的業務功能。
controller manager
集群內部的管理控制中心，其主要目的是實現kubernetes集群的故障檢測和恢復的自動化工作，比如根據rc的定義完成pod的複製或移除，以確保pod例項數符合rc副本的定義；根據service與pod的管理關係，完成服務的endpoints物件的建立和更新；其他諸如node的發現、管理和狀態監控、死亡容器所佔磁碟空間及本地快取的映象檔案的清理等工作也是由controller manager完成的。
scheduler
集群中的排程器，負責pod在集群節點中的排程分配。
kubelet
負責本node節點上的pod的建立、修改、監控、刪除等全生命週期管理，同時kubelet定時「上報」本node的狀態資訊到api server裡。
proxy
實現了service的**與軟體模式的負載均衡器。
客戶端通過kubectl命令列工具或kubectl proxy來訪問kubernetes系統，在kubernetes集群內部的客戶端可以直接使用kuberctl命令管理集群。kubectl proxy是api server的乙個反向**，在kubernetes集群外部的客戶端可以通過kubernetes proxy來訪問api server。
api server內部有一套完備的安全機制，包括認證、授權和准入控制等相關模組。
K8S基礎概念
node作為集群中的工作節點，執行真正的應用程式，在node上kubernetes管理的最小執行單元是pod。node上執行著kubernetes的kubelet kube proxy服務程序，這些服務程序負責pod的建立 啟動 監控 重啟 銷毀 以及實現軟體模式的負載均衡。node包含的資訊 no...
K8S基礎概念
node作為集群中的工作節點，執行真正的應用程式，在node上kubernetes管理的最小執行單元是pod。node上執行著kubernetes的kubelet kube proxy服務程序，這些服務程序負責pod的建立 啟動 監控 重啟 銷毀 以及實現軟體模式的負載均衡。node包含的資訊 no...
K8s基礎概念
最近在做新的系統架構，使用了比較新的容器技術k8s來做一整套分布式系統架構。今天來記錄一下k8s的一些基礎概念。純憑記憶，如有錯誤請指正。網上能看到的就不說了，說一些我理解的。k8s是一套google開源的利用容器技術的分布式及系統解決方案。通過對應用程式的容器化管理，實現服務的自動管理，如部署，多...