K8S三种发布方式和声明式资源管理

|-------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 蓝绿发布 | 把应用服务集群标记位两个组，蓝组和绿组，先升级蓝组，先要把蓝组从负载均衡当中移除，绿组继续提供服务，蓝组升级完毕，再把绿组从负载均衡当中移除，绿组升级，然后都加入回负载均衡当中去，完成对外服务，对硬件资源要求很高，但是有了云计算和微服务，现在的成本也大大降低了特点： 1.一旦出现问题，问题影响范围很大 2.发布策略简单 3.基于云计算技术和微服务，用户是无感知的 4.升级和回滚都比较方便缺点：在发布升级的过程之中，只有一部分集群在对外服务，可能会使集群的负载能力下降，响应变慢,需要注意给集群增加负载能力（一般来说没什么特殊需求）段时间内可能会浪费一定的资源成本 |
| 金丝雀发布（灰度发布） | 基于deployment控制器创建的服务，才可以使用这种发布方式，也算是一种滚动更新，实现了一个步骤叫暂停，也就是发布的过程中，暂时停止，只有一部分的pod先升级，其他的pod还是处于老的版本，只有一部分用户可以访问新的版本，绝大数用户还在老版本，确定无问题之后，再把剩下的老版本升级成新的版本，也就是把暂停取消，继续发布，如果有问题可以立即回滚，暂停不是回滚，一旦取消暂停只能全部升级完毕之后，再回滚。特点：自动化的要求比较高，对运维人员的要求比较高方便发现问题，及时解决，影响范围比较小用户无感知，可以实现平滑过渡，而且比较节约资源发布策略比较复杂不易回滚，必须等到全部发布成功之后才能回滚。 |
| 滚动发布 | deployment的默认更新方式 |
| | 应用程序升级，面临的最大的问题是新旧业务之间的切换，从立项>定稿>需求发布>开发>测试>发布，测试之后上线，再完美也会有问题，为了不让发生的问题影响所有用户，有了上述的三种发布方式 |

声明式资源管理(yaml文件)

|---|--------------------------------|
| 1 | 适合对资源的修改操作 |
| 2 | 声明式管理依赖于yaml文件，所有的内容都在yaml文件当中 |
| 3 | 编辑好的yaml文件还是要靠陈述式命令发布到k8s集群当中 |

|-------------------|------------------------------------------------|
| Kubectl create | 只能创建，不能更新，从指定yaml文件中读取配置，创建服务，不能更新 |
| Kubectl apply -f | 既可以创建资源对象也可以更新资源对象，如果yaml文件更改了，apply可以直接更新资源对象 |
| Kubectl delete -f | 删除yaml文件中声明的资源对象，如deployment或者pod和service |

Yaml文件如何生成

|---|-------------------------------------------------------------------------|
| 1 | 手打 |
| 2 | 可以根据已有的资源，直接生成 1.deployment的yaml文件 2.Service的yaml文件 3.不基于控制器的pod的yaml文件 |

k8s当中支持两种声明式资源管理方式

|--------|------------------|
| yaml格式 | 用来配置和管理资源对象 |
| Json格式 | 主要用于api接口之间消息的传递 |

bash 复制代码

[root@master01 k8s.yaml]# kubectl get deployments.apps
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
myapp-test   0/3     3            0           5d
nginx-chen   0/1     1            0           40h
[root@master01 k8s.yaml]# kubectl get deployments.apps nginx-chen -o yaml
展示yaml文件
[root@master01 k8s.yaml]# kubectl get deployments.apps nginx-chen -o yaml > /opt/k8s.yaml/nginx-chen.yaml
导出修改
[root@master01 k8s.yaml]# vim nginx-chen.yaml
[root@master01 k8s.yaml]# kubectl apply -f nginx-chen.yaml
Warning: resource deployments/nginx-chen is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
deployment.apps/nginx-chen configured
第二次更新必须要导出之后才能更新
[root@master01 k8s.yaml]# kubectl get pod

deployment

bash 复制代码

apiVersion: apps/v1
#声明API版本的标签
kind: Deployment
#定义资源的类型service/pod/deployment/jod/ingress/daemonset/statefulset
metadata:
  name: nginx1
  namespace: chen
  labels:
    wdf: nginx1
#标签名可以自定义
#定义资源的元数据信息，资源名称，资源对象部署的命名空间，标签等等信息
spec:
#定义deployment的资源需要的参数属性
  replicas: 3
#定义副本数
  selector:
#定义标签选择器
    matchLabels:
      wdf: nginx1
#选择匹配的标签
  template:
#定义业务模版，如果定义了多个副本，所有的副本的属性都会按照模版的配置进行匹配
    metadata:
      labels:
        wdf: nginx1
#定义了pod的副本都使用元数据的标签和属性来进行匹配
    spec:
      containers:
      - name: nginx
        image: nginx:1.10
        posts:
        - containerPort: 80
#spec声明的是容器的相关参数,虽然我指定了容器的暴露端口是80，nginx默认的镜像就是80，即使声明了其他端口，也不会改变容器的端口，除非nginx的端口已经被修改，那么这里声明端口是可以的

service

bash 复制代码

#定义API的版本
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  namespace: chen
  labels:
    wdf: nginx1
#这里的元数据信息包括，service的名称，所属的命名空间，以及要匹配的deployment的标签，这里的标签要和之前的标签名保持一致，否则它不知道为谁服务
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
   #nodepord: 30000
#这里可以指定访问端口，可以以不指定，不指定就会随机分配（范围是30000-32764）
  selector:
    wdf: nginx1
#匹配所有的标签都是wdf:nginx1的pod后端提供服务

pod

bash 复制代码

#定义pod的apirversion
apiVersion: v1
#定义资源的类型
kind: Pod
#定义元数据信息，主要是一些pod的名称，命名空间，标签
metadata:
  name: centos1
  namespace: chen
spec:
  restartPolicy: Never
#restartPolicy指的是pod内的容器启动失败或者有问题的重启策略：Always Never Onfailue ##三种重启策略,只有异常退出才会重启，状态非0，如果状态是0，不重启,restartPolicy指的是容器的重启策略，资源类
型定义为deployment，容器的重启策略只能是Always
  containers:
  - name: centos
    image: centos:7
    command: ["echo"]
    args: ["hello,word!"]

command
args
定义容器运行的命令参数，类型于docker的CMD和entrypoint
args可以理解docker中的cmd 给command传参
command和args都会覆盖原容器的标准输出（cmd）
 
 
#定义pod的apiversion
apiVersion: v1
#定义资源的类型
kind: Pod
#定义元数据信息，pod的名称，所属的标签
metadata:
  name: centos1
spec:
  restartPolicy: Always
#restartPolicy指的是pod内的容器启动失败或者有问题的重启策略：always 指的是总是重启  never 指的是挂就挂了 Onfailure（只有异常退出才会重启，状态非0，如果状
态码是0，不重启），restartPolicy指的是容器的重启策略，资源类型定义为deployment，容器的重启策略只能是Always
  containers:
  - name: centos
    image: centos:7
    args:
    - /bin/bash
    - -c
    - while true; do sleep 3600; done
#多个命令要用分号隔开
 
 
#定义pod的apiversion
apiVersion: v1
#定义资源的类型
kind: Pod
#定义元数据信息，pod的名称，所属的标签
metadata:
  name: centos1
  namespace: xiaobu
spec:
  restartPolicy: Always
#restartPolicy指的是pod内的容器启动失败或者有问题的重启策略：always 指的是总是重启  never 指的是挂就挂了 Onfailure（只有异常退出才会重启，状态非0，如果状
态码是0，不重启），restartPolicy指的是容器的重启策略，资源类型定义为deployment，容器的重启策略只能是Always
  containers:
  - name: centos
    image: centos:7
    command: ["/usr/bin/test", "-e", "/etc/passwd"]
    command: ["/bin/bash", "-c", "touch /tmp/live ; sleep 30; rm -rf /tmp/live; slepp 3600"]
#command和args只能有一个,会把容器的标准输出覆盖，不论是args和commmand都会覆盖CMD和ENTYRPOINT
 
command和args不要同时出现，除非你要传参，都会容器的标准输出