一篇文章搞懂K8S高級(jí)特性
K8S高級(jí)特性
K8S中還有一些高級(jí)特性有必要了解下,比如彈性擴(kuò)縮應(yīng)用(見(jiàn)上文)、滾動(dòng)更新(見(jiàn)上文)、配置管理、存儲(chǔ)卷、網(wǎng)關(guān)路由等。
在了解這些高級(jí)特性之前有必要先看幾個(gè)K8S的核心概念:
ReplicaSet
ReplicaSet確保任何時(shí)間都有指定數(shù)量的Pod副本在運(yùn)行。通常用來(lái)保證給定數(shù)量的、完全相同的Pod的可用性。建議使用Deployment來(lái)管理ReplicaSet,而不是直接使用。
ConfigMap
ConfigMap是一種API對(duì)象,用來(lái)將非機(jī)密性的數(shù)據(jù)保存到鍵值對(duì)中。使用時(shí),Pod可以將其用作環(huán)境變量、命令行參數(shù)或者存儲(chǔ)卷中的配置文件。使用ConfigMap可以將你的配置數(shù)據(jù)和應(yīng)用程序代碼分開(kāi)。
Volume
Volume指的是存儲(chǔ)卷,包含可被Pod中容器訪問(wèn)的數(shù)據(jù)目錄。容器中的文件在磁盤上是臨時(shí)存放的,當(dāng)容器崩潰時(shí)文件會(huì)丟失,同時(shí)無(wú)法在多個(gè)Pod中共享文件,通過(guò)使用存儲(chǔ)卷可以解決這兩個(gè)問(wèn)題。
常用的存儲(chǔ)卷有如下幾種:
- configMap:configMap卷提供了向Pod中注入配置數(shù)據(jù)的方法。ConfigMap對(duì)象中存儲(chǔ)的數(shù)據(jù)可以被configMap類型的卷引用,然后被Pod中運(yùn)行的容器化應(yīng)用使用。
- emptyDir:emptyDir卷可用于存儲(chǔ)緩存數(shù)據(jù)。當(dāng)Pod分派到某個(gè)Node上時(shí),emptyDir卷會(huì)被創(chuàng)建,并且Pod在該節(jié)點(diǎn)上運(yùn)行期間,卷一直存在。當(dāng)Pod被從節(jié)點(diǎn)上刪除時(shí)emptyDir卷中的數(shù)據(jù)也會(huì)被永久刪除。
- hostPath:hostPath卷能將主機(jī)節(jié)點(diǎn)文件系統(tǒng)上的文件或目錄掛載到你的Pod中。在Minikube中的主機(jī)指的是Minikube所在的虛擬機(jī)。
- local:local卷所代表的是某個(gè)掛載的本地設(shè)備,例如磁盤、分區(qū)或者目錄。local卷只能用作靜態(tài)創(chuàng)建的持久卷,尚不支持動(dòng)態(tài)配置。
- nfs:nfs卷能將NFS(網(wǎng)絡(luò)文件系統(tǒng))掛載到你的Pod中。
- persistentVolumeClaim:persistentVolumeClaim卷用來(lái)將持久卷(PersistentVolume)掛載到Pod中。持久卷(PV)是集群中的一塊存儲(chǔ),可以由管理員事先供應(yīng),或者使用存儲(chǔ)類(Storage Class)來(lái)動(dòng)態(tài)供應(yīng),持久卷是集群資源類似于節(jié)點(diǎn)。
Ingress
Ingress 通過(guò)K8S的Ingress資源可以實(shí)現(xiàn)類似Nginx的基于域名訪問(wèn),從而實(shí)現(xiàn)Pod的負(fù)載均衡訪問(wèn)。
安裝Ingress
進(jìn)入頁(yè)面https://github.com/kubernetes/ingress-nginx/blob/nginx-0.20.0/deploy/mandatory.yaml,將里面的內(nèi)容復(fù)制,保存到k8s master機(jī)器上的一個(gè)文件ingress-controller.yaml里,里面的鏡像地址需要修改下,大家直接用下面這個(gè)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訪問(wèn)規(guī)則(就是類似配置nginx的代理轉(zhuǎn)發(fā)配置),讓ingress將域名 tomcat.core.com轉(zhuǎn)發(fā)給后端的tomcat-service-yaml 服務(wù),新建一個(gè)文件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
在訪問(wèn)機(jī)器配置host,master目錄:/etc/hosts,在 host里增加如下host(ingress部署的機(jī)器ip對(duì)應(yīng)訪問(wèn)的域名)
192.168.159.131 tomcat.core.com 或者 192.168.159.132 tomcat.core.com
配置完后直接在客戶機(jī)瀏覽器訪問(wèn)http://tomcat.core.com/ ,能正常訪問(wèn)tomcat。
高級(jí)特性
配置管理
ConfigMap允許你將配置文件與鏡像文件分離,以使容器化的應(yīng)用程序具有可移植性。接下來(lái)我們演示下如何將ConfigMap的的屬性注入到Pod的環(huán)境變量中去。
添加配置文件nginx-config.yaml用于創(chuàng)建ConfigMap,ConfigMap名稱為nginx-config,存儲(chǔ)信息放在data節(jié)點(diǎn)下:
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
通過(guò)yaml格式查看ConfigMap中的內(nèi)容:
kubectl get configmaps nginx-config -o yaml
添加配置文件nginx-deployment.yaml用于創(chuàng)建Deployment,部署一個(gè)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 # 進(jìn)入容器控制臺(tái)執(zhí)行,下面命令 ECHO $NGINX_ENV
存儲(chǔ)卷使用
通過(guò)存儲(chǔ)卷,我們可以把外部數(shù)據(jù)掛在到容器中去,供容器中應(yīng)用訪問(wèn),這樣就算容器崩潰了,數(shù)據(jù)依然可以存在。
記得之前我們使用Docker部署Nginx的時(shí)候,將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 可以認(rèn)為是一臺(tái)虛擬機(jī),我們可以用Minikube的ssh命令來(lái)訪問(wèn)它
minikube ssh
Minikube中默認(rèn)有一個(gè)docker用戶,我們先重置下它的密碼
sudo passwd docker
在Minikube中創(chuàng)建mydata目錄
mkdir /home/docker/mydata
我們需要把nginx的目錄復(fù)制到Minikube中去,才能實(shí)現(xiàn)目錄的掛載,注意docker用戶只能修改/home/docker目錄中的文件,我們通過(guò)scp命令來(lái)復(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ù)訪問(wèn)端口
kubectl get services
通過(guò)CURL命令訪問(wèn)Nginx首頁(yè)信息。
總結(jié)
Service是K8S服務(wù)的核心,屏蔽了服務(wù)細(xì)節(jié),統(tǒng)一對(duì)外暴露服務(wù)接口,真正做到了“微服務(wù)”。舉個(gè)例子,我們的一個(gè)服務(wù) A,部署了 3 個(gè)備份,也就是 3 個(gè) Pod;對(duì)于用戶來(lái) 說(shuō),只需要關(guān)注一個(gè) Service 的入口就可以,而不需要操心究竟應(yīng)該請(qǐng)求哪一個(gè) Pod。優(yōu) 勢(shì)非常明顯:一方面外部用戶不需要感知因?yàn)?Pod 上服務(wù)的意外崩潰、K8S 重新拉起 Pod 而造成的 IP 變更,外部用戶也不需要感知因升級(jí)、變更服務(wù)帶來(lái)的 Pod 替換而造成的 IP 變化,另一方面,Service 還可以做流量負(fù)載均衡。
但是,Service 主要負(fù)責(zé) K8S 集群內(nèi)部的網(wǎng)絡(luò)拓?fù)?/strong>。那么集群外部怎么訪問(wèn)集群內(nèi)部呢?這個(gè)時(shí)候就需要 Ingress 了,官方文檔中的解釋是:
Ingress 是對(duì)集群中服務(wù)的外部訪問(wèn)進(jìn)行管理的 API 對(duì)象,典型的訪問(wèn)方式是 HTTP。
ngress 可以提供負(fù)載均衡、SSL 終結(jié)和基于名稱的虛擬托管。
翻譯一下:Ingress 是整個(gè) K8S 集群的接入層,復(fù)雜集群內(nèi)外通訊。
Ingress 和 Service 的網(wǎng)絡(luò)拓?fù)潢P(guān)系圖如下:
kubectl排查服務(wù)問(wèn)題
K8S 上部署服務(wù)失敗了怎么排查?
用這個(gè)命令:
kubectl describe ${RESOURCE} ${NAME}
拉到最后看到Events部分,會(huì)顯示出 K8S 在部署這個(gè)服務(wù)過(guò)程的關(guān)鍵日志。
一般來(lái)說(shuō),通過(guò)kubectl describe pod ${POD_NAME}已經(jīng)能定位絕大部分部署失敗的問(wèn)題 了,當(dāng)然,具體問(wèn)題還是得具體分析。
K8S 上部署的服務(wù)不正常怎么排查?
如果服務(wù)部署成功了,且狀態(tài)為running,那么就需要進(jìn)入 Pod 內(nèi)部的容器去查看自己的服 務(wù)日志了:
查看 Pod 內(nèi)部某個(gè) container 打印的日志:
kubectl log ${POD_NAME} ‐c ${CONTAINER_NAME}。
進(jìn)入 Pod 內(nèi)部某個(gè) container:
kubectl exec ‐it [options] ${POD_NAME} ‐c ${CONTAINER_NAME} [args]
這個(gè)命令的作用是通過(guò) kubectl 執(zhí)行了docker exec xxx進(jìn)入到容器實(shí)例內(nèi)部。之后,就是 用戶檢查自己服務(wù)的日志來(lái)定位問(wèn)題。
K8S真的放棄Docker了嗎?
Docker作為非常流行的容器技術(shù),之前經(jīng)常有文章說(shuō)它被K8S棄用了,取而代之的是另一 種容器技術(shù)containerd!其實(shí)containerd只是從Docker中分離出來(lái)的底層容器運(yùn)行時(shí),使 用起來(lái)和Docker并沒(méi)有啥區(qū)別,從Docker轉(zhuǎn)型containerd非常簡(jiǎn)單,基本沒(méi)有什么門檻。 只要把之前Docker命令中的docker改為crictl基本就可以了,都是同一個(gè)公司出品的東西, 用法都一樣。所以不管K8S到底棄用不棄用Docker,對(duì)我們開(kāi)發(fā)者使用來(lái)說(shuō),基本沒(méi)啥影響!
K8S CRI
K8S發(fā)布CRI(Container Runtime Interface),統(tǒng)一了容器運(yùn)行時(shí)接口,凡是支持CRI的 容器運(yùn)行時(shí),皆可作為K8S的底層容器運(yùn)行時(shí)。
K8S為什么要放棄使用Docker作為容器運(yùn)行時(shí),而使用containerd呢?
如果你使用Docker作為K8S容器運(yùn)行時(shí)的話,kubelet需要先要通過(guò)dockershim去調(diào)用 Docker,再通過(guò)Docker去調(diào)用containerd。
如果你使用containerd作為K8S容器運(yùn)行時(shí)的話,由于containerd內(nèi)置了CRI插件, kubelet可以直接調(diào)用containerd。
使用containerd不僅性能提高了(調(diào)用鏈變短了),而且資源占用也會(huì)變?。―ocker不是 一個(gè)純粹的容器運(yùn)行時(shí),具有大量其他功能)。
當(dāng)然,未來(lái)Docker有可能自己直接實(shí)現(xiàn)K8S的CRI接口來(lái)兼容K8S的底層使用。
到此這篇關(guān)于K8S高級(jí)特性的文章就介紹到這了,更多相關(guān)K8S高級(jí)特性內(nèi)容請(qǐng)搜索本站以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持本站!
版權(quán)聲明:本站文章來(lái)源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有,歡迎引用、轉(zhuǎn)載,請(qǐng)保持原文完整并注明來(lái)源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站,禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像,否則將依法追究法律責(zé)任。本站部分內(nèi)容來(lái)源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來(lái),僅供學(xué)習(xí)參考,不代表本站立場(chǎng),如有內(nèi)容涉嫌侵權(quán),請(qǐng)聯(lián)系alex-e#qq.com處理。