5分钟让你理解K8S必备架构概念，以及网络模型（中）

写在前面

在这用XMind画了一张导图记录Redis的学习笔记和一些面试解析（源文件对部分节点有详细备注和参考资料，欢迎关注个人公众号：阿风的架构笔记后台发送【导图】拿下载连接，已经完善更新）： node

前言

在上一篇文章中介绍了K8S的基础架构流程，以及核心的组件；这篇文章继续K8S的相关的概念。mysql

上篇介绍到了NodePort Service解决了外部请求K8S内部的应用的问题。下面咱们看看如何搭建应用服务集群的？nginx

应用集群

在传统应用中，咱们通常利用nginx反向代理，经过配置域名指向多个IP地址，从而实现了应用的集群。若是须要增长应用或减小应用，都须要调整nginx的配置；仍是至关繁琐的。面试

那K8S是如何实现应用集群的呢？sql

副本集ReplicaSet

上一篇文章中介绍了利用NodePort Service 的Selector 选择Label标签，路由到后端的其中一个Pod。数据库

上图中由3个Pod组成的应用集群，那如何保证Pod集群的高可用呢？若是其中一个Pod挂了，被删除了，K8S会怎么处理？后端

K8S有个Replica Set组件，从字面上面来看就是副本集意思；它的做用就是用来保证Pod的高可用，若是咱们在Replica Set中定义了应用数量为3，那么它会保证应用数量；即便一个pod挂了，它会自动会启动1个，始终保证pod应用数量为3。api

编写yamlmarkdown

apiVersion: extensions/v1beta1  #指定api版本
kind: ReplicaSet       #指定建立资源的角色/类型
metadata: 
  name: mc-user
spec: 
  replicas: 3       #副本集数量
  template:         #pod模板
    metadata:       #资源的元数据/属性 
      labels:       #标签订义
        app: mc-user  #标签值
    spec:           # 指定该资源的内容
      containers:    #容器定义
        - name: mc-user   #容器的名字 
          image: rainbow/mc-user:1.0.RELEASE    #容器镜像
复制代码

上面就是定义了 mc-user的pod，副本集数始终为3。Service的yaml和以前同样，注意Selector的Label，可提供给外部访问端口31001网络

apiVersion: v1
kind: Service
metadata: 
  name: mc-user
spec: 
  ports:
    - name: http
      port: 8080
      targetPort: 8080
      nodePort: 31001
  selector:
    app: mc-user
  type: NodePort
复制代码

执行kubectl apply -f 命令，启动ReplicaSet和Service

咱们能够试着查看启动的3个pod，并选择其中一个pod将它删除。

# kubectl get all
# kubectl delete po mc-user-6adfw
复制代码

咱们再查看pod

kubectl get all
复制代码

仍是有3个pod，能够看出即便删除了一个pod；ReplicaSet会又帮咱们启动了一个pod。

这个就是ReplicaSet的自愈能力，自我恢复能力。

滚动发布Rolling Update

咱们先来谈谈什么是滚动发布？滚动发布是一种高级发布策略，按批次依次替换老版本，逐步升级到新版本。发布过程当中，应用不中断，用户体验平滑。

如今Pod中是V1的版本，如今咱们想升级到V2版本，整个流程是什么样子呢？

先删除其中一个V1的pod

而后发布V2的Pod

再删除一个V1的pod

再启动一个V2的Pod

再删除最后一个V1的pod

最终升级完成。

咱们能够发现滚动发布的特色，就是老版本和新版本会共存一段时间。因此此种发布方式适用版本兼容的应用。也能够支持滚动回退。咱们来看看和蓝绿发布的区别

滚动发布抽象Deployment

以前介绍的ReplicaSet 实际上是对Pod的一次包装，Deployment又在基础上面对ReplicaSet的又一次包装。

注意点：ReplicaSet 和 Deployment是一个软件概念，它是没有具体的组件的；是抽象出来的名词，方便你们理解

上图就是描述了deployment滚动发布的架构；Deployment的滚动发布，对用户请求以及Service是透明的，无感知。

Deployment的yaml

apiVersion: apps/v1  #指定api版本，此值必须在kubectl apiversion中
kind: Deployment       #指定建立资源的角色/类型
metadata: 
  name: mc-user
spec: 
  selector:           #此deployment选择哪一个标签进行滚动的发布
    matchLabels:      #滚动发布pod的标签，要跟下面template中的labels一致
      app: mc-user
  minReadySeconds: 10 #最小10s等待就绪时间，能够方便看到滚动发布流程
  replicas: 3       #副本集数量
  template:         #pod模板
    metadata:       #资源的元数据/属性 
      labels:       #标签订义
        app: mc-user  #标签值
    spec:           #指定该资源的内容
      containers:    #容器定义
        - name: mc-user   #容器的名字 
          image: rainbow/mc-user:1.0.RELEASE    #容器镜像
复制代码

上面的yaml和ReplicaSet很相似，须要注意的

selector:        #此deployment选择哪一个标签进行滚动的发布
   matchLabels:  #滚动发布pod的标签，要跟下面template中的labels一致
      app: mc-user
复制代码

定义deployment管理哪一个标签pod

Service的yaml

Service的yaml没有变化，须要定义selector，选择标签就好了

apiVersion: v1
kind: Service
metadata: 
  name: mc-user
spec: 
  ports:
    - name: http
      port: 8080
      targetPort: 8080
      nodePort: 31000
  selector:
    app: mc-user
  type: NodePort
复制代码

咱们用kubectl apply -f命令执行 deployment和service

咱们再用kubectl get all获取运行状况，咱们就能够发现有两个类型

deployment.apps/mc-user 以及 replicaset.apps/mc-user-4345afaa

要升级的时候，只须要更改deployment中的image名称，再执行apply

image: rainbow/mc-user:1.1.RELEASE    #容器镜像
复制代码

咱们用kubectl get all查看，就会发现replicaset 有2个；一个是老版本的，一个是新版本的。老版本的pod数逐渐减小，新版本的pod数量逐渐增长，一直到新版本为3，老版本为0。

回退版本

若是发现版本有问题，咱们能够回退版本，可使用下面命令

kubectl rollout undo deployment/mc-user
复制代码

这个咱们就回退到V1.0的老版本了。

ConfigMap配置

在咱们平常业务过程当中，须要会配置一些配置参数，如：一次性的静态配置（数据库链接字符串，用户名，密码），以及能够运行过程当中的动态配置（如：限购数量）等；那K8S中的Pod如何得到外部的配置信息呢？

上图中，K8S提供了ConfigMap这个功能，提供用户在外部进行配置，而后K8S把ConfigMap以环境变量的方式提供给Pod中的容器或者也能够经过Volume文件持久化的方式提供给Pod容器。

共享配置

由于咱们会有不少服务的配置是相同的，那实现微服务之间共享一份配置信息，以下图

一份ConfigMap能够提供给多个服务使用，ConfigMap会把配置信息以env方式存在于每一个服务的环境变量中。

ConfigMap的yaml

apiVersion: v1  #指定api版本，此值必须在kubectl apiversion中
kind: ConfigMap       #指定建立资源的角色/类型
metadata: 
  name: mc-user-config
data: #定义配置信息
  DATASOURCE_URL: jdbc:mysql://mysql/mc-user
  DATASOURCE_USERNAME: root
  DATASOURCE_PASSWORD: 123456
复制代码

修改Deployment配置文件

增长envFrom属性

apiVersion: apps/v1  #指定api版本，此值必须在kubectl apiversion中
kind: Deployment     #指定建立资源的角色/类型
metadata: 
  name: mc-user
spec: 
  selector:           #此deployment选择哪一个标签进行滚动的发布
    matchLabels:      #滚动发布pod的标签，要跟下面template中的labels一致
      app: mc-user
  minReadySeconds: 10 #最小10s等待就绪时间，能够方便看到滚动发布流程
  replicas: 3       #副本集数量
  template:         #pod模板
    metadata:       #资源的元数据/属性 
      labels:       #标签订义
        app: mc-user  #标签值
    spec:           #指定该资源的内容
      containers:    #容器定义
        - name: mc-user   #容器的名字 
          image: rainbow/mc-user:1.0.RELEASE    #容器镜像
          envFrom:  #环境变量来源
            - configMapRef: #容器应用的configmap引用
                name: mc-user-config #configMap的名称
复制代码

envFrom中的configMapRef配置引用名称；这样咱们就能够在pod容器中获取到configmap的配置信息了。咱们能够用

kubectl exec mc-user-34wrwq-3423 printenv ｜ grep DATASOURCE_NAME
复制代码

得到pod容器中的环境变量。

configMap变动

若是服务已经运行中，咱们更新了ConfigMap的配置信息，那么POD中的容器会即时得到新的配置信息吗？

很不幸，更新了configMap；再用kubectl apply -f 从新发布configmap；以前的pod容器是不会得到最新的配置信息的。

那如何让pod容器用最新的ConfigMap配置值呢？咱们能够删除pod，由于replicaset会保证pod数量，会自动重启，那新的pod就会应用新的配置信息了。

总结

今天介绍K8S的副本集ReplicaSet、滚动发布Deployment、配置ConfigMap的概念；下一篇会介绍网络相关的模型。谢谢！！！

看完三件事❤️

若是你以为这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：

点赞，转发，有大家的『点赞和评论』，才是我创造的动力。
关注公众号 『阿风的架构笔记』，不按期分享原创知识。
同时能够期待后续文章ing🚀
关注后回复【666】扫码便可获取架构进阶学习资料包