瞭解kubertnetes

kubernetses在古希臘語中意味著舵手的意思，docker把自己比作一條鯨魚承載著各種集裝箱貨物在大海遨遊。谷歌就要用kubernetes掌握這條鯨魚帶領著他的航行方向。

kubetnetes是一個open-source system 開源系統，是為了自動化，讓我們的應用部署、擴縮容、管理容器化的應用自動化。

kebetnetes是谷歌15年的生產環境的經驗積累，經過了大量的實踐驗證過的，並且融合社群優秀的ider和經驗。2017年kubernetes在容器編排大戰中勝出。

一切以服務為中心， 使用者不用去關心執行的環境執行的細節，構建在kubernetes上的系統不僅可以獨立執行在物理機虛擬機器私有云公有云等在任何宿主機執行都是無差別的。

在kubernetes中的服務，可以自動的擴縮容、更新、升級、部署。在受到相應的指令後，他會觸發一個排程流程，選中目標節點部署或停止相應的服務，如果有新的服務啟動會自動的加入相應的負載均衡器自動的生效，執行的過程中kubernetes會定期檢查他們的例項數以及他們執行的狀態。當發現 某個例項不可用的情況會銷燬重新建立一個例項。不需要人工參與

kubernetes是以docker的技術標準為基礎，去打造一個全新的分散式架構系統。kubernetes並不需要底層一定是docker，需要的只是docker的一種技術標準，只要實現了這個標準的產品都可以替代docker。

kubernetes核心概念

pod建立過程：

1.通過yaml或命令建立新的pod

2.kubectl將事件寫入apiserver

3.apiserver將該pod事件寫入etcd

4.watch API監聽apiserver狀態


5.將事件放入FIFO佇列，Informe取出事件，將事件寫入DeltaFIFO快取中，kubescheduler通過pod是否繫結主機，為pod進行排程繫結並寫入etcd。


6.LocalStore讀取快取進行更新，store同步，更新controller。controller讀取node節點是否部署。

7.kubelet通過send even觸發事件進行建立。

pod replicaset deployment

pod執行在containerd之上，每個pod中都運行了pause映象。負責將pod中的容器link到一起以及容器的健康檢查。同一個pod中的容器共享一個networknamespace以及一個名稱空間所以同一個pod下的容器會共享一個hostname，一個ip地址。通過埠來指定不通的服務。

replicaset（複製集）是運行於pod之上，複製pod副本集數量的建立監測等，當replicaset中pod出現問題不滿足副本集數量時會將故障的pod銷燬，重新部署。在kubetnetes1.6以後官方將rs特意的隱藏掉不需要使用者過多的去關注，轉而又deployment封裝rc。

deployment更新本質上是管理rs。當有更新時會按照定義的策略去重新建立一個rc及pod，刪掉舊的rs下指定數量的pod，然後新的在更新一個pod。舊的rs把pod及rc都刪除。

deployment滾動更新：

service流程：

service通過標籤選擇同一名稱空間下的pod進行負載，service對外提供了一個clusterIP可供叢集內訪問。通過ClusterIP將請求傳送到service，service通過核心級IPVS將後端pod資訊錄入然後進行負載，請求到達pod所在的node後由kube-proxy進行分發到具體的pod。

service要實現負載需與node中kube-proxy進行結合。kube-proxy負載與service的通訊。

kube-proxy和service背景

說到kube-proxy，就不得不提到k8s中service，下面對它們兩做簡單說明：

kube-proxy其實就是管理service的訪問入口，包括叢集內Pod到Service的訪問和叢集外訪問service。 kube-proxy管理sevice的Endpoints，該service對外暴露一個Virtual IP，也成為Cluster IP, 叢集內通過訪問這個Cluster IP:Port就能訪問到叢集內對應的serivce下的Pod。 service是通過Selector選擇的一組Pods的服務抽象，其實就是一個微服務，提供了服務的LB和反向代理的能力，而kube-proxy的主要作用就是負責service的實現。 service另外一個重要作用是，一個服務後端的Pods可能會隨著生存滅亡而發生IP的改變，service的出現，給服務提供了一個固定的IP，而無視後端Endpoint的變化。

kube-proxy內部原理：

kube-proxy當前實現了兩種proxyMode：userspace和iptables。其中userspace mode是v1.0及之前版本的預設模式，從v1.1版本中開始增加了iptables mode，在v1.2版本中正式替代userspace模式成為預設模式。

iptables mode因為使用iptable NAT來完成轉發，也存在不可忽視的效能損耗。另外，如果叢集中存在上萬的Service/Endpoint，那麼Node上的iptables rules將會非常龐大，效能還會再打折扣。這也導致，目前大部分企業用k8s上生產時，都不會直接用kube-proxy作為服務代理，而是通過自己開發或者通過Ingress Controller來整合HAProxy, Nginx來代替kube-proxy。

kubernetes的架構設計

kubernetes認證的密碼學原理

通過apiserver進行認證與授權

加密分為對稱加密與非對稱加密，對稱加密是指雙方約定好公私鑰進行加密解密校驗通訊。非對稱加密是指在對稱加密之前先校驗此次通訊加密的合法性，先行校驗隨後在進行對稱加密。為了保證非對稱加密的可靠性，所以用到了中立的ca證書，來進行校驗服務端是否可信。TLS/SSL加密協議

kubernetes提供了三種認證方式基於證書的TLS雙向認證。以及祕鑰token認證，內部通訊使用ServiceAccount將證書以及token等資訊掛載到pod指定目錄中然後pod可與serviceapi進行通訊。

kubernetes授權

三種授權策略，kubernetes1.6版本以後使用RBAC模型。

RBAC是什麼？

RBAC是基於角色的訪問控制（Role-BasedAccessControl）在RBAC中，許可權與角色相關聯，使用者通過成為適當角色的成員而得到這些角色的許可權。這就極大地簡化了許可權的管理。這樣管理都是層級相互依賴的，許可權賦予給角色，而把角色又賦予使用者，這樣的許可權設計很清楚，管理起來很方便。

RBAC介紹。

RBAC認為授權實際上是Who、What、How三元組之間的關係，也就是Who對What進行How的操作，也就是“主體”對“客體”的操作。

Who：是許可權的擁有者或主體（如：User，Role）。

What：是操作或物件（operation，object）。

How：具體的許可權（Privilege,正向授權與負向授權）。

然後RBAC又分為RBAC0、RBAC1、RBAC2、RBAC3.

kubernetes授權設計：

RBAC設計分為使用者層，角色層，資源許可權層。

使用者層分為普通使用者user，叢集內部訪問使用者ServiceAccount。

資源動作層，包含resource（namespace等）， verbs：一般的動作分為：listcreate updateplace小更新 delete等。

角色層分為當前角色名稱，包含資源（當前namespace下），執行動作等。

k8s內部並無資料庫來儲存關係表所以需要RoleBinding，角色繫結。然後可以執行當前角色namespace下資源相對應的工作。如需全域性許可權則需要ClusterRole，並進行ClusterRolebinding。

角色授權完畢後還需准入控制，對角色進行入口或請求控制Adminsioncontrol。

大體有AlwayAdmit允許所有，AlwaysDeny拒絕所有，ServiceAccoun

t協助serviceaccount對沒有角色的pod等頒發當前namespace下預設的serviceaccount。DenyEscolatingExec拒絕exec動作。