云原生部署_k8s入門

K8S官網文檔：https://kubernetes.io/zh/docs/home/

Kubernetes是什么

Kubernetes 是用于自動部署、擴縮和管理容器化應用程序的開源系統。 Kubernetes 源自，Google 15 年生產環境的運維經驗同時凝聚了社區的最佳創意和實踐。簡稱K8s.

Kubernetes：作為開源的容器編排引擎，用來對容器化應用進行自動化部署、擴縮和管理。

K8s核心架構

????????K8S 是屬于Master-Worker架構，即有 Master 節點負責核心的調度、管理和運維，Worker 節點則執行用戶的程序。但是在 K8S 中，主節點一般被稱為Master Node ，而從節點則被稱為WorkerNode 或者 Node。

????????所有 Master Node 和 Worker Node 組成了K8S 集群，同一個集群可能存在多個 Master Node 和 Worker Node。（不是單個主節點）。

? ? ? ? 為了實現對應的能力，不同類型的節點具有不同的組件。

Master Node組件

kube-apiserver。K8S 的請求入口服務。API Server 負責接收 K8S 所有請求（來自 UI 界面或者 CLI 命令行工具），然后，API Server 根據用戶的具體請求，去通知其他組件干活。
Scheduler。K8S 所有 Worker Node 的調度器。當用戶要部署服務時，Scheduler 會選擇最合適的 Worker Node（服務器）來部署。
Controller Manager。K8S 所有 Worker Node 的監控器。Controller Manager 有很多具體的 Controller，Node Controller、Service Controller、Volume Controller 等。Controller 負責監控和調整在 Worker Node上部署的服務的狀態，比如用戶要求 A 服務部署 2 個副本，那么當其中一個服務掛了的時候，Controller 會馬上調整，讓 Scheduler 再選擇一個 Worker Node 重新部署服務。
etcd。K8S 的存儲服務。etcd 存儲了 K8S 的關鍵配置和用戶配置。K8S 中僅 API Server 才具備讀寫權限，其他組件必須通過 API Server 的接口才能讀寫數據。

Worker Node組件

Kubelet。Worker Node 的監視器，以及與 Master Node 的通訊器。Kubelet 是 Master Node 安插在Worker Node 上的“眼線”，它會定期向 Master Node 匯報自己 Node 上運行的服務的狀態，并接受來自Master Node 的指示采取調整措施。負責控制所有容器的啟動停止，保證節點工作正常。
Kube-Proxy。K8S 的網絡代理。Kube-Proxy 負責 Node 在 K8S 的網絡通訊、以及對外部網絡流量的負載均衡。
Container Runtime。Worker Node 的運行環境。即安裝了容器化所需的軟件環境確保容器化程序能夠跑起來，比如 Docker Engine運行環境。

K8s網絡模型

K8s內部存在4中不同的網絡通信：

同一個Pod內容器之間的通信
不同Pod之間通信
Pod和Service之間通信
集群外部流量和Service之間

K8S為Pod和Service資源對象分別使用了各自的專有網絡，Pod網絡由K8S的網絡插件配置實現，而Service網絡則由K8S集群指定。?

K8s實戰/kubectl命令使用

kubectl是apiserver的客戶端工具，工作在命令行下，能夠連接apiserver實現各種增刪改查等操作。kubectl官方使用文檔：https://kubernetes.io/zh/docs/reference/kubectl/overview/

NameSpace（命名空間）

將同一集群中的資源劃分為相互隔離的組。
同一命名空間內的資命名稱要唯一.
命名空間是用來隔離資源的，不隔離網絡。

創建namespace

1. 命令方式

kubectl create namespace tuling

2. yaml方式

新建一個名為 my-namespace.yaml 的 YAML 文件

apiVersion: v1
kind: Namespace
metadata:
????????name: tulingmall

運行：kubectl apply -f my-namespace.yaml

刪除namespace

kubectl delete namespace tuling
kubectl delete -f my-namespace.yaml

Pod

Pod是可以在 Kubernetes 中創建和管理的、最小的可部署的計算單元。

Pod中可以有一個或多個容器，這些容器共享存儲、網絡、以及怎樣運行這些容器的聲明。

Deployment

Deployment負責創建和更新應用程序的實例，使Pod擁有多副本，自愈，擴縮容等能力。

創建Deployment后，Kubernetes Master 將應用程序實例調度到集群中的各個節點上。如果托管實例的節點關閉或被刪除，Deployment控制器會將該實例替換為群集中另一個節點上的實例。這提供了一種自我修復機制來解決機器故障維護問題。

?kubectl create deployment // 可以創建一個應用部署deployment與pod

1.?kubectl create deployment my-tomcat --image=tomcat:9.0.55

?#my-tomcat表示pod的名稱 --image表示鏡像的地址

2.?kubectl get deployment

#查看一下deployment的信息

3.?kubectl delete deployment my-tomcat

#刪除deployment

4.?kubectl logs my-tomcat-6d6b57c8c8-n5gm4

#查看Pod打印的日志

5.?#使用 exec 可以在Pod的容器中執行命令

kubectl exec my-tomcat-6d6b57c8c8-n5gm4 -- env? #使用 env 命令查看環境變量

kubectl exec my-tomcat-6d6b57c8c8-n5gm4 -- ls /? ?# 查看容器的根目錄下面內容

kubectl exec my-tomcat-6d6b57c8c8-n5gm4 -- sh? ? #進入Pod容器內部并執行bash命令，如果想退出容器可以使用exit命令

Service

????????Service是一個抽象層，它定義了一組Pod的邏輯集，并為這些Pod支持外部流量暴露、負載均衡和服務發現。

????????盡管每個Pod 都有一個唯一的IP地址，但是如果沒有Service，這些IP不會暴露在集群外部。Service允許您的應用程序接收外部流量。Service也可以用在ServiceSpec標記type的方式暴露，type類型如下：

ClusterIP（默認）：在集群的內部IP上公開Service。這種類型使得Service只能從集群內訪問。
NodePort：使用NAT在集群中每個選定Node的相同端口上公開Service。使用 <NodeIP>:<NodePort> 從集群外部訪問Service。是ClusterIP的超集。
LoadBalancer：在當前云中創建一個外部負載均衡器(如果支持的話)，并為Service分配一個固定的外部IP。是NodePort的超集。
ExternalName：通過返回帶有該名稱的CNAME記錄，使用任意名稱（由spec中的externalName指定）公開Service。不使用代理。

Ingress

????????Ingress是一種 Kubernetes 資源類型，它允許在 Kubernetes 集群中暴露 HTTP 和 HTTPS 服務。通過 Ingress，您可以將流量路由到不同的服務和端點，而無需使用不同的負載均衡器。

????????Ingress 通常使用 Ingress Controller 實現，它是一個運行在 Kubernetes 集群中的負載均衡器，它根據Ingress 規則配置路由規則并將流量轉發到相應的服務。

Ingress 和 Service區別

????????Ingress 和 Service都是 Kubernetes 中用于將流量路由到應用程序的機制，但它們在路由層面上有所不同：

Service 是 Kubernetes 中抽象的應用程序服務，它公開了一個單一的IP地址和端口，可以用于在 Kubernetes集群內部的 Pod 之間進行流量路由。
Ingress 是一個 Kubernetes 資源對象，它提供了對集群外部流量路由的規則。Ingress 通過一個公共IP地址和端口將流量路由到一個或多個Service。

存儲

Volume

????????Volume指的是存儲卷，包含可被Pod中容器訪問的數據目錄。容器中的文件在磁盤上是臨時存放的，當容器崩潰時文件會丟失，同時無法在多個Pod中共享文件，通過使用存儲卷可以解決這兩個問題。

PV & PVC

Volume 提供了非常好的數據持久化方案，不過在可管理性上還有不足。要使用Volume， Pod 必須事先知道以下信息：

當前的 Volume 類型并明確 Volume 已經創建好。
必須知道 Volume 的具體地址信息。

????????但是 Pod 通常是由應用的開發人員維護，而 Volume 則通常是由存儲系統的管理員維護。開發人員要獲得上面的信息，要么詢問管理員，要么自己就是管理員。這樣就帶來一個管理上的問題：應用開發人員和系統管理員的職責耦合在一起了。

????????Kubernetes 給出的解決方案是 Persistent Volume 和 Persistent Volume Claim。

PersistentVolume(PV）是外部存儲系統中的一塊存儲空間，由管理員創建和維護，將應用需要持久化的數據保存到指定位置。PV 具有持久性，生命周期獨立于 Pod。
Persistent Volume Claim (PVC)是對 PV 的申請 (Claim），申明需要使用的持久卷規格。PVC 通常由普通用戶創建和維護。需要為 Pod 分配存儲資源時，用戶可以創建一個PVC，指明存儲資源的容量大小和訪問模式（比如只讀）等信息，Kubernetes 會查找并提供滿足條件的 PV。

????????有了PersistentVolumeClaim，用戶只需要告訴 Kubernetes 需要什么樣的存儲資源，而不必關心真正的空間從哪里分配、如何訪問等底層細節信息。這些 Storage Provider 的底層信息交給管理員來處理。

K8S工作流程

以k8s部署nginx為例，在master節點執行一條命令要master部署一個nginx應用

(kubectl create deployment nginx --image=nginx)

Master Node動作：

這條命令首先發到master節點的網關api server，這是matser的唯一入口
api server將命令請求交給controller mannager進行控制(請求轉交：api server -> controller)
controller mannager 進行應用部署解析，生成一次部署信息，并通過api server將信息存入etcd存儲（存儲要部署的應用: controller->etcd）
scheduler調度器通過api server從etcd存儲中，拿到要部署的應用，開始調度看哪個節點有資源適合部署(讀取要部署的應用：etcd ->scheduler )
scheduler把計算出來的調度信息通過api server再放到etcd中（保存調度信息：scheduler->etcd）

Worker Node動作：

每一個node節點的監控組件kubelet，隨時和master保持聯系（給api-server發送請求不斷獲取最新數據），拿到master節點存儲在etcd中的部署信息(node獲取Master信息)
假設node2的kubelet拿到部署信息，顯示他自己節點要部署某某應用，kubelet就自己run一個應用在當前機器上，并隨時給master匯報當前應用的狀態信息（node執行相應動作）
node和master也是通過master的api-server組件聯系的
每一個Node機器上的kube-proxy能知道集群的所有網絡，只要node訪問別人或者別人訪問node，node上的kube-proxy網絡代理自動計算進行流量轉發（流量轉發）