Kubernetes 入門筆記

節點

Kubernetes 是主從結構，分爲主節點和工作節點

Master

Master 指集羣控制節點，主節點。負責整個集羣的管理和控制。在 Master 運行着以下關鍵進程：

API Server(kube-apiserver)：提供 Http Rest 接口的關鍵服務進程，是 Kubernetes 所有資源增刪改查的唯一入口，也是集羣控制的入口進程。
Controller Manager(kube-controller-manager)：Kubernetes 所有資源對象的自動化控制中心，就像是資源對象的 “大總管”。
Scheduler(kube-scheduler)：負責資源調度 (Pod 調度) 的進程，相當於“調度室”。

Master 需要部署 etcd 服務，因爲 Kubernetes 所有資源對象數據保存在 etcd 中。高可用部署建議 3 臺服務器部署 Master。

Node

除了 Master，其他集羣中的機器稱爲 Node，是集羣中的工作負載節點。每個 Node 都會被 Master 分配一些工作負載 (Docker 容器)，當某個 Node 宕機時，其上面的工作負載就會被 Master 自動轉移到其他 Node 上。在 Node 運行着以下關鍵進程：

kubelet：負責 Pod 對應的容器的創建、啓動、停止等任務，同時與 Master 密切協作，實現集羣的基本功能。
kube-proxy：實現 Kubernetes Service 的通信和負載均衡機制的重要組件。
Docker Engine：Docker 引擎，負責本機的容器創建和管理工作。

Node 可以在運行期間動態增加到 Kubernetes 集羣中，默認情況下 kubelet 會向 Master 註冊自己，定時向 Master 彙報自身信息，以及當前有哪些 Pod 在運行等。當超過一定時間，不上報信息時，Master 就會將此 Node 標記爲不可用，接着觸發工作負載轉移的自動流程。

查看 Node：

kubectl get nodes

查看 Node 的詳細信息：

kubectl describe node Node-NAME

命名空間

Kubernetes 可以創建多個虛擬集羣，稱爲命名空間 (namespace)，用於實現多租戶的資源隔離，通過將集羣內部的資源對象分配到不同的 namespace 中，形成邏輯上分組的不同項目、小組或用戶組，便於不同分組在共享集羣資源的同時可以被分別管理。如果沒有明確定義的命名空間，集羣將在始終存在的默認命名空間 (default) 中創建。

查看命名空間

kubectl get namespace

創建命名空間

kubectl create namespace test-zjh

刪除命名空間

kubectl delete namespace test-zjh

資源對象

我們可以採用 YAML 或 JSON 格式定義或創建一個 Kubernetes 資源對象

kubectl apply -f ./my-manifest.yaml           # 創建資源
kubectl apply -f ./my1.yaml -f ./my2.yaml     # 使用多個文件創建
kubectl apply -f ./dir                        # 基於目錄下的所有清單文件創建資源
kubectl apply -f https://git.io/vPieo         # 從 URL 中創建資源

dPqCQw

以上列舉的內容都是 kubernetes 中的 Object，這些對象都可以在 yaml 文件中作爲一種 API 類型來配置。在想要創建的 Kubernetes 對象對應的 .yaml 文件中，必須配置如下的字段：

apiVersion - 創建該對象所使用的 Kubernetes API 的版本
kind - 想要創建的對象的類型
metadata - 幫助識別對象唯一性的數據，包括一個 name 字符串、UID 和可選的 namespace
也需要提供對象的 spec 字段。對象 spec 的精確格式對每個 Kubernetes 對象來說是不同的，包含了特定於該對象的嵌套字段。

容器集 (Pod)

Kubernetes 中的邏輯而非物理的工作單位（最基本單位）稱爲 Pod。Pod 是包含一個或多個容器的容器組。同一容器集中的所有容器共享同一個 IP 地址、IPC、主機名稱及其它資源。每個 Pod 都會包含一個特殊的 Pause 容器 (根容器)，再加上一個或多個用戶的業務容器。Pause 容器的作用就是提供 IP 等資源共享給業務容器的。

例，定義一個 Nginx 的 Pod：

apiVersion: v1 # API版本
kind: Pod # 指定資源對象類型爲 Pod
metadata:
  name: zjh-nginx # Pod的名稱
  labels: # 指定標籤，自定義key-value(可多個)，用於查詢和篩選
    app: test-nginx
spec: # 容器組定義
  containers:
    - name: web
      image: nginx:latest
      ports:
        - containerPort: 80

保存爲 zjh-nginx.yaml

部署 Pod：

kubectl apply -f ./zjh-nginx.yaml -n test-zjh  # -n 指定命名空間

查看 Pod：

kubectl get pod -n test-zjh -o wide # -o wide 顯示更詳細的信息
kubectl get pod -n test-zjh -o yaml # -o yaml 獲取pod的yaml

查看日誌：

kubectl logs zjh-nginx -n test-zjh -f

刪除 Pod：

kubectl delete pod zjh-nginx -n test-zjh

測試訪問 nginx 服務 (目前只能在 Kubernetes 集羣內訪問)：

控制器 (Controller)

Kubernetes 中內建了很多 controller（控制器），這些相當於一個狀態機，用來控制 Pod 的具體狀態和行爲。控制器包括有 Deployment，StatefulSet，DaemonSet，Replication Controller，Replica Set，Job，Cron Job，Horizontal Pod Autoscaling，Admission Controller。

Deployment

Deployment 是 Kubernetes 在 1.2 版本引入的新概念，內部使用了 Replica Set 來實現目的，爲 Pod 和 ReplicaSet 提供了一個聲明式定義（declarative）方法，用來替代以前的 Replication Controller（RC）來方便的管理應用，可以看作是 RC 的一次升級。典型的應用場景包括：

定義 Deployment 來創建 Pod 和 ReplicaSet
滾動升級和回滾應用
擴容和縮容
暫停和繼續 Deployment

例，定義一個 Nginx 的 Deployment ：

apiVersion: apps/v1 # API版本
kind: Deployment # 資源對象類型爲 Deployment
metadata:
  name: zjh-nginx # Deployment的名稱
spec:
  selector: # 定位需要管理的 Pod，通過Pod的labels標籤定位
    matchLabels:
      app: test-nginx
  replicas: 3 # 要部署的個數，k8s自動擴容分配
  template: # 要部署的 Pod
    metadata:
      labels:
        app: test-nginx
    spec:
      containers:
        - name: web
          image: nginx:latest
          ports:
            - containerPort: 80

重新保存爲 zjh-nginx.yaml

部署 Deployment ：

kubectl apply -f ./zjh-nginx.yaml -n test-zjh  # -n 指定命名空間

查看 Pod：

kubectl get pods -n test-zjh -o wide -l 'app=test-nginx' # -l 指定labels

查看 Deployment ：

kubectl get deploy -n test-zjh -o wide

測試刪除一個 pod：

kubectl delete pod zjh-nginx-7b9f67656d-446k2 -n test-zjh

發現會自動重新部署一個新的 Pod：擴容：

kubectl scale deployment zjh-nginx -n test-zjh --replicas 4 # 擴容爲4個

刪除 Deployment ：

kubectl delete deployment zjh-nginx -n test-zjh

服務發現

Kubernetes 中爲了實現服務實例間的負載均衡和不同服務間的服務發現，創造了 Serivce 對象，同時又爲從集羣外部訪問集羣創建了 Ingress 對象。

Service

Serivce （svc）可以理解爲微服務架構中的一個微服務，Serivce 定義了一個服務的訪問入口地址，通過這個入口地址訪問其背後的一組由 Pod 副本組成的集羣實例。比如，我們用 Deployment 部署了一個集羣服務（有很多 Pod），Serivce 就是爲我們提供訪問入口，Serivce 會發現到其中一個 Pod 進行調用。

例，定義一個 Nginx 的 Serivce ：

apiVersion: apps/v1 # API版本
kind: Deployment # 資源對象類型爲 Deployment
metadata:
  name: zjh-nginx # Deployment的名稱
spec:
  selector: # 定位需要管理的 Pod，通過Pod的labels標籤定位
    matchLabels:
      app: test-nginx
  replicas: 3 # 要部署的個數，k8s自動擴容分配
  template: # 要部署的 Pod
    metadata:
      labels:
        app: test-nginx
    spec:
      containers:
        - name: web
          image: nginx:latest
          ports:
            - containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  ports:
    - port: 80 # Service虛端口
      targetPort: 80 # 容器端口
      nodePort: 33088 # 暴露端口
  selector: # 指定如何選擇 Pod
    app: test-nginx
  type: NodePort # 指定爲Node的IP地址

重新保存爲 zjh-nginx.yaml

部署 Serivce ：

kubectl apply -f ./zjh-nginx.yaml -n test-zjh  # -n 指定命名空間

查看 Serivce ：

kubectl get svc -n test-zjh -o wide

瀏覽器訪問：

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/sxrccfJhIUFNzXUVQdVu4A

節點