一篇文章搞懂K8S高級特性
K8S高級特性
K8S中還有一些高級特性有必要了解下，比如彈性擴(kuò)縮應(yīng)用（見上文）、滾動更新（見上文）、配置管理、存儲卷、網(wǎng)關(guān)路由等。
在了解這些高級特性之前有必要先看幾個(gè)K8S的核心概念：
ReplicaSet
ReplicaSet確保任何時(shí)間都有指定數(shù)量的Pod副本在運(yùn)行。通常用來保證給定數(shù)量的、完全相同的Pod的可用性。建議使用Deployment來管理ReplicaSet，而不是直接使用。
ConfigMap
ConfigMap是一種API對象，用來將非機(jī)密性的數(shù)據(jù)保存到鍵值對中。使用時(shí)，Pod可以將其用作環(huán)境變量、命令行參數(shù)或者存儲卷中的配置文件。使用ConfigMap可以將你的配置數(shù)據(jù)和應(yīng)用程序代碼分開。
Volume
Volume指的是存儲卷，包含可被Pod中容器訪問的數(shù)據(jù)目錄。容器中的文件在磁盤上是臨時(shí)存放的，當(dāng)容器崩潰時(shí)文件會丟失，同時(shí)無法在多個(gè)Pod中共享文件，通過使用存儲卷可以解決這兩個(gè)問題。
常用的存儲卷有如下幾種：
- configMap：configMap卷提供了向Pod中注入配置數(shù)據(jù)的方法。ConfigMap對象中存儲的數(shù)據(jù)可以被configMap類型的卷引用，然后被Pod中運(yùn)行的容器化應(yīng)用使用。
- emptyDir：emptyDir卷可用于存儲緩存數(shù)據(jù)。當(dāng)Pod分派到某個(gè)Node上時(shí)，emptyDir卷會被創(chuàng)建，并且Pod在該節(jié)點(diǎn)上運(yùn)行期間，卷一直存在。當(dāng)Pod被從節(jié)點(diǎn)上刪除時(shí)emptyDir卷中的數(shù)據(jù)也會被永久刪除。
- hostPath：hostPath卷能將主機(jī)節(jié)點(diǎn)文件系統(tǒng)上的文件或目錄掛載到你的Pod中。在Minikube中的主機(jī)指的是Minikube所在的虛擬機(jī)。
- local：local卷所代表的是某個(gè)掛載的本地設(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é)點(diǎn)。
Ingress
Ingress 通過K8S的Ingress資源可以實(shí)現(xiàn)類似Nginx的基于域名訪問，從而實(shí)現(xiàn)Pod的負(fù)載均衡訪問。
安裝Ingress
進(jìn)入頁面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訪問規(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
在訪問機(jī)器配置host，master目錄：/etc/hosts，在 host里增加如下host(ingress部署的機(jī)器ip對應(yīng)訪問的域名)
192.168.159.131 tomcat.core.com 或者 192.168.159.132 tomcat.core.com
配置完后直接在客戶機(jī)瀏覽器訪問http://tomcat.core.com/ ，能正常訪問tomcat。
高級特性
配置管理
ConfigMap允許你將配置文件與鏡像文件分離，以使容器化的應(yīng)用程序具有可移植性。接下來我們演示下如何將ConfigMap的的屬性注入到Pod的環(huán)境變量中去。
添加配置文件nginx-config.yaml用于創(chuàng)建ConfigMap，ConfigMap名稱為nginx-config，存儲信息放在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
通過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)入容器控制臺執(zhí)行，下面命令 ECHO $NGINX_ENV
存儲卷使用
通過存儲卷，我們可以把外部數(shù)據(jù)掛在到容器中去，供容器中應(yīng)用訪問，這樣就算容器崩潰了，數(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)為是一臺虛擬機(jī)，我們可以用Minikube的ssh命令來訪問它
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目錄中的文件，我們通過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ù)細(xì)節(jié)，統(tǒng)一對外暴露服務(wù)接口，真正做到了“微服務(wù)”。舉個(gè)例子，我們的一個(gè)服務(wù) A，部署了 3 個(gè)備份，也就是 3 個(gè) Pod；對于用戶來 說，只需要關(guān)注一個(gè) Service 的入口就可以，而不需要操心究竟應(yīng)該請求哪一個(gè) Pod。優(yōu) 勢非常明顯：一方面外部用戶不需要感知因?yàn)?Pod 上服務(wù)的意外崩潰、K8S 重新拉起 Pod 而造成的 IP 變更，外部用戶也不需要感知因升級、變更服務(wù)帶來的 Pod 替換而造成的 IP 變化，另一方面，Service 還可以做流量負(fù)載均衡。
但是，Service 主要負(fù)責(zé) K8S 集群內(nèi)部的網(wǎng)絡(luò)拓?fù)?/strong>。那么集群外部怎么訪問集群內(nèi)部呢？這個(gè)時(shí)候就需要 Ingress 了，官方文檔中的解釋是：
Ingress 是對集群中服務(wù)的外部訪問進(jìn)行管理的 API 對象，典型的訪問方式是 HTTP。
ngress 可以提供負(fù)載均衡、SSL 終結(jié)和基于名稱的虛擬托管。
翻譯一下：Ingress 是整個(gè) K8S 集群的接入層，復(fù)雜集群內(nèi)外通訊。
Ingress 和 Service 的網(wǎng)絡(luò)拓?fù)潢P(guān)系圖如下：
kubectl排查服務(wù)問題
K8S 上部署服務(wù)失敗了怎么排查？
用這個(gè)命令：
kubectl describe ${RESOURCE} ${NAME}
拉到最后看到Events部分，會顯示出 K8S 在部署這個(gè)服務(wù)過程的關(guān)鍵日志。
一般來說，通過kubectl describe pod ${POD_NAME}已經(jīng)能定位絕大部分部署失敗的問題 了，當(dāng)然，具體問題還是得具體分析。
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è)命令的作用是通過 kubectl 執(zhí)行了docker exec xxx進(jìn)入到容器實(shí)例內(nèi)部。之后，就是 用戶檢查自己服務(wù)的日志來定位問題。
K8S真的放棄Docker了嗎？
Docker作為非常流行的容器技術(shù)，之前經(jīng)常有文章說它被K8S棄用了，取而代之的是另一 種容器技術(shù)containerd！其實(shí)containerd只是從Docker中分離出來的底層容器運(yùn)行時(shí)，使 用起來和Docker并沒有啥區(qū)別，從Docker轉(zhuǎn)型containerd非常簡單，基本沒有什么門檻。 只要把之前Docker命令中的docker改為crictl基本就可以了，都是同一個(gè)公司出品的東西， 用法都一樣。所以不管K8S到底棄用不棄用Docker，對我們開發(fā)者使用來說，基本沒啥影響！
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需要先要通過dockershim去調(diào)用 Docker，再通過Docker去調(diào)用containerd。
如果你使用containerd作為K8S容器運(yùn)行時(shí)的話，由于containerd內(nèi)置了CRI插件， kubelet可以直接調(diào)用containerd。
使用containerd不僅性能提高了（調(diào)用鏈變短了），而且資源占用也會變?。―ocker不是 一個(gè)純粹的容器運(yùn)行時(shí)，具有大量其他功能）。
當(dāng)然，未來Docker有可能自己直接實(shí)現(xiàn)K8S的CRI接口來兼容K8S的底層使用。
到此這篇關(guān)于K8S高級特性的文章就介紹到這了,更多相關(guān)K8S高級特性內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
在Kubernetes集群中,Node狀態(tài)為NotReady通常意味著節(jié)點(diǎn)上存在某些問題,解決Node節(jié)點(diǎn)NotReady狀態(tài)的步驟包括檢查節(jié)點(diǎn)日志、容器運(yùn)行時(shí)狀態(tài)、網(wǎng)絡(luò)組件、節(jié)點(diǎn)資源、節(jié)點(diǎn)與控制平面的通信,本文介紹解決K8S中Node狀態(tài)為NotReady的步驟,感興趣的朋友一起看看吧2025-03-03
k8s入門實(shí)戰(zhàn)deployment使用詳解
這篇文章主要為大家介紹了k8s入門實(shí)戰(zhàn)deployment使用詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪2023-03-03
這篇文章主要介紹了kubectl?命令的相關(guān)資料,包括常用命令,基本命令和使用說明,本文給大家介紹的非常詳細(xì),感興趣的朋友一起看看吧2025-04-04
在Kubernetes集群中搭建Istio微服務(wù)網(wǎng)格的過程詳解
這篇文章主要介紹了在Kubernetes集群中搭建Istio微服務(wù)網(wǎng)格,我們采用default配置檔部署istio網(wǎng)格，istioctl?install命令不指定任何配置檔默認(rèn)就是呀default配置檔，需要的朋友可以參考下2022-05-05
Kubernetes教程之Windows?HostProcess?運(yùn)行容器化負(fù)載
這篇文章主要介紹了Kubernetes?Windows?HostProcess?運(yùn)行容器化負(fù)載,本篇內(nèi)容還是比較多的，總共包含了?Windows?HostProcess的創(chuàng)建、為?Windows?Pod?和容器配置?GMSA?和?Windows?的?Pod?和容器配置?RunAsUserName三大功能模塊，需要的朋友可以參考下2022-07-07
ES業(yè)務(wù)數(shù)據(jù)遷移遇到的精度問題BUG
這篇文章主要為大家介紹了ES業(yè)務(wù)數(shù)據(jù)遷移遇到的BUG精度問題，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪2022-06-06
Kubernetes是google開源的容器編排工具,本質(zhì)是一組服務(wù)器集群,在集群的各個(gè)節(jié)點(diǎn)上運(yùn)行程序來進(jìn)行容器進(jìn)行管理,最終實(shí)現(xiàn)資源管理智能化、自動化,這篇文章主要介紹了Kubernetes組件和架構(gòu)簡介,需要的朋友可以參考下2023-09-09
本次部署方式為setafulset的方式部署rabbitmq集群，使用svc的無頭服務(wù)，本次涉及使用到的服務(wù)有setafulset、secret、configmap、service、pv、pvc、sa，在rabbitmq的官網(wǎng)中使用的是operator的方式，感興趣的朋友一起看看吧2024-03-03
k8s整合istio配置gateway入口、配置集群內(nèi)部服務(wù)調(diào)用管理(最新推薦)
這篇文章主要介紹了k8s整合istio配置gateway入口、配置集群內(nèi)部服務(wù)調(diào)用管理,本文給大家介紹的非常詳細(xì)，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值，需要的朋友可以參考下2023-08-08
Rainbond應(yīng)用分享與發(fā)布官方文檔說明
這篇文章主要為大家介紹了Rainbond應(yīng)用分享與發(fā)布的官方文檔說明，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪2022-04-04