一 K8s簡介

Kubernetes是谷歌嚴格保密十幾年的祕密武器——Borg的一個開源版本，是一個全新的基於容器技術的分佈式架構領先方案。
Borg是谷歌內部使用的大規模集羣管理系統，基於容器技術，目的是實現資源管理的自動化，以及跨多個數據中心的資源利用率的最大化；
K8s是第一個將”一切以服務爲中心，一切圍繞服務運轉”作爲指導思想的創新型產品
K8s是Go語言開發，是Docker的上層架構，就好像Java與J2EE的關係一樣
K8s是一個開放的開發平臺，不侷限於任何語言

二 K8s功能簡介

k8s能方便地管理跨機器運行容器化的應用
提供應用部署、維護、擴展機制
集羣管理、安全防護、准入機制、多應用支撐、服務註冊、服務發現、智能負載均衡、故障發現、自我修復、服務滾動升級、在線擴容、資源配額管理
使用Docker對應用程序包裝、實例化、運行
以集羣的方式運行、管理跨機器的容器
解決Docker跨機器容器之間的通訊問題
k8s的自我修復機制使得容器集羣總是運行在用戶期望的狀態

三爲什麼使用k8s

K8s不僅僅支持Docker，還支持Rocket，這是另一種容器技術。
全面擁抱微服務架構
使用k8s我們系統可以隨時的整體遷移
k8s系統具備了超強的橫向擴容能力
k8s提供完善的管理工具，涵蓋了包括開發、部署測試、運維監控在內的各個環節

四 k8s集羣

4.1 k8s集羣

4.2 k8s架構圖

4.3 體系結構

1. 1. master

集羣控制管理節點，所有的命令都經由master處理,負責整個集羣的管理和控制，基本上Kubernetes所有的控制命令都是發給它，它來負責具體的執行過程，我們後面所有執行的命令基本都是在Master節點上運行的

Kubernetes API Server（kube-apiserver），提供Http Rest接口的關鍵服務進程，是Kubernetes裏所有資源的增、刪、改、查等操作的唯一入口，也是集羣控制的入口進程
Kubernetes Controller Manager（kube-controller-manager），Kubernetes裏所有資源對象的自動化控制中心，可以理解爲資源對象的“大總管”
Kubernetes Scheduler（kube-scheduler），負責資源調度（Pod調度）的進程，相當於公交公司的“調度室”
etcd Server，Kubernetes裏所有的資源對象的數據全部是保存在etcd中,(集羣部署，不與master放同一臺機器)

4.3.1.5 etcd

etcd是一個高可用的鍵值存儲系統，主要用於共享配置和服務發現。對比與ZooKeeper，etcd更輕量級。

etcd是由CoreOS開發並維護的，靈感來自於 ZooKeeper 和 Doozer，提供了與ZooKeeper相似的功能，它使用Go語言編寫，並通過Raft一致性算法處理日誌複製以保證強一致性。Raft是一個新的一致性算法，適用於分佈式系統的日誌複製，Raft通過選舉的方式來實現一致性。Google的容器集羣管理系統Kubernetes、開源PaaS平臺Cloud Foundry和CoreOS的Fleet都廣泛使用了etcd。在分佈式系統中，如何管理節點間的狀態一直是一個難題，etcd像是專門爲集羣環境的服務發現和註冊而設計，它提供了數據TTL失效、數據改變監視、多值、目錄監聽、分佈式鎖原子操作等功能，可以方便的跟蹤並管理集羣節點的狀態

特點

簡單: 支持curl方式的用戶API（HTTP+JSON）
安全: 可選的SSL客戶端證書認證
快速: 單實例每秒 1000 次讀寫能力
可靠: 使用Raft保證強一致性
Etcd的應用場景包括服務發現（Service Discovery）、消息發佈與訂閱、負載均衡、分佈式通知與協調、分佈式鎖、分佈式隊列。如果你熟悉ZooKeeper, 你會發現etcd實現了ZooKeeper的功能

1. 1. Node

除了Master，Kubernetes集羣中的其他機器被稱爲Node節點，早期版本也稱爲Minion節點

Node節點纔是Kubernetes集羣中的工作負載節點，每個Node都會被Master分配一些工作負載（Docker容器），當某個Node宕機，其上的工作負載會被Master自動轉移到其他節點上去

Kubelet

kubelet，負責Pod對應的容器的創建、啓停等任務，同時與Master節點密切協作，實現集羣管理的基本功能。一旦Node被納入集羣管理範圍，kubelet進程就會向Master彙報自身的情報，這樣Master可以獲知每個Node的資源使用情況，並實現高效均衡的資源調度策略。而某個Node超過指定時間不上報信息，會被Master判定爲“失聯”，Node狀態被標記爲不可用（Not Ready），隨後Master會觸發“工作負載大轉移”的自動流程；

kube-proxy

實現Kubernetes Service的通信與負載均衡機制的重要組件；

Docker Engine（docker）

Docker引擎，負責本機的容器創建和管理工作；

4.2.3.4 pod

Pod是最小部署單元，一個Pod由一個或多個容器組成，Pod中容器共享存儲和網絡，在同一臺Docker主機上運行。同一個Pod裏的容器共享同一個網絡命名空間，可以使用localhost互相通信　　　　　　　　　　　　　　　　　　　　

每個Pod都有一個特殊的被稱爲“根容器”的Pause容器，還包含一個或多個緊密相關的用戶業務容器；
一個Pod裏的容器與另外主機上的Pod容器能夠直接通信；
如果Pod所在的Node宕機，會將這個Node上的所有Pod重新調度到其他節點上；
普通Pod及靜態Pod，前者存放在etcd中，後者存放在具體Node上的一個具體文件中，並且只能在此Node上啓動運行；
Docker Volume對應Kubernetes中的Pod Volume；
每個Pod可以設置限額的計算機資源有CPU和Memory；

　　　　Requests，資源的最小申請量；

　　　　Limits，資源最大允許使用的量；

Service

Service一個應用服務抽象，定義了Pod邏輯集合和訪問這個Pod集合的策略。
Service代理Pod集合對外表現是爲一個訪問入口，分配一個集羣IP地址，來自這個IP的請求將負載均衡轉發後端Pod中的容器。
Service通過LableSelector選擇一組Pod提供服務。
在K8s集羣中微服務的負載均衡是由Kube-proxy實現的，在K8s的每個節點上都有一個Service其實就是我們經常提起的微服務架構中的一個“微服務”，kubernetes中的核心。通過分析、識別並建模系統中的所有服務爲微服務——Kubernetes Service，最終我們的系統由多個提供不同業務能力而又彼此獨立的微服務單元所組成，服務之間通過TCP/IP進行通信，從而形成了我們強大而又靈活的彈性網絡，擁有了強大的分佈式能力、彈性擴展能力、容錯能力。

如上圖示，每個Pod都提供了一個獨立的Endpoint（Pod IP+ContainerPort）以被客戶端訪問，多個Pod副本組成了一個集羣來提供服務，一般的做法是部署一個負載均衡器來訪問它們，爲這組Pod開啓一個對外的服務端口如8000，並且將這些Pod的Endpoint列表加入8000端口的轉發列表中，客戶端可以通過負載均衡器的對外IP地址+服務端口來訪問此服務。運行在Node上的kube-proxy其實就是一個智能的軟件負載均衡器，它負責把對Service的請求轉發到後端的某個Pod實例上，並且在內部實現服務的負載均衡與會話保持機制。Service不是共用一個負載均衡器的IP地址，而是每個Servcie分配一個全局唯一的虛擬IP地址，這個虛擬IP被稱爲Cluster IP。

Node IP Node節點的IP地址，是Kubernetes集羣中每個節點的物理網卡的IP地址，是真是存在的物理網絡，所有屬於這個網絡的服務器之間都能通過這個網絡直接通信；
Pod IP Pod的IP地址，是Docker Engine根據docker0網橋的IP地址段進行分配的，通常是一個虛擬的二層網絡，位於不同Node上的Pod能夠彼此通信，需要通過Pod IP所在的虛擬二層網絡進行通信，而真實的TCP流量則是通過Node IP所在的物理網卡流出的；
Cluster IP 僅僅作用於Kubernetes Servcie這個對象，並由Kubernetes管理和分配IP地址；無法被Ping，因爲沒有一個“實體網絡對象”來響應；只能結合Service Port組成一個具體的通信端口；Node IP網、Pod IP網域Cluster IP網之間的通信，採用的是Kubernetes自己設計的一種編程方式的特殊的路由規則，與IP路由有很大的不同；Label
Label可以附加到各種資源對象上，一個資源對象可以定義任意數量的Label。給某個資源定義一個Label，相當於給他打一個標籤，隨後可以通過Label Selector（標籤選擇器）查詢和篩選擁有某些Label的資源對象。我們可以通過給指定的資源對象捆綁一個或多個Label來實現多維度的資源分組管理功能，以便於靈活、方便的進行資源分配、調度、配置、部署等管理工作；Label Selector示例：select * from pod where pod’s name=’XXX’,env=’YYY’，支持操作符有=、!=、in、not in；

4.3.5 Deployment

擁有更加靈活強大的升級、回滾功能。在新的版本中，官方推薦使用Replica Set和Deployment來代替RC，兩者相似度>90%，相對於RC一個最大升級是我們隨時指導當前Pod“部署”的進度。Deployment使用了Replica Set，除非需要自定義升級功能或根本不需要升級Pod，一般情況下，我們推薦使用Deployment而不直接使用Replica Set；

典型使用場景：

創建一個Deployment對象來生成對應的Replica Set並完成Pod副本的創建過程；

檢查更新Deployment的狀態來查看部署動作是否完成（Pod副本的數量是否達到預期的值）；

更新Deployment以創建新的Pod；（比如鏡像升級）

如果當前Deployment不穩定，則回滾到一個早先的Deployment版本；

掛起或者恢復一個Deployment；

4.3.6 Kubectl

Node、Pod、Replication Controller和Service等都可以看作是一種“資源對象”，幾乎所有的資源對象都可以通過Kubernetes提供的kubectl工具執行增、刪、改、查等操作並將其保存在ectd中持久化存儲。常用指令

kubectl get nodes　查看集羣中有多少節點

kubectl create -f mysql-rc.yaml　創建

kubectl apply -f　mysql-rc.yaml　創建或更新

kubectl delete -f mysql-rc.yaml　刪除

kuberctl delete pods --all 刪除所有的pod

kubectl get rc　查詢RC

kubectl get pods 查詢pod默認空間

kubectl get pods —all-namespaces　所有空間

kubectl get pods --namespace kube-system　指定空間

Kubectl get pod pod-name -o wide 顯示更多信息

kubectl get pods -o wide

Kubectl get pod pod-name -o yaml　以yaml格式顯示信息

kubectl get pods -n kube-system | grep -v Running

kubectl get service　查詢service默認空間

kubectl get services --namespace kube-system

kubectl get pods -n kube-system -o wide

kubectl get deployments 查看

kubectl logs -f pods/monitoring-grafana-xxxxxxx -n kube-system

kubectl describe node codename　查看節點的詳細信息

kubectl logs pod-name 查看容器輸出到控制檯日誌

worn_xiao

發佈了196 篇原創文章 · 獲贊 34 · 訪問量 23萬+

私信關注