K8S知識點總結

 

一.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驗證