了解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就能訪問到集群內對應的seri vc e下的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-Based Access Control ）在 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：一般的動作分為：list create update place小更新 delete等。
角色層分為當前角色名稱，包含資源（當前namespace下），執行動作等。
k8s內部並無數據庫來存儲關系表所以需要RoleBinding，角色綁定。然后可以執行當前角色namespace下資源相對應的工作。如需全局權限則需要ClusterRole，並進行ClusterRolebinding。
角色授權完畢后還需准入控制，對角色進行入口或請求控制Adminsioncontrol。
大體有AlwayAdmit允許所有，AlwaysDeny拒絕所有，ServiceAccoun
t協助serviceaccount對沒有角色的pod等頒發當前namespace下默認的serviceaccount。DenyEscolatingExec拒絕exec動作。
kubenetes各組件端口
以下是Master節點的端口列表
以下是node節點的端口列表
api-service: 使用6443端口進行通信，可開啟8080網頁登錄查看信息。默認會生成kubernetes的service 使用cluster網關ip 后端對應master service-ip。
kube-controller: metric端口為10252，內部加密通訊端口為10257。
kube-scheduler: metric端口為10251，內部加密通訊端口為10259。
kubelet: 監聽的端口10250,api會檢測他是否存活 。10248 –healthz-port: 健康檢查服務的端口 。10255 –read-only-port: 只讀端口，可以不用驗證和授權機制，直接訪問 。4194 –cadvisor-port: 當前節點 cadvisor 運行的端口。
kube-proxy: metric端口為10249,healthz端口10256。
NodePort:默認生成端口30000-32767
ingress： metric端口10254
nocache： 端口53
calico： 端口9099
etcd： 對外訪問端口2379，內部通信2380端口。
prometheus： 9090端口
grafan： 3000端口
alertmanager： 9093端口
kafka： 9092端口
es ： 9200端口
elk組件各版本7.6.2 zookeeper版本3.6 kafka2.12 promethus版本2.2 docker版本1.17 1.16 k8s版本1.20.2 1.17 1.19 1.16.10幾個版本有問題ipset無鎖沖突 grafan7.x