k8s in action

容器与虚拟机的区别？P8

虚拟机将宿主机的资源硬隔离，每个虚拟机都有一个独立的操作系统，这些操作系统的生成需要消耗宿主机额外的资源，一个服务一个虚拟机的方式浪费太多资源，所以只能多个服务公用一个虚拟机，就行权益平台1.0一样，当一个服务重启就会影响其他服务

多个容器可以共享宿主机的操作系统，容器消耗的资源只是容器内程序运行依赖的资源，没有操作系统资源的浪费，可以一个服务一个容器

使用K8S部署流程？P19

构建镜像-》提交镜像-》提交应用描述到K8S API-》API分配节点-》节点kubelets负责拉取镜像运行docker容器

k8s好处？P20

在集群中自动分配资源节点-也可指定节点启动相应服务、节点及容器健康监控-自动转移pod、自动扩缩容、发版时检测版本是否异常-自动停止滚动更新

--------------------------pod---------------------------------

pod中的服务容器是紧密相关的组件，pod是扩缩容的基本单位

pod描述文件yaml P59，创建pod：kubectl create -f createPod.yml

apiVersion: v1
kind: Pod
metadata:
 name: kubia-manual
spec:
 containers:
 - image: yfzhou528/kubia
   name: kubia
   ports:
   - containerPort: 8080
     protocol: TCP

--------------------------标签---------------------------------

功能：筛选满足标签条件的资源，如pod、节点等

为节点增加标签，在pod描述文件中使用nodeSelector指定pod运行在添加特定标签的节点上

为高GPU的node节点添加标签：
kubectl lable node $nodeName gpu=true

apiVersion: v1
kind: Pod
metadata:
 name: kubia-manual
spec:
 nodeSelector: // 标签选择器
   gpu: "true"
 containers:
 - image: yfzhou528/kubia
   name: kubia
   ports:
   - containerPort: 8080
     protocol: TCP

-----------------------命名空间------------------------------------

 资源隔离，创建pod时可指定命名空间

----------------------存活探针-------------------------------------

k8s通过存活探针检测容器是否正常运行，如果不正常，通过RC或Deployment重新创建容器

HTTP GET 探针，通过向容器ip发送get请求检测响应是否正常，可设置首次探针探测时间、响应超时时间、探测多久探一次、失败阈值即失败几次后要重启容器

apiVersion: v1
kind: Pod
metadata:
 name: kubia-manual
spec:
 nodeSelector: // 标签选择器
   gpu: "true"
 containers:
 - image: yfzhou528/kubia
   name: kubia
   livenessProbe: //探针
    httpGet:      //httpGet存活探针
     path: /      //get请求路径
     port: 8080   //get请求端口
    initialDelaySeconds: 15 //第一次探针检测在容器启动15s后，防止误探
   ports:
   - containerPort: 8080
     protocol: TCP

 探测容器、重启容器这项工作由k8s节点上的kubelet负责，如果节点挂了，kubelet无法完成这项工作，所以引入副本控制器ReplicationController

------------------ReplicationController-----------------------------------------

作用：通过标签选择器确保标签匹配的pod始终正常运行，通过检查pod副本数来新建/删除pod。

注意RC作用的最小单元是pod而不是容器，而kubelet的工作是检测pod内的容器状态和重启容器

三要素：标签选择器、副本数、pod模板

如果RC标签选择器selector中有多个标签，组成集合A，则pod的标签labels中的标签项集合B必须是A的父级才会被RC管理

apiVersion: v1
kind: ReplicationController
metadata:
 name: kubia-rc
spec:
 replicas: 3      // 副本数
 selector:        // 标签选择器
  app: kubia      // rc只作用于携带此标签的pod
 template:        // pod模板
  metadata:
   label:
    app: kubia    // pod携带的标签，必须与上面相同
  spec:
   containers:
   - image: yfzhou528/kubia
     name: kubia
     livenessProbe: //探针
      httpGet:      //httpGet存活探针
         path: /      //get请求路径
         port: 8080   //get请求端口
        initialDelaySeconds: 15 //第一次探针检测在容器启动15s后，防止误探
     ports:
     - containerPort: 8080
       protocol: TCP

如果更改pod标签，rc会发现副本数不足而新建pod。如果更改rc标签，之前的pod全部失效，rc会再创建replicas个pod

更改rc文件（kubectl edit rc $rcname）的pod模板只会影响之后创建的pod，对现有pod无影响

扩缩容：更改rc文件的replicas实现，或者通过命令kubectl scale rc $rcname --replicas=5

删除rc会将其管理的pod也一并删除，可通过--cascade=false保留pod

--------------------ReplicaSet---------------------------------------

与ReplicationController的区别？P104 标签匹配功能更强：匹配多标签、匹配缺少某个标签、匹配标签key

apiVersion: apps/v1beta2
kind: ReplicaSet
metadata:
 name: kubia-rs
spec:
 replicas: 3      // 副本数
 selector:        // 标签选择器
  matchLables:    // *****matchLables选择器****
   app: kubia     // rc只作用于携带此标签的pod
 template:        // pod模板
  metadata:
   labels:
    app: kubia    // pod携带的标签，必须与上面相同
  spec:
   containers:
   - image: yfzhou528/kubia
     name: kubia
     livenessProbe: //探针
      httpGet:      //httpGet存活探针
         path: /      //get请求路径
         port: 8080   //get请求端口
        initialDelaySeconds: 15 //第一次探针检测在容器启动15s后，防止误探
     ports:
     - containerPort: 8080
       protocol: TCP

apiVersion: apps/v1beta2
kind: ReplicaSet
metadata:
 name: kubia-rs
spec:
 replicas: 3        // 副本数
 selector:          // 标签选择器
  matchExpressions: // *****matchExpressions选择器****
   - key: app       // pod标签的key必须是app
     operator: In   // pod标签的值必须在下面values集合中
     values:        // pod标签的值的集合
      - kubia
 template:          // pod模板
  metadata:
   labels:
    app: kubia    // pod携带的标签，必须与上面相同
  spec:
   containers:
   - image: yfzhou528/kubia
     name: kubia
     livenessProbe: //探针
      httpGet:      //httpGet存活探针
         path: /      //get请求路径
         port: 8080   //get请求端口
        initialDelaySeconds: 15 //第一次探针检测在容器启动15s后，防止误探
     ports:
     - containerPort: 8080
       protocol: TCP

---------------------DaemonSet--------------------------------------

通过标签选择器匹配节点，并在节点上创建并管理一个pod，当节点挂了之后不会在其他节点创建pod，当新加入一个节点时会在它上面新建一个pod。场景：集群日志收集系统

apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: kubia-ds
spec:
 selector:        // 标签选择器
  matchLabels:
   app: ssd-ds
 template:        // pod模板
  metadata:
   labels:
    app: ssd-ds   // 在创建pod时自动为pod打上此标签
  spec:
   nodeSelector:  // 节点选择器
    disk: ssd     // 只会在有此标签的节点上才会创建pod
   containers:
   - image: yfzhou528/kubia
     name: kubia

-------------------------Job----------------------------------

适用临时任务：运行完任务就终止

若pod内部进程成功结束，不重启容器；若pod异常退出会新建一个pod，直到完成任务

缺陷：资源创建后会立即运行任务，不能控制触发时间

apiVersion: batch/v1
kind: Job
metadata:
 name: kubia-job
spec:
 completions: 5       // *******顺序创建运行5个pod，用于任务需顺序执行5次的场景******
 parallelism: 2       // *******并行度，最多同时运行2个pod******
 backoffLlimit: 6     // *******job被标记为失败之前可重试的次数，默认6****
 selector:            // 标签选择器，管理此标签的pod
  matchLabels:
   app: batch-job
 template:            // pod模板
  metadata:
   labels:
    app: batch-job    // 在创建pod时自动为pod打上此标签
  spec:
   restartPolicy: OnFailure  // *******pod重启策略******
   activiDeadlineSeconds: 100 // ****pod运行超过100s则任务失败****
   containers:
   - image: yfzhou528/kubia
     name: kubia

CronJob

优势：在指定的时间运行job，注意同时启动多个job时要保证幂等

apiVersion: batch/v1
kind: CronJob
metadata:
 name: kubia-cron-job
spec:
 schedule: "0,30 * * * *"       // ********任务在每小时的0分、30分触发一次********
 jobTemplate:                   // job模板
  spec:
   template:                    // pod模板
    metadata:
     labels:
      app: batch-job            // 在创建pod时自动为pod打上此标签
    spec:
     restartPolicy: OnFailure   // pod重启策略
     activiDeadlineSeconds: 100 // pod运行超过100s则任务失败
     containers:
     - image: yfzhou528/kubia
       name: kubia

---------------------Service--EndPoint------------------------------------

功能：为辖内的pod提供外部访问入口，转发、负载均衡。

服务在整个生命周期内ip不变，辖内的pod不管怎么变动都无所谓，其他pod都可以通过访问service来间接访问pod

先创建service，再创建客户端pod，则客户端pod会自动在环境变量中添加service的ip及端口，通过这个就可以访问service

apiVersion: v1
kind: Service
metadata:
 name: kubia-service
spec:
 selector:            // 为此标签的pod提供对外服务及请求重定向
  app: kubia
 ports:               // service对外暴露的端口集合
 - name: http
   port: 80           // service对外暴露的端口
   targetPort: 8080   // service内的pod对应的接收转发端口
 - name: https
   port: 443
   targetPort: 8443 

service并不是直接和辖内的pod连接的，而是通过EndPoint资源，当service中指定selector选择器时会自动创建对应的EndPoint资源，如果不指定则需手动创建

service中的selector选择器将符合的pod的ip及port列表存储在EndPoint资源中，当service收到请求后会从EndPoint资源存储的列表中选择一个

apiVersion: v1
kind: Service
metadata:
 name: kubia-service-no-selector
spec:
 #selector:            // 不提供选择器
  #app: kubia
 ports:               // service对外暴露的端口集合
 - name: http
   port: 80           // service对外暴露的端口
   targetPort: 8080   // service内的pod对应的接收转发端口
 - name: https
   port: 443
   targetPort: 8443 
------------
apiVersion: v1
kind: EndPoints
metadata:
 name: kubia-service-no-selector// 必须与Service名字相同
subsets:                        // 手动提供pod的ip及端口
 - addresses:                   
   - ip: 11.11.11.11
   - ip: 22.22.22.22
   ports:
   - port: 80

向集群外部的客户端暴露服务的几种方式

1.通过节点负载均衡器暴露service：

apiVersion: v1
kind: Service
metadata:
 name: kubia-loadbalancer
spec:
 type: LoadBalancer   // *******该服务从k8s基础架构获取针对节点的负载平衡器*******
 selector:            // 为此标签的pod提供对外服务及请求重定向
  app: kubia
 ports:               // service对外暴露的端口集合
 - name: http
   port: 80           // service对外暴露的端口
   targetPort: 8080   // service内的pod对应的接收转发端口
 - name: https
   port: 443
   targetPort: 8443 

 -------------------------Ingress----------------------------------

2.通过Ingress暴露服务

通过LoadBalancer暴露服务的缺点：服务过多时，每个服务都需要独有的负载均衡器及公网ip

Ingress类似nginx，只需一个公网ip提供入口，然后根据请求域名找到对应的转发规则，将请求转发给对应的服务 P144

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: kubia-ingress
spec:
 rules:
 - host: kubia.example.com         // 对外域名，访问时映射到此服务
   http:
    paths:
    - path: /aa                    // 将kubia.example.com/aa请求发送到kubia-nodeport服务的80端口（nginx转发功能）
      backend:
       serviceName: kubia-nodeport // kubia-nodeport是一个NodePort类型的服务
       servicePort:80
 - host: kubia.example.com2       
   http:
    paths:
    - path: /bb                    // 将kubia.example.com2/bb请求发送到kubia-nodeport2服务的80端口（nginx转发功能）
      backend:
       serviceName: kubia-nodeport2
       servicePort:80

----------------------就绪探针-------------------------------------

service和其后端pod组成服务集群，当pod启动时，就绪探针会检查是否就绪，如果没就绪就不将pod添加到后端集群中，即不添加到Endpoint维护的ip:port列表，当探查到它就绪时再添加进去

就绪探针只会根据探查结果操作endpoint列表，不设计pod的删除、新建、重启。而存活探针会在容器不存活时重启容器，它针对的是容器不是pod。

apiVersion: v1
kind: ReplicationController
metadata:
 name: kubia-rc
spec:
 replicas: 3      // 副本数
 selector:        // 标签选择器
  app: kubia      // rc只作用于携带此标签的pod
 template:        // pod模板
  metadata:
   label:
    app: kubia    // pod携带的标签，必须与上面相同
  spec:
   containers:
   - image: yfzhou528/kubia
     name: kubia
     readinessProbe: //*******就绪探针,默认10s检查一次*******
      exec:
       command:
       - ls
       - /var/ready
     livenessProbe: //存活探针
      httpGet:      //httpGet存活探针
         path: /      //get请求路径
         port: 8080   //get请求端口
        initialDelaySeconds: 15 //第一次探针检测在容器启动15s后，防止误探
     ports:
     - containerPort: 8080
       protocol: TCP

----------------------持久卷PV、持久卷声明PVC-------------------------------------

PV是集群层面的资源，不属于任何一个命名空间；PVC是命名空间层面的资源

集群管理员创建PV资源，开发通过创建PVC资源，然后在pod的容器中挂载卷，并在pod资源的volumes属性的卷中指定PVC，来获取匹配的PV

一个PVC创建之后会自动与现有的PV匹配，匹配成功后PVC就和PV绑定了，这是在PVC创建时就完成的。一个PV只能同时被一个PVC绑定

#####创建持久卷PV#####
apiVersion: v1
kind: PersistentVolume
metadata:
 name: kubia-pv
spec:
 capacity:            |->PV容量
  storage: 1Gi        |
  
 accessModes:         |->PV支持的访问模式
 - ReadWriteOnce      |ReadWriteOnce：允许单客户端读写
 - ReadOnlyMany       |ReadOnlyMany:允许多客户端读
                      |ReadWriteMany:允许多客户端读写
                                       |->PV被PVC释放后，处理PV的策略
 persistentVolumeReclaimPolicy: Retain |Retain:保留不作处理
                                       |Recycle:删除卷的存储内容，可被其他PVC再次绑定循环使用
                                       |Delete:删除卷的存储内容，不可被其他PVC再次绑定
 nfs:
  path: "/data/k8s/volumes"   |
  server: 192.168.1.101       |->持久卷存储在哪，这里指定nfs服务器地址及存储目录
  readOnly: false             |
                                       

#####创建持久卷声明PVC#####
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: kubia-pvc    <---------------------------------------------------
spec:                                                                  |
 resources:            |                                               |
  requests:            |->声明需要的系统资源                           |
   storage: 1Gi        |                                               |
                                                                       |
 accessModes:          |->声明持久卷的访问模式                         |
 - ReadWriteOnce       |                                               |
                                                                       |
 storageClassName: ""  |确保PVC绑定到预先配置的PV，而不是自动生成的PV上|
                                                                       |
                                                                       |
#####创建Pod指定PVC#####                                               |
apiVersion: v1                                                         |
kind: Pod                                                              |
metadata:                                                              |
 name: kubia-pod                                                       |
spec:                                                                  |
 containers:                                                           |
 - image: yfzhou528/kubia                                              |
   name: kubia                                                         |
   ports:                                                              |
   - containerPort: 27017                                              |
     protocal: TCP                                                     |
   volumeMounts:                                                       |
   - name: kubia-data      |指定容器使用的卷名    <-------------       |
     mountPath: /data/db                                       |       |
 volumes:                  |自定义容器使用的卷名及卷对应的PVC  |       |
 - name: kubia-data   ---------------------------------------- |
   persistentVolumeClaim:  |                                           |
    claimName: kubia-pvc   |--------------------------------------------
     

----------------------ConfigMap-------------------------------------

创建configmap一般使用命令行模式而不是yaml模式

apiVersion: v1           
kind: Pod                
metadata:                
 name: kubia-configmap         
spec:                    
 containers:             
 - image: yfzhou528/kubia
   name: kubia           
   env:                    #指定环境变量
   - name: INTERVAL        #环境变量名<----------------------------
     valueFrom:            |                                      |
      configMapKeyRef:     |->环境变量源自ConfigMap               |
       name: my-configmap  #源自哪个ConfigMap，指定它的名字       |
       key: sleep-interval #将ConfigMap中哪个key的值赋给INTERVAL---

若Pod中某个container引用的ConfigMap不存在，则这个容器启动失败，pod中的其他容器无影响，当这个不存在的ConfigMap创建后，失败容器会自动重启

configMap卷：pod中的某个容器挂在一个卷，在这个卷中将configMap中的条目放进去，这样容器需要的卷内容就与卷声明解耦，依赖的条目内容改变后无需更改卷声明

配置热更新：kubectl edit修改ConfigMap的内容后，引用ConfigMap卷的容器和pod无需重启即可实现配置热更新，但是会有一定的延迟

apiVersion: v1           
kind: Pod                
metadata:                
 name: kubia-configmap         
spec:                    
 containers:             
 - image: yfzhou528/kubia
   name: kubia    
   
   volumeMounts:
   - name: config
     mountPath: /etc/zhou #将ConfigMap的条目挂载到容器的哪个目录
 volumes:
 - name: config
   configMap:              #configMap类型的卷
    name: myConfigMap      #哪个ConfigMap

Secret资源：类似ConfigMap，支持HTTPS

----------------------DownwardAPI卷-------------------------------------

apiVersion: v1           
kind: Pod                
metadata:                
 name: kubia-downward     
 labels:
  foo: bar
 annotations:
  key1: value1  
spec:                    
 containers:             
 - image: yfzhou528/kubia
   name: kubia    
   volumeMounts:
   - name: downVolume
     mountPath: /etc/zhou
 volumes:
 - name: downVolume
   downwardAPI:
    items:
    - path: "podName"
      fieldRef:
       fieldPath: metadata.name # kubia-downward
    - path: "labels"
      fieldRef:
       fieldPath: metadata.labels # foo: bar  
    - path: "annotations"
      fieldRef:
       fieldPath: metadata.annotations  # key1: value1  

自动更新：可以在pod运行时修改标签和注解，容器挂载的DownwardAPI卷中相关的pod元数据项将自动更新

DownwardAPI卷局限性：只能将本pod及容器的元数据传递给进程，对本pod之外的数据无能为力

容器可通过与K8S API服务器交互获取其他pod的元数据，但是需要认证和授权才行

在pod内专门创建一个代理容器负责与K8S API服务器交互，pod内的其他容器只需与代理容器交互即可，免去每个容器都有认证授权

----------------------***Deployment***----------------------------------

用于版本发布-滚动升级

通过Deployment资源触发滚动升级时，会自动创建一个新的ReplicaSet，新旧两个RS通过label来区分管理新旧版本的pod: P263

　　1.新RS创建后，在RS的selector中除了pod的标签，新增了一个deploment标签，它的值是当前版本pod模板的hash值，用于区分RS版本。由于旧pod中没有新增的deployment标签，所以旧pod不归新RS管理

　　2.旧pod也都会增加一个另外的deploment标签，这时旧RS仍然能管理旧pod

　　3.旧RS再增加这个相同的deploment标签，这时旧RS仍然能管理旧pod

Deployment滚动升级完成后，不会删除旧RS，此旧RS用于版本回滚

maxSurge+maxUnavailable控制滚动升级速率、minReadySeconds+就绪探针 阻止异常pod滚动升级：

apiVersion: apps/v1beta1           
kind: Deployment 
metadata:                
 name: kubia-deployment
spec:
 replicas: 3                    #升级后期望运行多少个pod
 minReadySeconds: 10            #新创建的pod成功运行多久后才视为可用
 strategy:                      #升级策略：
  type: RollingUpdate           #RollingUpdate(默认):渐进删除旧pod，同时创建新pod
                                #Recreate:在删除全部旧pod后，再创建新pod
  rollingUpdate:                #控制滚动升级速率：
   maxSurge: 1                  #在滚动升级期间，允许超出期望副本replicas的pod数。
                                #即允许最多同时存在pod数=replicas+maxSurge
   maxUnavailable: 0            #在滚动升级期间，相对于期望副本数，允许存在不可用状态pod的数量。
                                #即同时正常运行的最少pod数=replicas-maxUnavailable
                              
 template:                      #定义pod模板
  metadata:
   name: kubia
   labels:
    app: kubia
  spec:
   containers:             
   - image: yfzhou528/kubia:v2  #版本tag v2非常重要，代表本次要更新的版本号
     name: kubia    
     readinessProbe:            #就绪探针，配合minReadySeconds可阻止异常版本继续滚动升级
      periodSeconds: 1          #探测频率
      httpGet:
       path: /
       port: 8080

如何阻止异常pod滚动升级（maxUnavailable + minReadySeconds + 就绪探针）？

就绪探针在未超过minReadySeconds的时间内，探测到pod未就绪，而如果maxUnavailable设置为0，即表示不允许有不存活的pod存在，这就不能满足继续滚动升级的条件，导致滚动停止，若10分钟内没完成滚动升级则视为升级失败

---StatefulSet--------------------------------------------------------

可以用于解决RS的什么问题：RS的声明文件中，如果一个pod的某个容器挂载了一个卷，这个卷会制定一个PVC，这个PVC会绑定一个PV。如果RS的期望副本数>1，则多个pod中的这个容器都是用同一个PV，数据都往一处写，无法做到分开写。

StatefulSet不像RS那样指定PVC，而是通过指定一个PVC模板，同时先创建好多个PV，等SS创建pod时会通过PVC模板创建属于此pod的PVC实例，此PVC再绑定到创建好的PV中的一个，这样就做到了不同pod中的容器挂载不同的PV就行数据存储；

同时如果SS创建的pod挂了，SS进行恢复创建pod时，会和挂掉的pod保持相同的pod名、ip地址、pv，新pod仍可以使用挂掉的pod之前存储在pv中的数据

SS修改资源文件的副本数进行缩容时，会先删最高索引值的pod，删pod不会删它的PVC实例（如果需要释放PVC绑定的PV，需要手动删除PVC，这时数据就没了），这时如果再进行扩容，会使用没删的PVC实例及它绑定的PV中的数据，这中机制是为了保证误删pod时可以恢复数据。

SS资源创建步骤：

apiVersion: v1
kind: PersistentVolume
metadata:
 name: kubia-pv-a
spec:
 capacity:            
  storage: 1Gi        
 accessModes:         
 - ReadWriteOnce                       
 persistentVolumeReclaimPolicy: Retain 
 nfs:
  path: "/data/k8s/volumes/kubia-pv-a"
  server: 192.168.1.101    
  readOnly: false
---
apiVersion: v1
kind: PersistentVolume
metadata:
 name: kubia-pv-b
spec:
 capacity:            
  storage: 1Gi        
 accessModes:         
 - ReadWriteOnce                       
 persistentVolumeReclaimPolicy: Retain 
 nfs:
  path: "/data/k8s/volumes/kubia-pv-b"
  server: 192.168.1.101    
  readOnly: false
---
apiVersion: v1
kind: PersistentVolume
metadata:
 name: kubia-pv-c
spec:
 capacity:            
  storage: 1Gi        
 accessModes:         
 - ReadWriteOnce                                                     
 persistentVolumeReclaimPolicy: Retain                                                                            
 nfs:
  path: "/data/k8s/volumes/kubia-pv-c"
  server: 192.168.1.101    
  readOnly: false

apiVersion: v1
kind: Service
metadata:
 name: kubia-service
spec:
 clusterIP: None  #headless模式让客户端pod直接访问此service辖内的pod，而不是通过service来访问
 selector:
  app: kubia
  ports:
  - name: http
    port:80

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
 name: kubia-ss
spec:
 serviceName: kubia-service   #与上面创建的service对应
 replicas: 2
 template:
  metadata:
   labels:
    app: kubia
  spec:                    
   containers:             
   - image: yfzhou528/kubia
     name: kubia           
     ports:                
     - name: http
       containerPort: 8080 
     volumeMounts:         
     - name: kubia-data    
       mountPath: /data/db 
       
 volumeClaimTemplates:      |
 - metadata:                |
    name: kubia-data        |
   spec:                    |
    resources:              |->创建久卷声明模板
     requests:              |
      storage: 1Gi          |
     accessModes:           |
     - ReadWriteOnce        |
 

-----------------------------------------------------------