Kubernetes(K8S)入门到运维 ( 四 ) > 网络与存储
Kubernetes(K8S)网络ServiceService即SVC。一个Pod的逻辑分组，一种可以访问它们的策略，通常称为微服务，这一组Pod能够被Service访问到，通常是通过Label Selector。如果Pod挂了，此时新建一个的Pod，此时的网络可能改变了，此时的Nginx在履行IP地址还是旧的IP地址，而SVC则是相当于一个路由器的作用，会记录内部匹配...
Kubernetes(K8S)网络
Service
Service即SVC。一个Pod的逻辑分组，一种可以访问它们的策略，通常称为微服务，这一组Pod能够被Service访问到，通常是通过Label Selector。
如果Pod挂了，此时新建一个的Pod，此时的网络可能改变了，此时的Nginx在履行IP地址还是旧的IP地址，而SVC则是相当于一个路由器的作用，会记录内部匹配到的Pod的地址，而Nginx的访问是访问SVC，而SVC相当于做转发，即类路由器功能。
注意：Service能够提供负载均衡的能力，但使用上有限制的， Service只提供4层负载均衡能力，即只能通过IP和端口进行转发。而没有7层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上4层负载均衡是不支持的。
Service的类型：
Service在K8S中有四种类型：
ClusterIP：默认类型，自动分配一个仅集群内部可以访问的虚拟IP。
NodePort：在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过NodePort来访问该服务。NodePort的原理在于在Node上开了一个端口，将向该端口的流量导入到kube-proxy，然后由kube-proxy进一步给到对应的Pod
LoadBalancer：在NodePort的基础上，借助Cloud Provider创建一个外部负载均衡器，并将请求转发到NodePort，即比NodePort多了一步，就是可以调用Cloud Provider去创建LoadBalancer来向节点导流，但这个服务需要花钱，因这个服务是提供商提供的叫LAPS，根据流量收费的。
ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有K8S 1.7或更高版本的kube-dns才支持。
VIP（虚拟IP）和Service代理：
在K8S集群中，每个Node运行一个kube-proxy进程，kube-proxy负责为Service实现一种VIP（虚拟IP）的形式，而不是ExternalName的形式。
在K8S V1.0版本，代理完全在userspace。在K8S V1.1版本新增了IPTables代理，但并不是默认的运行模式；从K8S V1.2起，默认就是IPTables代理；在K8S V1.8中，添加了IPVS代理；在K8S V1.14版本中，默认就使用IPVS代理。
K8S V1.0版本中，Service是4层（TCP/IP OverIP）概念，在K8S V1.1版本，新增了Ingress API，用来表示7层（Http）服务。
为什么不使用Round-Robin DNS？
DNS最大的特点是都会产生缓存，因此负载均衡就不在进行负载均衡了，继而只能作为辅助。
代理模式的分类：
userspace代理模式
iptables代理模式
ipvs代理模式
这种模式，kube-proxy会监视K8S Service对象和EndPoints，调用netlink接口以相应的创建ipvs规则并定期与K8S Service对象和EndPoints对象同步ipvs规则，以确保ipvs状态与期望一致。访问服务时，流量将被重定向到其中一个后端Pod。
与iptables类似，ipvs与netfilter的hook功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着ipvs可以更快的重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs为负载均衡算法提供了更多的选项：rr轮询调度；lc最小连接数；dh目标哈希；sh源哈希；sed最短期望延迟；nq不排队调度；
注意：ipvs模式假定运行在kube-proxy之前，在节点都安装了ipvs内核模块。当kube-proxy以ipvs代理模式启动时，kube-proxy将验证节点上是否安装了ipvs模块，如果未安装，则kube-proxy将回退到IPTables代理模式。
| #查看 ipvsadm -L
#查看对应的地址 kubectl get svc |
ClusterIP
ClusterIP主要在每个Node节点使用iptables，将发向ClusterIP对应端口的数据，转发到kube-proxy中，然后kube-proxy自己内部实现现有负载均衡的方法，并可以查询到这个Service下对应Pod的地址和端口，进而把数据转发给对应的Pod的地址和端口。
实现上图的功能，需要几个组件共同工作：
APIServer用户通过kubectl命令向APIServer发送创建Service命令，APIServer接收到请求后将数据存储到Etcd中。
K8S中每个节点都会有一个叫kube-proxy的进程，这个进程负责感知Service，Pod的变化，并将变化信息写入本地的IPTables规则中。
| vi svc-deploy.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 #api版本 apiVersion: apps/v1 #资源 kind: Deployment metadata: #运行名称 name: myapp-deploy #名称空间 namespace: default spec: #副本 replicas: 3 #选择器 selector: #规则 matchLabels: app: myapp release: stable #运行的Job template: metadata: #标签 labels: app: myapp release: stable env: test spec: #容器 containers: #容器名称 - name: myapp image: levi.harbor.com/library/nginx:1.9.1 imagePullPolicy: IfNotPresent #端口 ports: - name: http containerPort: 80
〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f svc-deploy.yaml
#每一个Pod都会有自己的Pod，并且Pod死亡后Pod的地址和之前是不一致的，要进行可靠性的访问需要借助SVC kubectl get pod -o wide
curl 地址
#service信息 vi svc.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 #api版本 apiVersion: v1 #资源 kind: Service metadata: #资源运行名称 name: mysvc #名称空间 namespace: default spec: #类型 type: ClusterIP #SVC想要匹配到Pod的话是使用标签选择器的，此处是按照选择器选中的资源进行选中 selector: app: myapp release: stable #端口 ports: - name: http #端口 port: 80 #容器端口 targetPort: 80 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f svc.yaml
kubectl get svc
#访问成功 curl IP
ipvsadm -L
kubectl get pod -o wide
#把标签修改到和svc-deploy.yaml的标签一致就可以匹配了 kubectl delete -f svc.yaml
#修改selector下的标签（myapp1、stable1） vi svc.yaml
kubectl apply -f svc.yaml
kubectl get svc
#访问不到，因为只是创建了自己的端点，并没有实际的后端端点 curl IP
ipvsadm -L
kubectl get pod |
Headless Service：
有时不需要或不想要负载均衡，以及单独的ServiceIP。遇到这种情况，可以通过指定Cluster IP（spec.clusterIP）的值为None来创建Headless Service。这类Service并不会分配ClusterIP，kube-proxy不会处理它们，而且平台也不会为它们进行负载均衡和路由。
这也是一种Cluster，只是一种特殊的ClusterIP。
| vi svc-none.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: v1 #资源类型 kind: Service metadata: #运行名 name: myapp-headless namespace: default spec: #选中标签 selector: app: myapp clusterIP: "None" #端口映射配置 ports: - port: 80 targetPort: 80 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f svc-none.yaml
kubectl get svc
#SVC会有一个主机名，这个写入的规则就是SVC名称+名称空间+集群域名 kubectl get pod -n kebe-system
#安装解析工具 yum -y install bind-utils
#查看coredns-xxx的IP地址 kubectl get pod -n kube-system -o wide
#解析这个域名，在kubectl get pod -n kube-system中可以看到 dig -t A SVC名称+名称空间+集群域名 @地址
#查看ANSWER SECTION:这一栏解析出来的地址 dig -t A myapp-headless.default.svc.cluster.local. @10.244.0.4
#和ANSWER SECTION:的地址进行校对 #虽然没有了IP，但是可以通过访问域名的方案进行访问 kubectl get pod -o wide
ipvsadm -L |
NodePort
| #NodePort的原理在于在Node上开了一个端口，将向该端口的流量导入到kube-proxy，然后由kube-proxy进一步给到对应的Pod vi nodeport.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: v1 #资源 kind: Service metadata: #运行名称 name: myapp namespace: default spec: type: NodePort #标签选择器，选择要为此服务的Pod selector: app: myapp release: stable #端口映射 ports: - name: http port: 80 targetPort: 80 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f nodeport.yaml
#对应的是一组标签 kubectl get pod --show-labels -o wide
#可以访问所在Node的IP地址 + 端口即可 kubectl get svc
#使用浏览器访问http://192.168.70.110 ~ 112:32570/（三台机器都可以）
#可以在三台机器都可以看到都有这么个端点信息 netstat -anpt | grep :32570
#查看规则 ipvsadm -L |
ExternalName
| #ExternalName这种类型的Service返回CNAME和它的值，可以将服务映射到externalName字段的内容（如：levi.svc.com）。如这个K8S Service的特例，它没有selector，也没有定义任何的端口和Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务。
vi ex.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: v1 #资源 kind: Service metadata: #运行名称 name: myservice namespace: default spec: type: ExternalName externalName: levi.svc.com 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 kubectl create -f ex.yaml
kubectl get svc
#查看coredns-xxx的地址 kubectl get pod -o wide -n kube-system
dig -t A SVC名称+名称空间+集群域名 @地址
#ANSWER SECTION:相当于做了个DNS别名，将Web服务引入集群内部 dig -t A myservice.default.svc.cluster.local. @10.244.0.3
#当查询主机myservice.default.svc.cluster.local.(SVC_NAME.NAMESPACE.svc.cluster.local)时，集群的DNS服务将返回一个值my.database.example.com的CNAME记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在DNS层，而且不会进行代理或转发 |
Service Ingress
Ingress就是提供一个7层的Http访问的解决方案，而实现这种方案的方式有很多。
场景就是对内的集群不是采用Http链接，对外采用Http链接。
我们采用Ingress Nginx的解决方案。
Ingress-Nginx github 地址：https://github.com/kubernetes/ingress-nginx
Ingress-Nginx 官方网站：https://kubernetes.github.io/ingress-nginx/
Nginx常用的访问方式还是NodePort部署方案，这样Nginx就会把内部服务暴露给外部。
Ingress-Nginx其实就是创建一个SVC与Nginx与之关联，在被Ingress链接进去，即以往需要修改Nginx配置文件，此时会自动添加进去。具体过程如上图。
安装Ingress
| #获取到配置文件 mkdir /usr/local/kubernetes/plugin/ingress
cd /usr/local/kubernetes/plugin/ingress
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml
cat mandatory.yaml | grep image
#使用阿里云的镜像仓库，也可以修改配置文件 docker pull registry.aliyuncs.com/google_containers/nginx-ingress-controller:0.26.1 docker tag registry.aliyuncs.com/google_containers/nginx-ingress-controller:0.26.1 quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.26.1
kubectl apply -f /usr/local/kubernetes/plugin/ingress/mandatory.yaml
kubectl apply -f mandatory.yaml
kubectl get pod -n ingress-nginx -o wide
#暴露方案：Bare-metal：https://kubernetes.github.io/ingress-nginx/deploy/
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/baremetal/service-nodeport.yaml
kubectl apply -f service-nodeport.yaml
kubectl get svc -n ingress-nginx |
实验：
| #deloyment和Service vi ingress.http.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: extensions/v1beta1 #资源 kind: Deployment metadata: #运行名称 name: nginx-dm spec: #运行副本数 replicas: 2 #运行的Pod template: metadata: #标签 labels: name: nginx spec: #容器 containers: - name: nginx image: levi.harbor.com/library/nginx:1.9.1 #镜像拉取策略 imagePullPolicy: IfNotPresent ports: - containerPort: 80 --- apiVersion: v1 #资源类型 kind: Service metadata: #运行名 name: nginx-svc spec: #端口 ports: - port: 80 targetPort: 80 protocol: TCP #应用选择器 selector: name: nginx 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 kubectl apply -f ingress.http.yaml
kubectl get deployment
kubectl get rs
kubectl get pod
kubectl get svc
curl IP
#实现Nginx-Ingress暴露方案，实现访问效果 vi ingress.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: extensions/v1beta1 #资源 kind: Ingress metadata: #运行名 name: nginx-test spec: #规则 rules: #访问域名 - host: www.leviigress.com #访问协议 http: #路径 paths: - path: / backend: #服务名 serviceName: nginx-svc #端口 servicePort: 80 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f ingress.yaml
#修改本地host文件，访问地址为ingress.yaml配置地址，即192.168.70.110 www.leviigress.com
#查看Ingress的端口 kubectl get svc -n ingress-nginx
#浏览器访问https://www.leviigress.com:31224/
kubectl get svc
kubectl deelte svc --all
kubectl delete deployment –all
#2个域名的访问方案，访问到不同的地址 vi ingress-http-two.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 #=============== 第一个 Start apiVersion: extensions/v1beta1 #资源 kind: Deployment metadata: #运行名称 name: nginx-dm1 spec: #Pod运行副本 replicas: 2 #运行的Pod template: metadata: #标签 labels: name: nginx1 spec: #容器 containers: - name: nginx image: levi.harbor.com/library/nginx:1.9.1 #镜像拉取策略 imagePullPolicy: IfNotPresent #端口 ports: - containerPort: 80 --- apiVersion: v1 #资源类型 kind: Service metadata: #运行 name: nginx-svc1 spec: #端口 ports: #外部访问端口 - port: 80 #外部访问端口映射到内部的端口 targetPort: 80 protocol: TCP #选择器 selector: name: nginx1 #=============== 第一个 End
#=============== 第二个 Start --- apiVersion: extensions/v1beta1 #资源 kind: Deployment metadata: #运行名称 name: nginx-dm2 spec: #Pod运行副本 replicas: 2 #运行的Pod template: metadata: #标签 labels: name: nginx2 spec: #容器 containers: - name: nginx image: levi.harbor.com/library/nginx:1.9.1 #镜像拉取策略 imagePullPolicy: IfNotPresent #端口 ports: - containerPort: 80 --- apiVersion: v1 #资源类型 kind: Service metadata: #运行 name: nginx-svc2 spec: #端口 ports: #外部访问端口 - port: 80 #外部访问端口映射到内部的端口 targetPort: 80 protocol: TCP #选择器 selector: name: nginx2
#=============== 第二个 End 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f ingress-http-two.yaml
kubectl get deployment
kubectl get rs
kubectl get pod
kubectl get svc
#Ingress规则 vi ingress-rule-two.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: extensions/v1beta1 #资源 kind: Ingress metadata: #运行 name: nginx-test1 spec: #规则 rules: #访问域名 - host: www.leviigress1.com #访问协议 http: #路径 paths: - path: / backend: #服务名 serviceName: nginx-svc1 servicePort: 80 --- apiVersion: extensions/v1beta1 kind: Ingress metadata: #运行 name: nginx-test1 spec: #规则 rules: #访问域名 - host: www.leviigress2.com #访问协议 http: #路径 paths: - path: / backend: #服务名 serviceName: nginx-svc2 servicePort: 80 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f ingress-rule-two.yaml
#修改本地host文件，访问地址为ingress.yaml配置地址，即192.168.70.110 www.leviigress1.com、192.168.70.110 www.leviigress2.com
#查看Ingress的端口 kubectl get svc -n ingress-nginx
#浏览器访问https://www.leviigress1.com:31224/、https://www.leviigress2.com:31224/
#查询pod的容器名 kubectl get pod -n ingress-nginx
#进入容器 kubectl exec 容器名 -n ingress-nginx -it -- /bin/bash #查看配置文件，配置规则是自动注入的，可以看到Ingress会把规则自动转换 cat /etc/nginx/nginx.conf cat /etc/nginx/nginx.conf | grep www
#Ingress Https代理访问 #创建证书，看文件 openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=nginxsvc/O=nginxsvc"
kubectl create secret tls tls-secret --key tls.key --cert tls.crt
#创建对应的deployment、service、ingress的yaml文件
#直接复制Ingress HTTP代理访问的deployment、service即可 vi deployment3.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: extensions/v1beta1 #资源 kind: Deployment metadata: #运行名称 name: nginx-dm spec: #运行副本数 replicas: 2 #运行的Pod template: metadata: #标签 labels: name: nginx spec: #容器 containers: - name: nginx image: levi.harbor.com/library/nginx:1.9.1 #镜像拉取策略 imagePullPolicy: IfNotPresent ports: - containerPort: 80 --- apiVersion: v1 #资源类型 kind: Service metadata: #运行名 name: nginx-svc spec: #端口 ports: - port: 80 targetPort: 80 protocol: TCP #应用选择器 selector: name: nginx 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f deployment3.yaml
kubectl get svc
curl IP
vi https-ingress.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 #资源 kind: Ingress metadata: name: nginx-test spec: tls: - hosts: - www.levi.com #使用已建立的证书 secretName: tls-secret rules: #访问域名 - host: www.levi.com #访问协议 http: #访问域名 paths: - path: / #Ingress绑定的SVC backend: serviceName: nginx-svc servicePort: 80 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
#修改域名，2处 kubectl apply -f https-ingress.yaml
kubectl get svc -n ingress-nginx
#添加hosts，浏览器访问192.168.70.110 www.levi.com，https://www.levi.com:31224/
# Nginx进行BasicAuth #Nginx的认证是使用Apache的，因此Master需要安装 yum -y install httpd
#输入对应的密码，要记住，后面页面访问时需要用到 htpasswd -c auth levi
kubectl create secret generic basic-auth --from-file=auth
#使用刚上面的测试deployment3.yaml
vi basicauth.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: extensions/v1beta1 #资源 kind: Ingress metadata: #运行 name: ingress-with-auth annotations: nginx.ingress.kubernetes.io/auth-type: basic nginx.ingress.kubernetes.io/auth-secret: basic-auth nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required - levi' spec: #规则 rules: #访问域名 - host: www.levi1.com #访问协议 http: #访问路径 paths: - path: / #关联的SVC backend: serviceName: nginx-svc servicePort: 80 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 kubectl apply -f basicauth.yaml
kubectl get svc -n ingress-nginx
#添加hosts，192.168.70.110 www.levi1.com，浏览器访问https://www.levi1.com:31224/ #输入刚配置的密码
#测试Nginx进行重写 #修改对应的nginx.ingress.kubernetes.io/rewrite-target:域名，跳转到别的地址中，如百度
#使用刚上面的测试deployment3.yaml
vi nginx-rewrite.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 #资源 kind: Ingress metadata: name: nginx-test annotations: #跳转到这个目标地址 nginx.ingress.kubernetes.io/rewrite-target: https://www.baidu.com/ spec: #规则 rules: - host: www.levi2.com #访问协议 http: paths: - path: / #绑定的SVC backend: serviceName: nginx-svc servicePort: 80 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f nginx-rewrite.yaml
kubectl get svc -n ingress-nginx
#添加hosts（192.168.70.110 www.levi2.com），浏览器访问https://www.levi2.com:31224/
kubectl delete ingress --all |
Kubernetes(K8S)存储
ConfigMap
ConfigMap是在K8S V1.2引入的，许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息，提供了向容器中注入配置信息的几只，ConfigMap可以被用来保存单个属性，也可以用来保存整个配置文件或者JSON二进制大对象。类似配置文件的注册中心。
ConfigMap创建方式：目录、文件、字面值。
实验：
| #目录创建 mkdir configmap
#复制内容 vi game.properties 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 enemies=aliens lieves=3 enemies.cheat=true enemies.cheat.level=noGoodRotten secret.code.passphrase=UUDDLRLRBABAS secret.code.allowed=true secret.code.leves=30 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
vi ui.properties 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 color.good=purple color.bad=yellow allow.textmode=true how.nice.to.look=fairlyNice 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
#--from-file这个参数可以使用多次，可以使用两次分别指定上个实例中的那两个配置文件，效果就跟指定整个目录是一样的 kubectl create configmap game-config --from-file=../configmap/
kubectl get cm
kubectl get cm game-config
#data:栏 kubectl get cm game-config -o yaml
kubectl describe cm game-config
kubectl delete cm --all
#文件创建 kubectl create configmap game-config --from-file=../configmap/game.properties
kubectl get configmaps game-config -o yaml
kubectl describe configmap game-config
#字面值创建 kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
kubectl get cm
kubectl describe configmap special-config
#Pod中使用ConfigMap #1.使用ConfigMap来替代环境变量 kubectl get cm
#第一个文本 vi special.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: v1 #资源类型 kind: ConfigMap metadata: #运行名称 name: special-config namespace: default data: special.how: very special.type: test 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 kubectl apply -f special.yaml
kubectl get cm
kubectl describe cm special-config
#第二个文本 vi env.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: v1 #资源 kind: ConfigMap metadata: name: env-config namespace: default data: log_level: INFO 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 kubectl apply -f env.yaml
kubectl get cm
kubectl describe cm env-config
#第三个文本 vi pod.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: v1 #资源 kind: Pod metadata: name: data-test-pod spec: #容器 containers: - name: test-container image: levi.harbor.com/library/nginx:1.9.1 command: ["/bin/sh","-c","env"] #环境变量 env: - name: SPECIAL_LEVEL_KEY #环境变量来源 valueFrom: configMapKeyRef: name: special-config key: special.how - name: SPECIAL_TYPE_KEY #环境变量来源 valueFrom: configMapKeyRef: name: special-config key: special.type #设置环境变量来源的引用 envFrom: - configMapRef: name: env-config #重启策略 restartPolicy: Never 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f pod.yaml
kubectl get pod
#关注对应的环境变量 kubectl log pod名
#====== 使用configMap设置命令行参数
#还是使用special.yaml和env.yaml
vi pod1.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: v1 #资源 kind: Pod metadata: name: data-test-pod2 spec: #容器 containers: - name: test-container2 image: levi.harbor.com/library/nginx:1.9.1 command: ["/bin/sh","-c","echo $(SPECIAL_LEVEL_KEY) and $(SPECIAL_TYPE_KEY)"] #环境变量 env: - name: SPECIAL_LEVEL_KEY #环境变量来源 valueFrom: configMapKeyRef: name: special-config key: special.how - name: SPECIAL_TYPE_KEY #环境变量来源 valueFrom: configMapKeyRef: name: special-config key: special.type #设置环境变量来源的引用 envFrom: - configMapRef: name: env-config #重启策略 restartPolicy: Never 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f pod1.yaml
kubectl get pod
kubectl log pod名
#通过数据卷插件使用ConfigMap #在数据卷里面使用这个ConfigMap，有不同的选项，最基本的就是将文件填入数据卷，在这个文件中，键就是文件名，键值就是文件内容
#还是使用special.yaml和env.yaml
vi pod2.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: v1 #资源 kind: Pod metadata: name: data-test-pod3 spec: containers: - name: test-container3 image: levi.harbor.com/library/nginx:1.9.1 command: ["/bin/sh","-c","cat /etc/config/special.how"] #数据卷 volumeMounts: - name: config-volume #数据卷的位置 mountPath: /etc/config volumes: - name: config-volume configMap: name: special-config #重启策略 restartPolicy: Never 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f pod2.yaml
kubectl get pod
kubectl log pod名
#进入容器查看 kubectl exec pod名 -it -- /bin/sh ls /etc/config cat /etc/config/*
#ConfigMap热更新 kubectl delete pod --all
kubectl delete cm --all
kubectl get cm
vi hotupdate.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 #定义ConfigMap apiVersion: v1 #资源 kind: ConfigMap metadata: name: log-config namespace: default #数据 data: log_level: INFO --- apiVersion: extensions/v1beta1 kind: Deployment metadata: #运行名 name: my-nginx spec: #副本 replicas: 1 template: metadata: #标签 labels: run: my-nginx spec: #容器 containers: - name: my-nginx image: levi.harbor.com/library/nginx:1.9.1 ports: - containerPort: 80 #存储卷 volumeMounts: #引用 - name: config-volume mountPath: /etc/config #存储卷的数据是来自于ConfigMap volumes: - name: config-volume configMap: name: log-config 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f hotupdate.yaml
kubectl get pod
kubectl log pod名
kubectl exec pod名 -it -- cat /etc/config/log_level
kubectl get cm
kubectl get deployment
kubectl get rs
kubectl get pod
#INFO改为DEBUG kubectl edit configmap log-config
kubectl exec pod名 -it -- cat /etc/c/log_level
#ConfigMap更新，并不会触发相关pod的滚动更新，可以通过修改pod annotations的方式强制触发滚动更新 kubectl get pod
|
Secret
Secret解决了密码、Token、秘钥等敏感数据的配置文件，而不需要把这些敏感数据暴露到镜像或Pod Spec中，Secret可以以Volume或者环境变量的方式使用。
Secrt的三种类型：
ServiceAccount：用来访问K8S API，由K8S自动创建，并且自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中
Opaque：base64编码格式的Secret，用来存储密码、秘钥等
Kubernetes.io/dockerconfigjson：用来存储私有registry的认证信息
| kubectl get pod -n kube-system
#进入kube-proxy的容器中 kubectl exec kube-proxy-xxx -n kube-system -it -- /bin/bash
#可以看到其中的加密文件和加密内容 cd /run/secrets/kubernetes.io/serviceaccount ls cat *
#Opaque Secret：类型是一个map类型，要求value是base64编码格式 echo -n "admin" | base64
echo -n "test123" | base64
vi secrets.yml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: v1 #资源 kind: Secret metadata: name: mysecret #加密类型 type: Opaque data: username: YWRtaW4= password: dGVzdDEyMw== 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f secrets.yml
kubectl get secret
kubectl get secret -n kube-system
#将Secret挂载到volume中 vi secrets1.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: v1 #资源类型 kind: Pod metadata: #运行名 name: seret-volume #标签 labels: name: seret-test spec: #数据卷 volumes: #关联到下面的容器数据卷配置 - name: secrets #数据卷数据来源secret，来自运行中的mysecret secret: secretName: mysecret #容器 containers: - image: levi.harbor.com/library/nginx:1.9.1 name: db volumeMounts: - name: secrets mountPath: /etc/config readOnly: true 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f secrets1.yml
kubectl get pod
#进入容器进行查看 kubectl exec seret-volume -it -- /bin/bash
cd /etc/config/ ls #保存时自动解密 cat *
#将Secret导出到环境变量中，不需要以明文声明 vi secrets2.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: extensions/v1beta1 #资源类型 kind: Deployment metadata: name: pod-deployment spec: #运行的副本 replicas: 2 #Pod配置 template: metadata: #标签 labels: app: pod-deployment spec: #容器 containers: - name: pod-1 image: levi.harbor.com/library/nginx:1.9.1 #运行的端口 ports: - containerPort: 80 #环境变量 env: - name: TEST_USER #数据来源 valueFrom: #关联secret secretKeyRef: #来源mysecret这个secret name: mysecret #key: username key: password 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 kubectl apply -f secrets2.yml
kubectl get pod
kubectl get secret
#进入容器 kubectl exec pod名 -it -- /bin/sh echo $TEST_USER
#使用K8S Secret 保存Harbor密码
kubectl delete deployment --all
kubectl delete pod --all
#每台node都需要做退出docker操作 docker images
#删除旧的镜像，实验密码下载 docker rmi levi.harbor.com/library/nginx:1.9.1
#退出登录，注意缓存和/etc/docker/key.json docker logout levi.harbor.com
#拉取镜像，看是否需要输入密码 docker pull levi.harbor.com/library/nginx:1.9.1
#Image为指定的harbor的镜像，不需要复制imagePullSecrets: - name: myregistryke vi pod.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: v1 kind: Pod metadata: name: harbor-pod spec: containers: - name: harbor-container image: levi.harbor.com/library/nginx:1.9.1 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f pod.yaml
kubectl get pod
#失败 kubectl describe pod harbor-pod
kubectl create secret docker-registry myregistrykey --docker-username=admin --docker-password=Harbor12345 --docker-email=admin@example.com
#新增imagePullSecrets: - name: myregistryke vi pod.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: v1 kind: Pod metadata: name: harbor-pod spec: containers: - name: harbor-container image: levi.harbor.com/library/nginx:1.9.1 #镜像拉取的秘钥 imagePullSecrets: #使用myregistrykey这个Secret - name: myregistrykey 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl delete pod --all
kubectl apply -f pod.yaml
kubectl get pod
docker images |
Volume
容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时，会出现一些问题。
首先容器崩溃时，kubelet会重启它，但是容器中的文件将丢失—容器以干净的状态（镜像最初状态）重新启动。其次在Pod中同时运行多个容器时，这些容器之间通常需要共享文件。K8S中的Volume抽象就很好的解决了这些问题。
K8S中的卷有明确的生命周期，与封装它的Pod相同。所以，卷的生命比Pod中的所有容器都长，当这个容器重启时，数据仍然得以保存。当然，当Pod不再存在时，卷也将不复存在。也许更重要的是，K8S支持多种类型的卷，Pod可以同时使用任意数据的卷。
K8S支持以下的卷：
awsElasticBlockStore、azureDisk、azureFile、cephfs、csi、downwardAPI、emptyDir
fc、flocker、gcePersistenDisk、gitRepo、glusterfs、hostPath、iscsi、local、nfs
persistenVolumeClaim、projected、portworxVolume、quobyte、rbd、scaleIO、secret
storageos、vsphereVolume
emptyDir卷：
当Pod被分配给节点时，首先创建emptyDir卷，并且该Pod在该节点上运行，该卷就会存在。正如卷的名字，最初是空的。Pod中的容器可以读取和写入，emptyDir卷中的相同文件，尽管卷可以挂载到每个容器中的相同或不同路径上。当出于任何原因从节点中删除Pod时，emptyDir中的数据将被永久删除。
使用场景：
暂存空间：例如用于基于磁盘的合并排序
用作长时间计算崩溃恢复时的检查点
Web服务器容器提供数据时，保存内存管理容器提取的文件
注意：容器崩溃不会从节点中移除Pod，因此emptyDir卷中的数据在容器崩溃时是安全的。
实验：
| vi empty.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: v1 kind: Pod metadata: #运行的资源类型的名称 name: empty-pod spec: #运行的容器配置 containers: - name: test-container image: levi.harbor.com/library/nginx:1.9.1 #数据卷 volumeMounts: #关联到下面的配置· - name: cache-volume mountPath: /cache #数据卷 volumes: - name: cache-volume emptyDir: {} 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f empty.yaml
kubectl get pod
kubectl exec empty-pod -it -- /bin/bash
#挂载目录 cd /cache ls |
hostPath卷：
hostPath卷将主机节点的文件系统中的文件或目录挂在到集群中。
用途：运行需要访问Docker内部的容器，使用/var/lib/docker的hostPath；在容器中运行cAdvisor，使用/dev/cgroups的hostPath；允许Pod指定给定的hostPath是否应该在Pod运行之前存在，是否应该创建，以及它应该以书面形式存在。
除了使用所需的Path属性之外，还可以给hostPath卷指定type。
hostPath卷的type值：
| 值 | 行为 |
|
| 空字符串（默认）用于向后兼容，这意味着在挂载hostPath卷之前不会执行任何检查。 |
| DirectoryOrCreate | 如果给定的路径上没有任何东西存在，那么将根据需要在那里创建一个空目录，权限设置为0755，与kubelet具有相同的组合所有权。 |
| Directory | 给定的路径下必须存在目录 |
| FileOrCreate | 如果在给定的路径上没有任何东西存在，那么会根据需要创建一个空文件，权限设置为0644，与kubelet具有相同的组和所有权 |
| File | 给定的路径下必须存在文件 |
| Socket | 给定的路径下必须存在Unix套接字 |
| CharDevice | 给定的路径下必须存在字符设备 |
| BlockDevice | 给定的路径下必须存在块设备 |
注意：
由于每个节点上的文件都不同，具有相同配置（例如从podTemplate创建）的Pod在不同节点上的行为可能会不同；
当K8S按照计划添加资源感知调度时，将无法考虑hostPath使用的资源；
在底层主机上创建的文件或目录只能由root写入。因此需要再特权容器中以root身份运行进程，或修改主机上的文件权限以便写入hostPath卷。
实验：
| vi hostpath.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: v1 kind: Pod metadata: #运行的资源类型的名称 name: hostpath-pod spec: #容器配置 containers: - name: test-container image: levi.harbor.com/library/nginx:1.9.1 #容器内的数据卷配置 volumeMounts: - name: test-volume mountPath: /test-hp #数据卷配置 volumes: - name: test-volume hostPath: #本地目录 path: /tmp #类型 type: Directory 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl delete pod --all
kubectl apply -f hostpath.yaml
kubectl get pod -o wide
#进入容器 kubectl exec -it hostpath-pod -- /bin/bash cd /test-pd/ ls echo "test" >> 666.txt
#到对应的机器上查看 cat /tmp/666.txt
#与本机互操作 |
PersistentVolume (PV) & PersistentVolumeClaim (PVC)
PVC是PV的请求匹配方案，主要解决有前往各PV时，一一绑定不合适。
PersistentVolume(PV)是由管理员设置的存储，是集群的一部分。就像节点集群中的资源一样，PV也是集群中的资源。PV是Volume之类的卷插件，但具有独立于使用PV的Pod的生命周期。此API对象包含存储实现的细节，即NFS、iSCSI或特定与云供应商的存储系统。
PersistentVolumeClaim(PVC)是用户存储的请求，与Pod相似。Pod消耗节点资源，PVC消耗PV资源。Pod可以请求特定级别的资源（CPU和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写或只读多次模式挂载）。
静态PV：是集群管理员创建一些PV。它们带有可供集群用户使用的实际存储的细节。它们存在于K8S API中，可用于消费。
动态PV：当管理员创建的静态PV都不匹配用户的PersistentVolumeClaim(PVC)时，集群可能会尝试动态为PVC创建卷。此配置基于StorageClasses：PVC必须请求存储类，且管理员必须创建并配置该类才能进行动态创建。声明类为""可以有效的禁用其动态配置。要重启基于存储级别的动态存储配置，集群管理员需要启用API Server是哪个的DefaultStorageClass准入控制器。例如通过确保DefaultStorageClass位于APIServer组件的—admission-control标志，使用逗号分隔的有序值列表中，可以完成此操作。
绑定：master中的控制环境监视新的PVC，寻找匹配的PV（如果可能），并将它们绑定在一起，如果为新的PV动态调配PV，则该环路将始终将PV绑定到PVC。否则用户总会得到它们所请求的存储，但是容器可能会超出要求的数量。一旦PV和PVC绑定后，PersistentVolumeClaim绑定是排他性的，不管它们是如何绑定的PVC跟PV是一对一的映射。
持久化卷声明的保护：PVC保护的目的是确保由Pod正在使用的PVC不会从系统中移除，因为如果被移除的话，可能会导致数据丢失。
注意：当Pod状态为Pending，并且Pod已经分配给节点或Pod为Running状态时，PVC处于活动状态。当启动PVC保护alpha功能时，如果用户删除了一个Pod正在使用的PVC，则该PVC不会被利己删除。PVC的删除将会被延迟，知道PVC不在被任何Pod使用。
持久化卷类型：
PV类型以插件形式实现，K8S支持这些插件类型：
GCEPersistentDisk、AWSElasticBlockStore、AzureFile、AzureDisk、FC(Fibre Channel)
FlexVolume、Flocker、NFS、iSCSI、RBD(Ceph Block Device)、CephFS
hostPath、VMware Photon、Portworx Volumes、ScaleIO Volumes、StorageOS
PV访问模式：
PV可以以资源提供者支持的任何方式挂载到主机上，如下表所示，供应商具有不同功能，每个PV访问模式都将被设置为该卷支持的特定模式，例如NFS可以支持多个读/写客户端，但特定的NFS PV可能以只读方式导出到服务器上。每个PV都有一套主机的用来描述特定功能的访问模式。
命令行中的缩写：
RWO – ReadWriteOnce (单个节点以读写挂载)
ROX – ReadOnlyMany (多个节点以读挂载)
RWX – ReadWriteMany (多节点读写挂载)
| Volume插件 | ReadWriteOnce | ReadOnlyMany | ReadWriteMany |
| AWSElasticBlockStoreAWSElasticBlockStore | √ |
|
|
| AzureFile | √ | √ | √ |
| AzureDisk | √ |
|
|
| CephFS | √ | √ |
|
| Cinder | √ |
|
|
| FC | √ | √ |
|
| FlexVolume | √ | √ |
|
| Flocker | √ | √ |
|
| GCEPersistentDisk | √ |
|
|
| Glusterfs | √ | √ |
|
| HostPath | √ | √ | √ |
| iSCSI | √ |
|
|
| PhotonPersistentDisk | √ | √ |
|
| Quobyte | √ |
|
|
| NFS | √ | √ | √ |
| RBD | √ | √ | √ |
| VsphereVolume | √ | √ |
|
| PortworxVolume | √ |
| √（当 pod 并列时有效） |
| ScaleIO | √ | √ |
|
| StorageOS | √ |
|
|
回收策略：
Retain（保留）：手动回收
Recycle（回收）：基本擦除（rm –rf /thevolume/*）
Delete（删除）：关联的存储资产（例如AWS EBS、GCE PD、Azure Disk和OpenStack Cinder卷）
注意：当前只有NFS和hostPath支持回收策略。AWS EBS、GCE PD、Azure Disk和Cinder卷支持删除策略。
卷状态：
Available（可用）：一块空闲资源还没有被任何声明绑定
Bound（已绑定）：已被声明绑定
Released（已释放）：声明被删除，但是资源还未被集群重新声明
Failed（失败）：该卷的自动回收失败
安装NFS：
| #Harbor机器上安装NFS服务器 yum install -y nfs-common nfs-utils rpcbind mkdir /nfs chmod 666 /nfs chown nfsnobody /nfs
vi /etc/exports /nfs *(rw,no_root_squash,no_all_squash,sync)
systemctl start rpcbind systemctl start nfs
#在所有K8S节点上执行 yum -y install nfs-utils rpcbind
#在安装完成了，则在客户端访问 #注意是否有关闭防火墙，systemctl stop firewalld showmount -e Harbor机器的IP
#挂载 mkdir /test mount -t nfs Harbor机器的IP:/nfs /test
#测试 cd test echo "111" >> 1.html
#Harbor机器上看 ll /nfs/
#取消挂载 cd ~ umount /test rm -rf /test
#开始准备测试 #进入Harbor机器上，即NFS服务器，新建多几个共享目录 vi /etc/exports /nfs *(rw,no_root_squash,no_all_squash,sync) /nfs1 *(rw,no_root_squash,no_all_squash,sync) /nfs2 *(rw,no_root_squash,no_all_squash,sync)
mkdir /nfs1 mkdir /nfs2 chmod 777 /nfs1 /nfs2 chown nfsnobody /nfs1 /nfs2
systemctl restart rpcbind systemctl restart nfs #通过之前的步骤，在别的机器测试下挂载目录 |
实验：
| #部署PV，修改为Retain kubectl delete pod --all kubectl delete pv --all
vi pv.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: v1 #资源类型PV kind: PersistentVolume metadata: name: nfspv1 spec: capacity: #存储1G storage: 1Gi #访问模式，RWO单个节点以读写挂载，ROX多个节点读挂载，RWX多节点读写挂载 accessModes: - ReadWriteOnce #回收策略，Retain保留，Recycle回收，Delete删除 persistentVolumeReclaimPolicy: Retain #存储关联NFS storageClassName: nfs nfs: #共享目录 path: /nfs #nfs服务器的IP server: 192.168.70.113 --- apiVersion: v1 #资源类型PV kind: PersistentVolume metadata: name: nfspv2 spec: capacity: #存储1G storage: 2Gi #访问模式，RWO单个节点以读写挂载，ROX多个节点读挂载，RWX多节点读写挂载 accessModes: - ReadOnlyMany #回收策略，Retain保留，Recycle回收，Delete删除 persistentVolumeReclaimPolicy: Retain #存储关联NFS storageClassName: nfs nfs: #共享目录 path: /nfs1 #nfs服务器的IP server: 192.168.70.113 --- apiVersion: v1 #资源类型PV kind: PersistentVolume metadata: name: nfspv3 spec: capacity: #存储3G storage: 3Gi #访问模式，RWO单个节点以读写挂载，ROX多个节点读挂载，RWX多节点读写挂载 accessModes: - ReadWriteMany #回收策略，Retain保留，Recycle回收，Delete删除 persistentVolumeReclaimPolicy: Retain #存储关联NFS storageClassName: slow nfs: #共享目录 path: /nfs2 #nfs服务器的IP server: 192.168.70.113 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f pv.yaml
kubectl get pv
#注意：要建立StatefulSet必须要建立一个None Service
#创建服务并使用PVC vi pod.yaml 〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓 apiVersion: v1 kind: Service metadata: #资源的运行名称 name: nginx #标签 labels: app: nginx spec: #端口 ports: - name: web port: 80 #由于下面要用到StatefulSet，因此SVC是None clusterIP: None selector: app: nginx --- apiVersion: apps/v1 #资源类型 kind: StatefulSet metadata: name: web spec: #应用匹配选择器 selector: matchLabels: app: nginx serviceName: "nginx" #运行副本 replicas: 3 #运行的Pod template: metadata: labels: app: nginx spec: #容器 containers: - name: nginx image: levi.harbor.com/library/nginx:1.9.1 ports: - containerPort: 80 name: web #数据卷 volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "nfs" resources: requests: storage: 1Gi
〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
kubectl apply -f pod.yaml
kubectl get pod
kubectl get pv
kubectl get pvc
#可以看到有一个失败了 kubectl get pod #出现的是1失败，也证明了是顺序创建的 #pod has unbound immediate PersistentVolumeClaims (repeated 2 times) kubectl describe pod web-1
#可以看到绑定类型是nfs，并且模式是ReadWriteOnce即RWO的 cat pod.yaml
#可以看到RWO的已经给绑定了，没了 kubectl get pv
kubectl describe pv nfspv1
#也可通过修改对应的storage和访问模式等，再次查看匹配模式，自己去实验
#在nfs服务器上的对应目录新建一个index.html vi index.html chmod 777 index.html
kubectl get pod -o wide
curl IP |
StatefulSet：
匹配Pod Name（网络标识）的模式为：$(statefulset名称)-$(序号)，如web-0
StatefulSet为每个Pod副本创建了一个DNS域名，这个域名的格式为：$(podname).(headless server name)，也意味着服务间是通过Pod域名拉通信而非Pod IP，因为当Pod所在Node发生故障时，Pod会被飘移到其他Node上，PodIP会发生变化，但Pod域名不会有变化。
| kubectl get pod -o wide
kubectl delete pod web-0
#会发现地址变了，但是Name还是没有变 kubectl get pod -o wide
#DNS域名没有变 kubectl exec web-0 -it -- /bin/sh ping web-0.nginx（pod名.SVC名） |
StatefulSet使用Headless服务来控制Pod的域名，这个域名的FQDN为：$(service name).$(namespace).svc.cluster.local，其中cluster.local指的是集群的域名。
| kubectl get pod -o wide -n kube-system #IP用coredns的IP dig -t A nginx.default.svc.cluster.local. @IP |
StatefulSet根据volumeClaimTemplates，为每个Pod创建一个PVC，PVC的命名规则匹配模式(volumeClaimTemplates.name)-(pod_name)，比如volumeMounts.name=www，Podname=www-[0 - 2]，因此创建出来的PVC是www-web-0、www-web-1、www-web-2。
删除Pod不会删除其PVC，手动删除PVC将会自动释放PV。
Statefulset启停顺序：
有序部署：部署StatefulSet时，如果有多个Pod副本，它们会被顺序创建（从0到N-1）并且，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态。
有序删除：当Pod被删除时，它们的终止的顺序是从N – 1到0。
有序扩展：当对Pod执行扩展操作时，与部署一样，它前面的Pod必须都处于Running和Ready状态。
| #有序删除 kubectl delete statefulset --all
#从后到前删除 kubectl get pod -w
#有序扩展 kubectl delete statefulset --all kubectl delete svc --all
kubectl create -f pod.yaml
kubectl get pod -o wide
curl IP
kubectl delete -f pod.yaml
kubectl get pod
kubectl get svc
#手动释放资源，要删除nfs的数据，但还是会正常的状态，因不会去看文件夹内是否有内容，在描述数据里，依然有这个信息 kubectl get pv
#查看描述数据 kubectl get pv nfspv1 -o yaml
#删除claimRef的内容 kubectl edit pv nfspv1 kubectl get pv |
StatefulSet使用场景：
稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现。
稳定的网络标识符，即Pod重新调度后其PodName和HostName不变。
有序部署、有序扩展，基于Init Contaniners来实现。
有序收缩。
K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容
更多推荐
0
0- 0
已为社区贡献6条内容
所有评论(0)