一 ：K8s功能
自動化部署容器與復制
隨時擴展或收縮容器規模
組織容器成組，提供容器間的負載均衡
快速更新及回滾容器版本
彈性伸縮，如果某個容器失效就進行替換
二 ：k8s重要組件
（1） Master組件
Master節點上面主要由四個模塊組成，APIServer，scheduler，controller manager，etcd
① APIServer，負責對外提供RESTful的kubernetes API服務，他是系統管理命令的統一入口，任何對資源進行增刪改查的操作都要交給APIServer處理后交給etcd。Kubectl（k8s提供的客戶端工具，該工具內部就是對kubernetes api的調用）是直接和APIServer交互的
② Schedule：他的職責很明確，就是負責調度pod到適合的node上，如果把scheduler看成一個黑匣子，那么它的輸入是pod和由多個node組成的列表，輸出是pod和一個node的綁定，即將這個pod部署到這個node上，kubernetes目前提供了調度算法，但是同樣也保留了接口，用戶可以根據自己的需求定義自己的調度算法
③ Controller manager：如果說APIserver做的事“前台”工作的話，那么controller manager就是負責“后台”的，每個資源一般都對應一個控制器，而controller manager 就是負責管理這些控制器的。比如我們通過APIServer創建一個Pod，當這個pod創建成功后，APIServer的任務就算完成了，而后面保證這個Pod的狀態始終和我們預期的一樣，那重任就是由controller manager去保證了
④ Etcd：它是一個高可用的鍵值存儲系統，kubernetes使用它來存儲各個資源的狀態，從而實現了Restful的API
（2） Node組件
① runtime：runtime是指容器運行環境，目前kubernetes支持docker和rkt兩種容器
② kubelet：kubelet是master在每個node節點上面的agent，是node節點上面最重要的模塊，他負責管理該node上面的所有容器，但是如果容器不是通過kubernetes創建的，它並不會管理，本質上，他負責使Pod得運行狀態與期望的狀態一致
③ kube-proxy：kube-proxy該模塊實現了kubernetes中的服務發現和反向代理功能，反向代理方面：kube-proxy支持tcp和upd連接轉發，默認基於round robin算法將客戶端流量轉發到與service對應的一組后端pod，服務發現方面，kube-proxy使用etcd的watch機制，監控集群中service和endpoint對象數據的動態變化，並且維護一個service到endpoint的映射關系，從而保證了后端pod的IP變化不會對訪問者造成影響，另外kube-proxy還支持session affinity
（3） Pod組件
① Pod：pod是k8s進行資源調度的最小單位，每個pod中運行着一個或多個密切相關的業務容器，這些業務容器共享這個pause容器的IP和Volume,我們以這個不易死亡的pause容器作為pod的根容器，以他的狀態表示整個容器組的狀態，一個pod一旦被創建就會放到ETCD中存儲，然后由master調度到一個node綁定，由這個node上的kubelet進行實例化，每個pod會被分配一個單獨的pod IP，pod IP + Containerport 組成了一個ENDpoin
（4） Service組件
① Service其功能使應用暴露，pods是有生命周期的，也有獨立的IP地址，隨着Pods的創建與銷毀，一個必不可少的工作就是保證各個應用能夠感知這種變化，這就要提到service了，service 是YAML或JSON定義的由Pods通過某種策略的邏輯組合，更重要是，pods的獨立IP需要通過service暴露到網絡中
搭建kubernetes群集環境有哪些方法
1：Minikube安裝方式
Minikube是一個工具，可以本地快速運行一個單點，嘗試Kubernetes或日常開發的用戶使用。但是這種方式僅可用於學習和測試部署，不能用於生產環境。
2：kubeadm安裝方式
kubeadm是一個kubernetes官方提供的快速安裝和初始化擁有最佳實踐（best practice）的kubernetes集群的工具，提供kubeadm init和kubeadm join，用於快速部署Kubernetes集群。目前kubeadm還處於beta 和alpha狀態，不推薦用在生產環境，但是可以通過學習這種部署方法來體會一些官方推薦的kubernetes最佳實踐的設計和思想。
kubeadm的目標是提供一個最小可用的可以通過Kubernetes一致性測試的集群，所以並不會安裝任何除此之外的非必須的addon。kubeadm默認情況下並不會安裝一個網絡解決方案，所以用kubeadm安裝完之后，需要自己來安裝一個網絡的插件。所以說，目前的kubeadm是不能用於生產環境的
3：二進制安裝（生產部署的方法）
從官方下載發行版的二進制包，手動部署每個組件，組成Kubernetes集群，這種方式符合企業生產環境標准的Kubernetes集群環境的安裝，可用於生產方式部署。
三： 基礎信息
使用kubernetes1.14.2，所有節點操作系統centos7.5.本文檔部署中所需要kubernetes相關安裝包和鏡像可提前在FQ服務器上下載，然后同步到k8s部署機器上，具體信息如下
| Ip地址 |
主機名 |
角色 |
| 192.168.124.24 |
K8s-master01 |
主節點1，etc節點1 |
| 192.168.124.26 |
K8s-master02 |
主節點2，etc節點2 |
| 192.168.124.27 |
K8s-master03 |
主節點3，etc節點3 |
| 192.168.124.29 |
K8s-node01 |
工作節點1 |
| 192.168.124.30 |
K8s-node02 |
工作節點2 |
| 192.168.124.31 |
K8s-node03 |
工作節點3 |
| 192.168.124.32 |
K8s-ha01 |
Nginx節點1，harbor節點1 |
| 192.168.124.33 |
K8s-ha02 |
Nginx節點2，harbor節點2 |
本套環境
kubernetes1.14.2
Docker 18.09.6-ce
Etcd 3.3.13
Flanneld 0.11.0
插件
- Coredns
- Dashboard
- Metrics-server
鏡像倉庫：
- harbor（兩個倉庫相互同步，對外提供統一入口VIP地址）
主要配置策略
kube-apiserver高可用（nginx負載層）
- 使用nginx+keepalived實現高可用，VIP：192.168.124.250
- 關閉非安全端口8080和匿名訪問：
- 在安全端口6443接受https請求；
- 嚴格的認證和授權策略（x509，token，RBAC）；
- 開啟bootstrap token認證，支持kubelet TLS bootstrapping；
- 使用https訪問kubelet，etcd，加密通信；
kube-controller-manager高可用：
- 3節點高可用；
- 關閉非安全端口，在安全端口 10252 接收 https 請求；
- 使用 kubeconfig 訪問 apiserver 的安全端口；
- 自動 approve kubelet 證書簽名請求 (CSR)，證書過期后自動輪轉；
- 各controller 使用自己的 ServiceAccount 訪問 apiserver；
kube-scheduler高可用：
- 3節點高可用；
- 使用 kubeconfig 訪問 apiserver 的安全端口；
kubelet：
- 使用 kubeadm 動態創建 bootstrap token，而不是在 apiserver 中靜態配置；
- 使用TLS bootstrap機制自動生成 client 和 server 證書，過期后自動輪轉；
- 在 kubeletConfiguration 類型的 JSON 文件配置主要參數；
- 關閉只讀端口，在安全端口 10250 接收 https 請求，對請求進行認證和授權，拒絕匿名訪問和非授權訪問；
- 使用 kubeconfig 訪問 apiserver 的安全端口；
kube-proxy：
- 使用kubeconfig 訪問 apiserver 的安全端口；
- 在KubeProxyConfiguration 類型的 JSON 文件配置主要參數；
- 使用ipvs代理模式；
集群插件：
- DNS：使用功能、性能更好的 coredns；
- Dashboard：支持登錄認證；
- Metric：metrics-server，使用 https 訪問 kubelet 安全端口；
- Log：Elasticsearch、Fluend、Kibana；
- Registry 鏡像庫：Harbor私有倉庫，兩個節點相互同步；
kubernetes集群部署中生成的證書文件如下：
ca-key.pem 根私鑰（controller-manager配置的時候，跟上--service-account-private-key-file）
ca.pem 根證書（apiserver配置的時候，跟上--service-account-key-file）
kubernetes-key.pem 集群私鑰
kubernetes.pem 集群證書
kube-proxy.pem proxy證書-node節點進行認證
kube-proxy-key.pem proxy私鑰-node節點進行認證
admin.pem 管理員證書-主要用於kubectl認證
admin-key.pem 管理員私鑰-主要用於kubectl認證
TLS作用：就是對通訊加密，防止中間人竊聽；同時如果證書不信任的話根本就無法與 apiserver 建立連接，更不用提有沒有權限向 apiserver 請求指定內容。
RBAC作用：RBAC 中規定了一個用戶或者用戶組(subject)具有請求哪些 api 的權限；在配合 TLS 加密的時候，實際上 apiserver 讀取客戶端證書的 CN 字段作為用戶名，讀取 O 字段作為用戶組。
總之想要與apiserver通訊就必須采用由apiserver CA簽發的證書，這樣才能形成信任關系，建立TLS連接；另外可通過證書的CN、O字段來提供RBAC所需用戶與用戶組。
kubernetes集群會默認開啟RABC（角色訪問控制機制），這里提前了解幾個重要概念：
- DRBC
K8S 1.6引進，是讓用戶能夠訪問K8S API資源的授權方式（不授權就沒有資格訪問K8S的資源）
- 用戶
K8S有兩種用戶：User 和 Service Account。其中，User給用戶使用，Service Account給進程使用，讓進程有相關權限。如Dashboard就是一個進程，可以創建一個Service Account給它使用。
- 角色
Role是一系列權限的集合，例如一個Role可包含讀取和列出Pod的權限（ClusterRole和Role類似，其權限范圍是整個集群）
- 角色綁定
RoleBinding把角色映射到用戶，從而讓這些用戶擁有該角色的權限（ClusterRoleBinding和RoleBinding類似，可讓用戶擁有ClusteRole的權限）
- Secret
Secret是一個包含少量敏感信息如密碼，令牌或密鑰的對象。把這些信息保存在Secret對象中，可以在這些信息被使用時加以控制，並可以減低信息泄露的風險。