kubernetes存储&Service

Service

Service也是Kubernetes里的最核心的资源对象之一，Kubernetes里的每个Service其实就是我们经常提起的微服务架构中的一个“微服务”，之前我们所说的Pod、RC等资源对象其实都是为这节所说的“服务”------Kubernetes Service作“嫁衣”的。

Pod、RC与Service的关系

Kubernetes的Service定义了一个服务的访问入口地址，前端的应用（Pod）通过这个入口地址访问其背后的一组由Pod副本组成的集群实例，Service与其后端Pod副本集群之间则是通过Label
Selector来实现“无缝对接”的。而RC的作用实际上是保证Service的服务能力和服务质量始终处于预期的标准。

通过分析、识别并建模系统中的所有服务为微服务-----Kubernetes Service，最终我们的系统由多个提供不同业务能力而又彼此独立的微服务单元所组成，服务之间通过TCP/IP进行通信，从而形成了我们强大而又灵活的弹性网格，拥有了强大的分布式能力、弹性扩展能力、容错能力，于此同时，我们的程序架构也变得简单和直观许多，

Service 代理

userspace 代理模式

这里的userspace是指Linux操作系统的用户空间。这种模型中，Kube-proxy负责跟踪API Server上的service和Endpoints对象的的变动（创建或移除）。对于每个service对象它会打开一个本地端口（运行于用户空间的Kube-proxy进程负责监听），任何到达此代理端口的连接请求都会被代理至当前Service资源后端的各Pod对象上，至于会挑选哪个pod取决于service资源的调度方式，默认为轮询

iptables 代理模式

iptables代理模式和前一种代理模式是类似的，都是由Kube-proxy来跟踪监听API-server上的service和Endpoints的变更。但是有一点不同的是iptables规则直接捕获到达cluster IP和port的流量，并将其重定向至当前Service的后端，对于每个Endpoints对象，Service资源会为其创建iptables规则并关联至挑选的后端pod资源，默认算法是随机调度（random）。iptables代理模式在Kubernetes1.1版本引入，并在1.2版开始成为默认类型。

ipvs 代理模式

ipvs是建立在netfilter的钩子函数上，但它使用hash表作为底层数据结构并工作于内核空间，因此流量转发速度特别快、规则同步性很好，而且它支持众多调度算法，rr（轮询）、lc（最小连接数）、dh（目标哈希）、sh（源哈希）、sed(最短期望延迟)、nq（不排队调度）。

内部访问方式

ClusterIP 服务是 Kubernetes的默认服务。它给你一个集群内的服务，集群内的其它应用都可以访问该服务。集群外部无法访问它。在某些场景下我们可以使用 Kubernetes 的Proxy 模式来访问服务，比如调试服务时。

创建Service

Service从逻辑上代表了一组Pod,具体是哪些Pod则是
由label来挑选的。Service有自己的IP,而且这个IP是不变的。客户端只需要访问Service的IP,Kubernetes则负责建立和维护Service与Pod的映射关系。无论后端Pod如何变化,对客户端不会有任何影响,因为Service没有变

创建Deployment

cat httpd.yml 
apiVersion: apps/v1
kind: Deployment
metadata:
 name: httpd
spec:
 replicas: 3
 selector:
  matchLabels:
   run: httpd
 template:
  metadata:
   labels:
    run: httpd
  spec:
   containers:
   - name: httpd
     image: httpd
     ports:
     - containerPort: 80

注意的是：node节点上的docker服务必须是好的，而且虚拟机要能上网
kubectl apply -f httpd.yml 
kubectl get pod -o wide  #注意：ip的出现是需要时间的(容器的准备也是需要时间的)
我们可以看到的是：Pod分配了各自的IP,这些IP只能被Kubernetes Cluster中的容器和节点访问

创建Service

cat httpd-svc.yml 
apiVersion: v1
kind: Service
metadata:
 name: httpd-svc
spec:
   selector:
    run: httpd
   ports:
     - protocol: TCP
       port: 8080
       targetPort: 80

#v1是Service的apiVersion
#指明当前资源的类型为Service
#Service的名字为httpd-svc
#selector指明挑选那些label为run: httpd的Pod作为Service的后端
#将Service的8080端口映射到Pod的80端口,使用TCP协议

kubectl apply -f httpd-svc.yml 
kubectl get service

httpd-svc分配到一个CLUSTER-IP
以通过该IP 访问后端的httpd Pod
通过kubectl describe可以查看httpd-svc与Pod的对应关系
kubectl describe service httpd-svc 

service运行原理

Cluster IP是一个虚拟IP,是由Kubernetes节点上的iptables规则管理的可以通过iptables-save命令打印出当前节点的iptables规则,因为输出较多,这里只截取与httpd-svc Cluster IP 10.99.229.179相关的信息
注意用户的切换：此处使用root用户
iptables-save |grep httpd-svc
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.104.247.136/32 -p tcp -m comment --comment "default/httpd-svc: cluster IP" -m tcp --dport 8080 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.104.247.136/32-p tcp -m comment --comment "default/httpd-svc: cluster IP" -m tcp --dport 8080 -j KUBE-SVC-RL3JAE4GN7VOGDGP

如果Cluster内的Pod(源地址来自10.244.0.0/16)要访问httpd-svc,则允许其他源地址访问httpd-svc,跳转到规则KUBE-SVC-RL3JAE4GN7VOG DGP。KUBE-SVC-RL3JAE4GN7VOGDGP规则

iptables-save |grep KUBE-SVC-RL3JAE4GN7VOGDGP
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-N5PH4BBCFTMHGLV6
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-UEWSDQT52CMKBNNL
-A KUBE-SVC-RL3JAE4GN7VOGDGP -j KUBE-SEP-BSPNJWUG33XKKPE5
 1/3的概率跳转到规则 KUBE-SEP-N5PH4BBCFTMHGLV6
 1/3的概率(剩下2/3的一半)跳转到规则  KUBE-SEP-UEWSDQT52CMKBNNL
 1/3的概率跳转到规则 KUBE-SEP-BSPNJWUG33XKKPE5

即将请求分别转发到后端的三个Pod。通过上面的分析,我们得到结论:iptables将访问Service的流量转发到后端Pod,而且使用类似轮询的负载均衡策略
另外,需要补充一点:Cluster的每一个节点都配置了相同的
iptables规则,这样就确保了整个Cluster都能够通过Service的Cluster IP访问Service

DNS访问Service
在Cluster中,除了可以通过Cluster IP访问Service,Kubernetes还提供了更为方便的DNS访问
kubeadm部署时会默认安装kube-dns组件
kube-dns是一个DNS服务器。每当有新的Service被创建,kube-dns会添加该Service的DNS记录。Cluster中的Po可以通过<SERVICE_NAME>.<NAMESPACE_NAME>访问Service

如果要访问其他namespace中的Service,就必须带上namesapce了。kubectl get namespace查看已有的namespace
kubectl get namespace
kube-dns是一个DNS服务器。每当有新的Service被创建,kube-dns会添加该Service的DNS记录

kubectl run busybox --rm -it --image=busybox /bin/sh  #只用于测试，不属于任何集群，进入交互界面
/ # wget httpd-svc.default:8080
Connecting to httpd-svc.default:8080 (10.99.215.181:8080)


 如上所示,我们在一个临时的busyboxPod中验证了DNS的有效性。另外,由于这个Pod与httpd-svc同属于default namespace,因此可以省略default直接用httpd-svc访问Service

部署两个Service

cat httpd2.yml 
apiVersion: apps/v1
kind: Deployment
metadata:
 name: httpd2
 namespace: kube-public
spec:
 replicas: 3
 selector:
  matchLabels:
   run: httpd2
 template:
  metadata:
   labels:
    run: httpd2
  spec:
   containers:
   - name: httpd2
     image: httpd
     ports:
     - containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
 name: httpd2-svc
 namespace: kube-public
spec:
   selector:
    run: httpd2
   ports:
     - protocol: TCP
       port: 8080
       targetPort: 80

kubectl apply -f httpd2.yml 
kubectl get service --namespace=kube-public 

#在busybox Pod中访问httpd2-svc,因为不属于同一个namespace,所以必须使用httpd2-svc.kube-public才能访问到
kubectl run busybox --rm -it --image=busybox /bin/sh
/ # wget httpd2-svc.kube-public:8080
注意：Pod与httpd-svc同属于default namespace,因此可以省略default直接用httpd-svc访问Service

外部访问方式

NodePort

除了Cluster内部可以访问Service,很多情况下我们也希望应用的Service能够暴露给Cluster外部。Kubernetes提供了多种类型的Service,默认是ClusterIP

(1)ClusterIP
Service通过Cluster内部的IP对外提供服务,只有Cluster内的节点和Pod可访问,这是默认的Service类型,前面实验中的Service都是ClusterIP

(2)NodePort
Service通过Cluster节点的静态端口对外提供服务。Cluster外部可以通过:访问Service

(3)LoadBalancer Service利用cloud provider特有的load balancer对外提供服务,cloud
provider负责将load balancer的流量导向Service 目前支持的 cloud
provider有GCP、AWS、Azur等

cat httpd-svc.yml 
apiVersion: v1
kind: Service
metadata:
 name: httpd-svc
spec:
   type: NodePort
   selector:
    run: httpd
   ports:
     - protocol: TCP
       port: 8080
       targetPort: 80

添加type: NodePort,重新创建httpd-svc
注意点是：要先运行pod 然后将它们打包成一个整体-service
kubectl apply -f httpd.yml 
kubectl apply -f httpd-svc.yml 
#Kubernetes依然会为httpd-svc分配一个ClusterIP,不同的是 PORT(S)为8080:30295 8080是ClusterIP监听的口,32312则是节点上监听的端口。Kubernetes会从30000~32767中分配一个可用的端口,每个节点都会监听此端口并将请求转发给Service
kubectl get service httpd-svc 
kubectl get pod -o wide

与ClusterIP一样,也是借助了iptables。与ClusterIP相比,每个节点的iptables中都增加了下面两条规则
iptables-save |grep 30295
	-A KUBE-NODEPORTS -p tcp -m comment --comment "default/httpd-svc:" -m tcp --dport 30295 -j KUBE-MARK-MASQ
	-A KUBE-NODEPORTS -p tcp -m comment --comment "default/httpd-svc:" -m tcp --dport 30295 -j KUBE-SVC-RL3JAE4GN7VOGDGP

iptables-save |grep KUBE-SVC-RL3JAE4GN7VOGDGP
	:KUBE-SVC-RL3JAE4GN7VOGDGP - [0:0]
	-A KUBE-NODEPORTS -p tcp -m comment --comment "default/httpd-svc:" -m tcp --dport 30295 -j KUBE-SVC-RL3JAE4GN7VOGDGP
	-A KUBE-SERVICES -d 10.98.81.225/32 -p tcp -m comment --comment "default/httpd-svc: cluster IP" -m tcp --	dport 8080 -j KUBE-SVC-RL3JAE4GN7VOGDGP
	-A KUBE-SVC-RL3JAE4GN7VOGDGP -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-Y5EOPQEI6R2HKSKZ
	-A KUBE-SVC-RL3JAE4GN7VOGDGP -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-SACXFJATP2WVU5HD
	-A KUBE-SVC-RL3JAE4GN7VOGDGP -j KUBE-SEP-MZTDTCCSTQYQRVK2

规则的含义是:访问当前节点30295端口的请求会应用规则  KUBE-SVC-RL3JAE4GN7VOGDGP其作用就是负载均衡到每一个Pod
NodePort默认的是随机选择,不过我们可以用nodePort指定某个特定端口

cat httpd-svc.yml 
apiVersion: v1
kind: Service
metadata:
 name: httpd-svc
spec:
   type: NodePort
   selector:
    run: httpd
   ports:
     - protocol: TCP
       nodePort: 30000
       port: 8080
       targetPort: 80

最终,Node和ClusterIP在各自端口上接收到的请求都会通过iptables转发到Pod的targetPort

kubectl apply -f httpd-svc.yml 
kubectl get service httpd-svc 
pod和svc的对应关系是多对多，只要标签一致

Loadbalancer

LoadBalancer 服务是暴露服务到 Internet
的标准方式。所有通往你指定的端口的流量都会被转发到对应的服务。它没有过滤条件，没有路由等。这意味着你几乎可以发送任何种类的流量到该服务，像
HTTP，TCP，UDP，WebSocket，gRPC 或其它任意种类。

ExternalName

这种类型的Service通过返回CNAME和它的值,可以将服务映射到externalName字段的内容(例如:
hub.atguigu.com )。ExternalName
Service是Service的特例，它没有selector，也没有定义任何的端口和Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务

kind:Service
apiVersion: v1
metadata:
  name: my-service-1
  namespace: default
spec:
  type: ExternalName
  externalName : my.database.example.com

当查询主机my-service.defalut.svc.cluster.local (
SVC_NAME.NAMESPACE.svc.cluster.local )时，集群的
DNS服务将返回一个值my.database.example.com的CNAME记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在DNS层，而且不会进行代理或转发

ingress-nginx

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.41.2/deploy/static/provider/cloud/deploy.yaml

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/baremetal/service-nodeport.yaml
#选择nodeport方案

ingress虚拟主机

建立两个svc

apiversion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-dm1
spec:
  replicas: 2
  template:
    metadata:
      labels:
        name: nginx1
    spec:
      containers:
      - name: nginx1
        image: wangyanglinux/myapp:v1
        imagePu11Policy: IfNotPresent
        ports:
        - containerport: 8e
---
apiversion: v1
kind: service
metadata:
  name: svc1
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    name: nginx1

apiversion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-dm2
spec:
  replicas: 2
  template:
    metadata:
      labels:
        name: nginx2
    spec:
      containers:
      - name: nginx2
        image: wangyanglinux/myapp:v2
        imagePu11Policy: IfNotPresent
        ports:
        - containerport: 8e
---
apiversion: v1
kind: service
metadata:
  name: svc2
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    name: nginx2

写ingress规则（和SVC对应也是两个）将写的规则注入到.conf文件

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-test
spec:
  rules:
    - host: wwe1.atguigu.com
      http:
        paths:
        - path:/
          backend :
            serviceName: nginx-svc
            servicePort: sel

添加hosts解析

存储

我们经常会说:容器和Pod是短暂的。其含义是它们的生命周期可能很短,会被频繁地销毁和创建。容器销毁时,保存在容器内部文件系统中的数据都会被清除

Volume的生命周期独立于容器,Pod中的容器可能被销毁和重建,但Volume会被保留

本质上,Kubernetes Volume是一个目录,这一点与Docker Volume类似。当Volume被mount到Pod,Pod中的所有容器都可以访问这个Volume

Volume也支持多种backend类型,包括 emptyDir、hostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、Ceph等,完整列表，可参考

https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes

Volume提供了对各种backend的抽象,容器在使用Volume读写数据的时候不需要关心数据到底是存放在本地节点的文件系统中还是云硬盘上。对它来说,所有类型的Volume都只是一个目录

emptyDir

emptyDir是最基础的Volume类型。正如其名字所示,一个emptyDir Volume是Host上的一个空目录

emptyDir Volume对于容器来说是持久的,对于Pod则不是。当Pod从节点删除时,Volume的内容也会被删除。但如果只是容器被销毁而Pod还在,则Volume不受影响。也就是说:emptyDir Volume的生命周期与Pod一致，Pod中的所有容器都可以共享Volume,它们可以指定各自的。

cat emptyDir.yml 
apiVersion: v1
kind: Pod
metadata:
 name: producer-consumer
spec:
  containers:
  - image: busybox
    name: producer
    volumeMounts:
    - mountPath: /producer_dir
      name: shared-volume
    args:
    - /bin/sh
    - -c
    - echo "hello world" > /producer_dir/hello ; sleep 30000
  - image: busybox
    name: consumer
    volumeMounts:
    - mountPath: /consumer_dir
      name: shared-volume
    args:
    - /bin/sh
    - -c
    - cat /consumer_dir/hello ; sleep 30000
  volumes:
  - name: shared-volume
    emptyDir: {}

这里我们模拟了一个producer-consumer场景。Pod有两个容器producer和consumer,它们共享一个Volume。producer负责往Volume中写数据,consumer则是从Volume读取数据

1.文件最底部volumes定义了一个emptyDir类型的Volume shared-volume
2.producer容器将shared-volume mount到/producer_dir目录
3.producer通过echo将数据写到文件hello里
4.consumer容器将shared-volume mount到/consumer_dir目录
5.consumer通过cat从文件hello读数据

kubectl get pod
kubectl logs producer-consumer consumer 
docker ps -a
docker inspect 8de1260fdd5a | grep Source
docker inspect f293c268929e | grep Source

因为emptyDir是Docker Host文件系统里的目录,其效果相当于执行了docker run -v/producer_dir和docker run -v /consumer_dir。通过docker inspect查看容器的详细配置信息,我们发现两个容器都mount了同一个目录

这里/var/lib/kubelet/pods/f42e8fc1-59d8-4359-9b6a-65b95b06c762/volumes/kubernetes.io~empty-dir/shared-volume， 就是emptyDir在Host上的真正路径

emptyDir是Host上创建的临时目录,其优点是能够方便地为Pod中的容器提供共享存储,不需要额外的配置。它不具备持久性,如果Pod不存在了,emptyDir也就没有了。根据这个特性,emptyDir特别适合Pod中的容器需要临时共享存储空间的场景

Configmap

一。三种创建方式

vim docs/user-guide/configmap/kubectl/game.properties
enemies=aliens 
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30

vim docs/user-guide/configmap/kubectl/ui.properties
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

使用目录创建

kubectl create configmap game-config -- from-file=docs/user-guide/configmap/kubectl
kubectl get cm
kubectl get cm game-config -0 yaml

-from- file 指定在目录下的所有文件都会被用在ConfigMap里面创建一 个键值对,键的名字就是 文件名,值就是文件的内容

使用文件创建

只要指定为一个文件就可以从单个文件中创建ConfigMap

kubectl create configmap game-config-2 from-file=docs/user-guide/configmap/kubectl/game.properties
kubectl get configmaps game-config-2 -0 yaml

-from-file这个参数可以使用多次，你可以使用两次分别指定上个实例中的mmeu 就跟指定整个目录是一样的

使用字面值创建

使用文字值创建,利用-from - literal参数传递配置信息，该参数可以使用多次,格式如下,只需指定键值即可

kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm

二。 Pod中使用ConfigMap
使用ConfigMap来替代环境变量

apiVersion: V1
kind: ConfigMap
metadata :
  name: special-config
  namespace: default
data:
  ipecial.how: very
  special. type: charm

apiVersion: V1
kind: ConfigMap
metadata :
  name: env-config
  namespace: default
data:
  1og_level: INFO

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
  - name: test-container
    image: hub. atguigu.com/library/myapp:v1
    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
    envF rom:
      - configMapRef:
          name: env-config
  restartPolicy: Never

用ConfigMap设置命令行参数

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm 

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: hub.atguigu.com/library/myapp:v1
      command: [ "/bin/sh", "-C", "echo $(SPECIAL_LEVEL_KEY) $(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
  restartPolicy: Never

通过数据卷插件使用ConfigMapl

apiVersion: v1
kind: ConfigMap
metadata:
  name: pecial-config
  namespace: default
data:
  special.how: very
  special.type: charm

在数据卷里面使用这个ConfigMap,有不同的选项。最基本的就是将文件填入数据卷，在这个文件 中,键就是文件名,键值就是文件内容

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers :
    - name: test-container
      image: hub. atguigu.com/library/myapp:v1
      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

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: hub. atguigu. com/library/myapp:v1
        ports:
        - containerPort: 80
        volumeMounts:
        - name: config-volume
          mountPath: /etc/config
    volumes:
      - name: config-volume
        configMap:
          name: log-config

kubectl exec‘kubectl get pods -1 run=my-nginx  -o=name|cut -d "/”-f2^ cat /etc/config/1og_level
INFO
#修改ConfigMap
kubectl edit configmap log-config
/tmp/1og_ level
DEBUG

<!--! ! !特别注意configMap 如果以ENV的方式挂载至容器，修改configMap并不会实
现热更新-->
ConfigMap更新后滚动更新Pod
更新ConfigMap目前并不会触发相关Pod的滚动更新，可以通过修改pod annotations的方式强制

Secret

Secret存在意义
Secret解决了密码、token、 密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者Pod
Spec中。Secret 可以以Volume或者环境变量的方式使用
Secret有三种类型:

• Service Account :用来访问Kubernetes API,由Kubertetes自动创建，并且会自动挂载到Pod的/ run/secrets/kubernetes. io/serviceaccount 目录中
• Opaque : base64编码格式的Secret, 用来存储密码、密钥等
• kubernetes.io/dockerconfigjson :用来存储私有docker registry的认证信息

Service Account

Service Account用来访问Kubernetes API,由Kubernetes自动创建,并且会自动挂载到Pod的
/run/secrets/ kubernetes . io/serviceaccount目录中

kubectl run nginx --image nginx
kubectl get pods
kubectl exec nginx-3137573019-md1u2 ls /run/secrets/kubernetes.io/serviceaccount

Opaque Secret

Opaque类型的数据是一个map类型，要求value是base64编码格式:

echo -n "admin"| base64
echo -n "1f2d1e2e67df"| base64

secrets.yml 
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: MWYyZDFlMmU2N2Rm
  username: YWRtaW4=

使用方式
将Secret挂载到Volume中

apiVersion: V1
kind: Pod
metadata:
  labels:
    ngme: seret-test
  name: seret-test
spec:
  volumes :
  - name: secrets
    secret:
      secretName:mysecret
  containers :
  - image: hub.atguigu.com/library/myapp:v1
    name: db
    volumeMounts:
    - name: secrets
      mountPath: " /etc/secrets"
      readOnly: true

将Secret导出到环境变量中

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: pod-deployment
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: pod-deployment
    spec:
      containers:
      - name: pod-1
        image:hub.atguigu.com/library/myapp:v1
      ports :
      - containerPort: 80
      env :
      - name: TEST_USER
        valueFrom:
          secretKeyRef :
            name: mysecret
            key: username
      - name: TEST_PASSWORD
        valueFrom:
          secretKeyRef:

kubernetes.io/dockerconfigjson

使用Kuberctl创建docker registry认证的secret

kubectl create secret docker-registry myregistrykey --docker-server=DOCKER_REGISTRY_SERVER --
docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

在创建Pod的时候，通过imagePullSecrets 矧用刚创建的、myregistrykey'

apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers :
  - name: foo
    image: roc/awangyang:v1
  imagePullSecrets:
    - name: myregistrykey I

PVC

PersistentVolume是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源-样, PV也是集群中的资源。PV
是Volume之类的卷插件，但具有独立于使用PV的Pod的生命周期。此API对象包含存储实现的细节，即NFS，iSCSI或特定于云供应商的存储系统

PersistentVolumeClaim (PVC)是用户存储的请求。它与Pod相似。Pod
消耗节点资源，PVC消耗PV资源。Pod可以请求特定级别的资源(CPU和内存)。声明可以请求特定的大小和访问模式(例如，可以以读/写 -次或 只读多次模式挂载)

静态pv

集群管理员创建一些PV。它们带有可供群集用户使用的实际存储的细节。它们存在于Kubernetes API中，可用 于消费

动态

当管理员创建的静态PV都不匹配用户的PersistentVolumeClaim 时，集群可能会尝试动态地为PVC创建卷。此
配置基于StorageClasses : PVC 必须请求[存储类],并且管理员必须创建并配置该类才能进行动态创建。声明该
类为””可以有效地禁用其动态配置，要启用基于存储级别的动态存储配置，集群管理员需要启用API server上的DefaultstorageClass [准入控制器]。例如，通过确保DefaultstorageClass 位于API server组件的| – admission- control标志，使用逗号分

绑定

master中的控制环路监视新的PVC,寻找匹配的PV (如果可能)，并将它们绑定在一起。 如果为新的PVC
动态调配PV,则该环路将始终将该PV绑定到PVC。否则，用户总会得到他们所请求的存储,但是容量可能超出 要求的数量。一旦PV和PVC绑定后，I PersistentVolumeClaim小绑定是排他性的，不管它们是如何绑定的。 PVC跟PV绑定是一对一的映射

持久化卷声明的保护

PVC保护的目的是确保由pod正在使用的PVC不会从系统中移除，因为如果被移除的话可能会导致数据丢失

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0003
spec: 
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storggeClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2

PV访问模式

PersistentVolume可以以资源提供者支持的任何方式挂载到主机上。如下表所示，供应商具有不同的功能,每个
PV的访问模式都将被设置为该卷支持的特定模式。例如，NFS可以支持多个读/写客户端，但特定的NFS PV可
能以只读方式导出到服务器上。每个PV都有一套自己的用来描述特定功能的访问模式
●ReadWriteOnce-- _该 卷可以被单个节点以读/写模式挂载
●ReadOnlyMany- - -该卷可以被多个节点以只读模式挂载
●ReadWriteMany- - -该卷可以被多个节点以读/写模式挂载

在命令行中，访问模式缩写为:
●RWO- ReadWriteOnce
●ROX - ReadOnlyMany
●RWX- ReadWriteMany


回收策略
●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 (失败) -- 该卷的自动回收失败
命令行会显示绑定到PV的PVC的名称

持久化演示说明- NFS
安裝NFS服务器

yum install -y nfs-common nfs-utils rpcbind
mkdir /nfsdata
chmod 666 /nfsdata
chown nfsnobody /nfsdata
cat /etc/exports
/nfsdata: *(rW, no_ root_ _squash,no_ all_ squash,sync)
systemctl start rpcbind
systemctl start nfs

cat /etc/exports
/nfsdata1: *(rW, no_ root_ _squash,no_ all_ squash,sync)
/nfsdata2: *(rW, no_ root_ _squash,no_ all_ squash,sync)
/nfsdata3: *(rW, no_ root_ _squash,no_ all_ squash,sync)
/nfsdata4: *(rW, no_ root_ _squash,no_ all_ squash,sync)

部署PV

apivension: v1
kind: PersistentVolume
metadata:
  name: nfspv1
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassNlame: nfs
  nfs: 
    path: /data/nfs
    server: 10.66.66.10

工、创建服务并使用PVC

apiVersion: v1
kind: Service
metadata :
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec: 
  selector:
    matchLabels: 
      app: nginx
  serviceName:"nginx"
  replicas: 3
  template:
    metadata :
      labels:
        app: nginx
    spec :
      containers :
      - name: nginx
        image: k8s. gcr. io/nginx-slim:0.8
        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