一篇文章搞懂K8S高級特性

更新時間：2021年11月16日 10:21:18 作者：core815

這篇文章主要給大家介紹了關(guān)于K8S高級特性的相關(guān)資料,文中通過時實例代碼以及圖文介紹的非常詳細,對大家學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友可以參考下

K8S高級特性

K8S中還有一些高級特性有必要了解下，比如彈性擴縮應(yīng)用（見上文）、滾動更新（見上文）、配置管理、存儲卷、網(wǎng)關(guān)路由等。

在了解這些高級特性之前有必要先看幾個K8S的核心概念：

ReplicaSet

ReplicaSet確保任何時間都有指定數(shù)量的Pod副本在運行。通常用來保證給定數(shù)量的、完全相同的Pod的可用性。建議使用Deployment來管理ReplicaSet，而不是直接使用。

ConfigMap

ConfigMap是一種API對象，用來將非機密性的數(shù)據(jù)保存到鍵值對中。使用時，Pod可以將其用作環(huán)境變量、命令行參數(shù)或者存儲卷中的配置文件。使用ConfigMap可以將你的配置數(shù)據(jù)和應(yīng)用程序代碼分開。

Volume

Volume指的是存儲卷，包含可被Pod中容器訪問的數(shù)據(jù)目錄。容器中的文件在磁盤上是臨時存放的，當(dāng)容器崩潰時文件會丟失，同時無法在多個Pod中共享文件，通過使用存儲卷可以解決這兩個問題。
常用的存儲卷有如下幾種：

configMap：configMap卷提供了向Pod中注入配置數(shù)據(jù)的方法。ConfigMap對象中存儲的數(shù)據(jù)可以被configMap類型的卷引用，然后被Pod中運行的容器化應(yīng)用使用。
emptyDir：emptyDir卷可用于存儲緩存數(shù)據(jù)。當(dāng)Pod分派到某個Node上時，emptyDir卷會被創(chuàng)建，并且Pod在該節(jié)點上運行期間，卷一直存在。當(dāng)Pod被從節(jié)點上刪除時emptyDir卷中的數(shù)據(jù)也會被永久刪除。
hostPath：hostPath卷能將主機節(jié)點文件系統(tǒng)上的文件或目錄掛載到你的Pod中。在Minikube中的主機指的是Minikube所在的虛擬機。
local：local卷所代表的是某個掛載的本地設(shè)備，例如磁盤、分區(qū)或者目錄。local卷只能用作靜態(tài)創(chuàng)建的持久卷，尚不支持動態(tài)配置。
nfs：nfs卷能將NFS（網(wǎng)絡(luò)文件系統(tǒng)）掛載到你的Pod中。
persistentVolumeClaim：persistentVolumeClaim卷用來將持久卷（PersistentVolume）掛載到Pod中。持久卷（PV）是集群中的一塊存儲，可以由管理員事先供應(yīng)，或者使用存儲類（Storage Class）來動態(tài)供應(yīng)，持久卷是集群資源類似于節(jié)點。

Ingress

Ingress 通過K8S的Ingress資源可以實現(xiàn)類似Nginx的基于域名訪問，從而實現(xiàn)Pod的負載均衡訪問。

安裝Ingress

進入頁面https://github.com/kubernetes/ingress-nginx/blob/nginx-0.20.0/deploy/mandatory.yaml，將里面的內(nèi)容復(fù)制，保存到k8s master機器上的一個文件ingress-controller.yaml里，里面的鏡像地址需要修改下，大家直接用下面這個yaml的內(nèi)容：

下載地址（不需要積分）：下載地址

apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: udp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: nginx-ingress-clusterrole
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "extensions"
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
  - apiGroups:
      - "extensions"
    resources:
      - ingresses/status
    verbs:
      - update

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-nginx"
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - get

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: nginx-ingress-role-nisa-binding
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress-role
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: nginx-ingress-clusterrole-nisa-binding
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress-clusterrole
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      hostNetwork: true
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller
          image: siriuszg/nginx-ingress-controller:0.20.0
          args:
            - /nginx-ingress-controller
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
          securityContext:
            allowPrivilegeEscalation: true
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE
            # www-data -> 33
            runAsUser: 33
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
            - name: http
              containerPort: 80
            - name: https
              containerPort: 443
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1

---

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
spec:
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
    - name: https
      port: 443
      targetPort: 443
      protocol: TCP
  selector:
    app.kubernetes.io/name: default-http-backend
    app.kubernetes.io/part-of: ingress-nginx

---

查看是否安裝成功

kubectl get pods -n ingress-nginx -o wide

配置ingress訪問規(guī)則（就是類似配置nginx的代理轉(zhuǎn)發(fā)配置），讓ingress將域名 tomcat.core.com轉(zhuǎn)發(fā)給后端的tomcat-service-yaml 服務(wù)，新建一個文件ingress- tomcat.yaml，內(nèi)容如下：

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
 name: web-ingress
spec:
 rules:
 - host: tomcat.core.com # 轉(zhuǎn)發(fā)域名
   http:
    paths:
    - path: /
      backend: 
       serviceName: tomcat-service-yaml
       servicePort: 80 # service的端口

查看生效的ingress規(guī)則：

kubectl get ing

在訪問機器配置host，master目錄：/etc/hosts，在 host里增加如下host(ingress部署的機器ip對應(yīng)訪問的域名)

192.168.159.131 tomcat.core.com
或者
192.168.159.132 tomcat.core.com

配置完后直接在客戶機瀏覽器訪問http://tomcat.core.com/ ，能正常訪問tomcat。

高級特性

配置管理

ConfigMap允許你將配置文件與鏡像文件分離，以使容器化的應(yīng)用程序具有可移植性。接下來我們演示下如何將ConfigMap的的屬性注入到Pod的環(huán)境變量中去。

添加配置文件nginx-config.yaml用于創(chuàng)建ConfigMap，ConfigMap名稱為nginx-config，存儲信息放在data節(jié)點下：

apiVersion: v1
kind: ConfigMap
metadata: 
 name: nginx-config
 namespace: default
data:
 nginx-env: test

應(yīng)用nginx-config.yaml文件創(chuàng)建ConfigMap：

kubectl create -f nginx-config.yaml

獲取所有ConfigMap：

kubectl get configmap

通過yaml格式查看ConfigMap中的內(nèi)容：

kubectl get configmaps nginx-config -o yaml

添加配置文件nginx-deployment.yaml用于創(chuàng)建Deployment，部署一個nginx服務(wù)，在Nginx的環(huán)境變量中引用ConfigMap中的屬性：

apiVersion: apps/v1
kind: Deployment
metadata: 
 name: nginx-deployment
 labels:
  app: nginx
spec:
 replicas: 1
 selector:
  matchLabels:
   app: nginx
 template:
  metadata:
   labels:
    app: nginx
  spec:
   containers:
    - name: nginx
      image: nginx:1.10
      ports:
       - containerPort: 80
      env:
       - name: NGINX_ENV # 在Nginx中設(shè)置環(huán)境變量
         valueFrom:
          configMapKeyRef:
           name: nginx-config # 設(shè)置ConfigMap的名稱
           key: nginx-env # 需要取值的鍵

應(yīng)用配置文件創(chuàng)建Deployment：

kubectl apply -f nginx-deployment.yaml

創(chuàng)建成功后查看Pod中的環(huán)境變量，發(fā)現(xiàn)NGINX_ENV變量已經(jīng)被注入了；

kubectl get pod -o wide

kubectl exec -it nginx-deployment-5ff74658b6-rlft8 -- sh
# 進入容器控制臺執(zhí)行，下面命令
ECHO $NGINX_ENV

存儲卷使用

通過存儲卷，我們可以把外部數(shù)據(jù)掛在到容器中去，供容器中應(yīng)用訪問，這樣就算容器崩潰了，數(shù)據(jù)依然可以存在。

記得之前我們使用Docker部署Nginx的時候，將Nginx的html、logs、conf目錄從外部掛載到了容器中；

docker run -p 80:80 --name nginx \
-v /mydata/nginx/html:/usr/share/nginx/html \
-v /mydata/nginx/logs:/var/log/nginx \
-v /mydata/nginx/conf:/etc/nginx \
-d nginx:1.10

Minikube 可以認為是一臺虛擬機，我們可以用Minikube的ssh命令來訪問它

minikube ssh

Minikube中默認有一個docker用戶，我們先重置下它的密碼

sudo passwd docker

在Minikube中創(chuàng)建mydata目錄

mkdir /home/docker/mydata

我們需要把nginx的目錄復(fù)制到Minikube中去，才能實現(xiàn)目錄的掛載，注意docker用戶只能修改/home/docker目錄中的文件，我們通過scp命令來復(fù)制文件

scp -r /home/macro/mydata/nginx docker@127.0.0.1:/home/docker/mydata/nginx

添加配置文件nginx-volume-deployment.yaml用于創(chuàng)建Deployment：

apiVersion: apps/v1
kind: Deployment
metadata: 
 name: nginx-volume-deployment
 labels:
  app: nginx
spec:
 replicas: 1
 selector:
  matchLabels:
   app: nginx
 template:
  metadata:
   labels:
    app: nginx
  spec:
   containers:
    - name: nginx
      image: nginx:1.10
      ports:
       - containerPort: 80
      volumeMounts:
       - mountPath: /usr/share/nginx/html
         name: html-volume
       - mountPath: /var/logs/nginx
         name: logs-volume
       - mountPath: /etc/nginx
         name: conf-volume
   volumes:
    - name: html-volume
      hostPath:
       path: /home/docker/mydata/nginx/html
       type: Directory
    - name: logs-volume
      hostPath:
       path: /home/docker/mydata/nginx/logs
       type: Directory
    - name: conf-volume
      hostPath:
       path: /home/docker/mydata/nginx/conf
       type: Directory

應(yīng)用配置文件創(chuàng)建Deployment

kubectl apply -f nginx-volume-deployment.yaml

添加配置文件nginx-service.yaml用于創(chuàng)建Service

apiVersion: v1
kind: Service
metadata: 
 name: nginx-service
spec:
 type: NodePort
 selector:
  app: nginx
 ports:
 - name: http
    protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 30080

查看下Service服務(wù)訪問端口

kubectl get services

通過CURL命令訪問Nginx首頁信息。

總結(jié)

Service是K8S服務(wù)的核心，屏蔽了服務(wù)細節(jié)，統(tǒng)一對外暴露服務(wù)接口，真正做到了“微服務(wù)”。舉個例子，我們的一個服務(wù) A，部署了 3 個備份，也就是 3 個 Pod；對于用戶來說，只需要關(guān)注一個 Service 的入口就可以，而不需要操心究竟應(yīng)該請求哪一個 Pod。優(yōu) 勢非常明顯：一方面外部用戶不需要感知因為 Pod 上服務(wù)的意外崩潰、K8S 重新拉起 Pod 而造成的 IP 變更，外部用戶也不需要感知因升級、變更服務(wù)帶來的 Pod 替換而造成的 IP 變化，另一方面，Service 還可以做流量負載均衡。

但是，Service 主要負責(zé) K8S 集群內(nèi)部的網(wǎng)絡(luò)拓撲。那么集群外部怎么訪問集群內(nèi)部呢？這個時候就需要 Ingress 了，官方文檔中的解釋是：

Ingress 是對集群中服務(wù)的外部訪問進行管理的 API 對象，典型的訪問方式是 HTTP。

ngress 可以提供負載均衡、SSL 終結(jié)和基于名稱的虛擬托管。

翻譯一下：Ingress 是整個 K8S 集群的接入層，復(fù)雜集群內(nèi)外通訊。

Ingress 和 Service 的網(wǎng)絡(luò)拓撲關(guān)系圖如下：

kubectl排查服務(wù)問題

K8S 上部署服務(wù)失敗了怎么排查？

用這個命令：

kubectl describe ${RESOURCE} ${NAME}

拉到最后看到Events部分，會顯示出 K8S 在部署這個服務(wù)過程的關(guān)鍵日志。

一般來說，通過kubectl describe pod ${POD_NAME}已經(jīng)能定位絕大部分部署失敗的問題了，當(dāng)然，具體問題還是得具體分析。

K8S 上部署的服務(wù)不正常怎么排查？

如果服務(wù)部署成功了，且狀態(tài)為running，那么就需要進入 Pod 內(nèi)部的容器去查看自己的服務(wù)日志了：

查看 Pod 內(nèi)部某個 container 打印的日志：

kubectl log ${POD_NAME} ‐c ${CONTAINER_NAME}。

進入 Pod 內(nèi)部某個 container：

kubectl exec ‐it [options] ${POD_NAME} ‐c ${CONTAINER_NAME} [args]

這個命令的作用是通過 kubectl 執(zhí)行了docker exec xxx進入到容器實例內(nèi)部。之后，就是用戶檢查自己服務(wù)的日志來定位問題。

K8S真的放棄Docker了嗎？

Docker作為非常流行的容器技術(shù)，之前經(jīng)常有文章說它被K8S棄用了，取而代之的是另一種容器技術(shù)containerd！其實containerd只是從Docker中分離出來的底層容器運行時，使用起來和Docker并沒有啥區(qū)別，從Docker轉(zhuǎn)型containerd非常簡單，基本沒有什么門檻。只要把之前Docker命令中的docker改為crictl基本就可以了，都是同一個公司出品的東西，用法都一樣。所以不管K8S到底棄用不棄用Docker，對我們開發(fā)者使用來說，基本沒啥影響！

K8S CRI

K8S發(fā)布CRI（Container Runtime Interface），統(tǒng)一了容器運行時接口，凡是支持CRI的容器運行時，皆可作為K8S的底層容器運行時。

K8S為什么要放棄使用Docker作為容器運行時，而使用containerd呢？

如果你使用Docker作為K8S容器運行時的話，kubelet需要先要通過dockershim去調(diào)用 Docker，再通過Docker去調(diào)用containerd。

如果你使用containerd作為K8S容器運行時的話，由于containerd內(nèi)置了CRI插件， kubelet可以直接調(diào)用containerd。
使用containerd不僅性能提高了（調(diào)用鏈變短了），而且資源占用也會變?。―ocker不是一個純粹的容器運行時，具有大量其他功能）。

當(dāng)然，未來Docker有可能自己直接實現(xiàn)K8S的CRI接口來兼容K8S的底層使用。

到此這篇關(guān)于K8S高級特性的文章就介紹到這了,更多相關(guān)K8S高級特性內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: