一.K8S介紹：
Kubernetes(k8s)是Google開源的容器集群管理系統。在Docker技術的基礎上，為容器化的應用提供部署運行、資源調度、服務發現和動態伸縮等一系列完整功能，提高了大規模 容器集群管理的便捷性。
1.K8S優勢：
容器編排；輕量級；開源；彈性伸縮；負載均衡
2.重要概念：
Cluster: 是 計算、存儲和網絡資源的集合，k8s利用這些資源運行各種基於容器的應用.
Master: master是cluster的大腦，他的主要職責是調度，即決定將應用放在那里運行。master運行linux操作系統，可以是物理機或者虛擬機。為了實現高可用，可以運行多個master。
Node: 職責是運行容器應用。node由master管理，node負責監控並匯報容器的狀態，同時根據master的要求管理容器的生命周期。node運行在linux的操作系統上，可以是物理機或者是虛擬機。
Pod: pod是k8s的最小工作單元。每個pod包含一個或者多個容器。pod中的容器會作為一個整體被master調度到一個node上運行。
Controller: k8s通常不會直接創建pod,而是通過controller來管理pod的。controller中定義了pod的部署特性，比如有幾個劇本，在什么樣的node上運行等。為了滿足不同的業務場景，
k8s提供了多種controller，包括deployment、replicaset、daemonset、statefulset、job等。
Deployment: 是最常用的controller。deployment可以管理pod的多個副本，並確保pod按照期望的狀態運行。
Replicaset: 實現了pod的多副本管理。使用deployment時會自動創建replicaset，也就是說deployment是通過replicaset來管理pod的多個副本的，我們通常不需要直接使用replicaset。
Daemonset: 用於每個node最多只運行一個pod副本的場景。正如其名稱所示的，daemonset通常用於運行daemon。
Job: 用於運行結束就刪除的應用，而其他controller中的pod通常是長期持續運行的。
Service: deployment可以部署多個副本，每個pod 都有自己的IP，外界如何訪問這些副本那？答案是service。k8s的 service定義了外界訪問一組特定pod的方式。service有自己的IP和端口，
service為pod提供了負載均衡。k8s運行容器pod與訪問容器這兩項任務分別由controller和service執行。
Namespace: 可以將一個物理的cluster邏輯上划分成多個虛擬cluster，每個cluster就是一個namespace。不同的namespace里的資源是完全隔離的。
二. k8s架構分析
k8s的集群由master和node組成，節點上運行着若干k8s服務
1.master節點：
master節點之上運行着的后台服務有kube-apiserver 、kube-scheduler、kube-controller-manager、etcd和pod網絡。
1.API Server: API Server是k8s的前端接口，各種客戶端工具以及k8s其他組件，可以通過它管理集群的各種資源。
2.Scheduler: scheduer負責決定將pod放在哪個node上運行。另外scheduler在調度時會充分考慮集群的架構，當前各個節點的負載，以及應用對高可用、性能、數據親和性的需求。
3.Controller Manager: 負責管理集群的各種資源，保證資源處於預期的狀態。
4.etcd: 負責保存k8s集群的配置信息和各種資源的狀態信息，當數據發生變化時，etcd會快速的通知k8s相關組件。
5.pod網絡：pod要能夠相互通信，k8s集群必須掌握pod網絡，fannel是其中一個可選的方案。
2.Node節點：
node是pod運行的地方。node上運行的k8s組件有kublet、kube-proxy和pod網絡（例如flannel）
1.kubelet: 是node的agent，當scheduler去確定在某個node上運行pod后，會將pod的具體配置信息發送給該節點的kubelet，kubelet會根據遮羞信息創建和運行容器，並向master報告運行狀態。
2.kube-proxy: 每個node都會運行kube-proxy服務，外界通過service訪問pod，kube-proxy負責將降訪問service的TCP/UDP數據流轉發到后端的容器。如果有多個副本，kube-proxy會實現負載均衡。
3.pod網絡：pod能能夠互相通信，k8s集群必須部署pod網絡，flannel是其中一個可以選擇的方案
3.部署過程：
1.kubectl 發送部署請求到 API Server。
2.API Server 通知 Controller Manager 創建一個 deployment 資源。
3.Scheduler 執行調度任務，將兩個副本 Pod 分發到 k8s-node1 和 k8s-node2。
4.k8s-node1 和 k8s-node2 上的 kubectl 在各自的節點上創建並運行 Pod。
三.deployment—yml文件
命令vs配置文件（yml文件）
1.命令方式簡單直接快捷，上手快；適合臨時測試或實驗。
2.配置文件方式提供了創建的模板，可以重復部署；易於管理；適合正規，跨環境，規模化部署。
案例：啟動nginx pod ,副本為3
1. 命令行方式： kubectl run nginx –image=nginx -r 3
2 .編寫yml文件
執行yml 文件：kubectl apply -f nginx.yml
給node打標簽
1.kubectl label node ken3 disk=ssd
2.將pod加入到標簽節點上（在yml文件中修改）
3.執行yml文件后查看pod，會發現運行在標簽為disk=ssd的節點上。
四.Job
容器按照持續運行的時間可分為兩類：服務類容器和工作類容器。服務類容器通常持續提供服務，需要一直運行，比如 http server，daemon 等。工作類容器則是一次性任務，比如批處理程序，完成后容器就退出。Kubernetes 的 Deployment、ReplicaSet 和 DaemonSet 都用於管理服務類容器；對於工作類容器，我們用 Job。
1.Job配置文件
restartPolicy 指定什么情況下需要重啟容器。對於 Job，只能設置為 Never 或者 OnFailure。對於其他 controller（比如 Deployment）可以設置為 Always 。
如果Job失敗會發生什么？
會自動生成很多pod。因為在job中期待完成數是1.但是因為job內部有錯誤，無法完成相應的任務，而且重啟策略是Never，表示容器從來不會重啟，所以系統為了完成工作，就會一直開啟新的容器，試圖去完成自己的工作。如果重啟策略為OnFailure的話，只有一個pod，但pod會一直重啟！
注意：
restartPolicy 表示pod重啟策略
Always： 這個是默認值，pod退出就會自動重啟
Never: 這個表示容器退出不會重啟
OnFailure: 表示容器再失敗退出的時候才會重啟，容器正常退出不會重啟
imagePullPolicy 表示鏡像拉取的策略
Always: 這個是默認值，表示每次執行yml文件都會去拉取dockerhub中的鏡像
Never: 總是不拉取鏡像
IfNotPresent: 本地不存在才會去拉取鏡像
五.cronjob
1.cj的yml文件
六.service
1.每個 Pod 都有自己的 IP 地址。當 controller 用新 Pod 替代發生故障的 Pod 時，新 Pod 會分配到新的 IP 地址。這樣就產生了一個問題：
如果一組 Pod 對外提供服務（比如 HTTP），它們的 IP 很有可能發生變化，那么客戶端如何找到並訪問這個服務呢？Kubernetes 給出的解決方案是 Service。
Kubernetes Service 從邏輯上代表了一組 Pod，具體是哪些 Pod 則是由 label 來挑選。Service 有自己 IP，而且這個 IP 是不變的。客戶端只需要訪問 Service 的 IP，Kubernetes 則負責建立和維護 Service 與 Pod 的映射關系。無論后端 Pod 如何變化，對客戶端不會有任何影響，因為 Service 沒有變。
2.創建service:
先創建deployment文件（如上）
再創建service文件：
selector 指明挑選那些 label 為 run: httpd 的 Pod 作為 Service 的后端。
將 Service 的 8080 端口映射到 Pod 的 80 端口，使用 TCP 協議。（tcp協議可省略，默認的）
七.DNS訪問
此時我們通過另一個容器來訪問剛才的pod
1.啟動容器busybox
2.通過名稱訪問service中運行的pod(進入到容器busybox中)
Wget httpd-svc:80
發現可以訪問。但要注意，通過名稱訪問，只能在同一名稱空間。如果不是在同一名稱空間，需要指定namespace. 執行如下：
1.修改yml文件：
2.同樣啟動容器busybox，並指定名稱空間進行訪問
Wget httpd2-svc.kube-public:80
3.或者在啟動容器busybox時就指定名稱空間
Kubectl run -it –image=busybox -n kube-public /bin/sh
八.外網如何訪問pod？（這里主要講通過端口形式）
1.編寫service的文件
在原有文件添加type:NodePort,表示暴露一個隨機端口出來。外部訪問只需加上這個端口就可以訪問。
2.固定宿主機端口
(1).編寫service的yml文件(加上固定端口號即可)
幾個端口表示的含義
port：表示svc的端口
targetPort: pod的端口
nodePort: 需要映射到宿主機的端口
九.數據管理（volume）
1.emptyDir
emptyDir 是最基礎的 Volume 類型。一個 emptyDir Volume 是 Host 上的一個空目錄。emptyDir Volume 對於容器來說是持久的，對於 Pod 則不是。當 Pod 從節點刪除時，Volume 的內容也會被刪除。但如果只是容器被銷毀而 Pod 還在，則 Volume 不受影響。emptyDir Volume 的生命周期與 Pod 一致。
實踐emptyDir(相當於docker中Docker Management Volume)
emptyDir 是 Host 上創建的臨時目錄，其優點是能夠方便地為 Pod 中的容器提供共享存儲，不需要額外的配置。但它不具備持久性，如果 Pod 不存在了，emptyDir 也就沒有了。
2.hostpath
hostPath Volume 的作用是將 Docker Host 文件系統中已經存在的目錄 mount 給 Pod 的容器。大部分應用都不會使用 hostPath Volume，因為這實際上增加了 Pod 與節點的耦合，限制了 Pod 的使用。不過那些需要訪問 Kubernetes 或 Docker 內部數據（配置文件和二進制庫）的應用則需要使用 hostPath。
實踐hostPath(效果相當於執行： docker run -v /tmp:/usr/share/nginx/html
編寫yml文件
3.NFS
1.環境准備：控制節點部署好NFS，節點需要下載nfs-utils支持nfs文件類型
2.編寫yml文件
4.pv&pvc
PersistenVolume(pv)是外部存儲系統中的一塊存儲空間，由管理員創建和維護。與volume一樣，pv具有持久性，生命周期獨立於Pod。
PersistentVolumeClaim(pvc)是對pv的申請。Pvc通常由普通用戶創建和維護。需要為pod分配存儲資源時，用戶可以創建一個pvc，指明存儲資源的容量大小和訪問模式等信息，K8s會查找並提供滿足條件的pv.
有了PersistentVolumeClaim，用戶只需要告訴k8s需要什么樣的存儲資源，而不必關心真正的空間從哪里分配，如何訪問等底層細節信息。這些Storage Provider的底層信息交給管理員來處理。
實踐PV/PVC
1.部署NFS
2.編寫pv的yml文件
3.執行yml文件並查看pv
注意：
accessModes有三類
ReadWriteOnce – 可以被單個節點進行讀寫掛載
ReadOnlyMany – 可以被多個節點進行只讀掛載
ReadWriteMany – 可以被多個節點進行讀寫掛載
4.創建pvc
編寫pvc的yml文件
執行yml文件並查看pvc
5.使用pvc
編寫部署nginx的yml文件
執行yml文件並進行測試
5.如何釋放pv
1.先停掉pod
2.刪除pvc
3.刪除pv
十.應用機密信息與配置管理
Secret
應用啟動過程中可能需要一些敏感信息，比如訪問數據庫的用戶名密碼或者秘鑰。將這些信息直接保存在容器鏡像中顯然不妥，Kubernetes 提供的解決方案是 Secret。
Secret 會以密文的方式存儲數據，避免了直接在配置文件中保存敏感信息。Secret 會以 Volume 的形式被 mount 到 Pod，容器可通過文件的方式使用 Secret 中的敏感數據；此外，容器也可以環境變量的方式使用這些數據。
實踐Secret
1.創建Secret
加密用戶及密碼： echo ‘123’ | base64
編寫secret的yml文件
執行yml文件並查看，獲取加密密碼
2.使用secret
兩種方式：1.以volume形式掛載在pod上；2.以環境變量形式使用
以volume的形式掛載到pod
1.創建pod並編寫yml文件
執行yml文件並進入到pod 查看secret
Volume形式可以動態更新密碼
以環境變量方式使用secret
1.編寫yml文件
執行文件並進入到Pod驗證