k8s学习环境搭建（5分钟让你理解K8S必备架构概念）

目录

1. 前言
2. 应用集群
3. 副本集
4. 滚动发布流程
5. ConfigMap
6. 总结

前言

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

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

应用集群

在传统应用中，我们一般利用nginx反向代理，通过配置域名指向多个IP地址，从而实现了应用的集群。如果需要增加应用或减少应用，都需要调整nginx的配置；还是相当繁琐的。

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

副本集ReplicaSet

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

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

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

编写yaml

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的概念；下一篇老顾会介绍网络相关的模型。谢谢！！！

---End---

---

老顾的微服务网关分享课程，请大家多多支持

推荐阅读

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

大厂如何基于binlog解决多机房同步mysql数据（一）？

大厂如何基于binlog解决多机房同步mysql数据（二）？

基于binlog的canal组件有哪些使用场景（三）？

基于binlog日志之canal企业应用及高可用原理（四）？

可用于大型应用的微服务生态灰度发布如何实现？

一线大厂级别公共Redis集群监控，细化到每个项目实例

Sharding-jdbc的实战入门之水平分表（一）

Sharding-Jdbc之水平分库和读写分离（二）

a、dubbo如何处理业务异常，这个一定要知道哦！

b、企业级SpringBoot应用多个子项目配置文件规划、多环境支持（一）

c、企业级SpringBoot应用多个子项目配置文件规划、多环境支持（二）

d、企业级SpringBoot应用多个子项目配置文件之配置中心（三）

e、利用阿里开源工具进行排查线上CPU居高问题

f、阿里二面：如何快速排查死锁？如何避免死锁？

g、微服务分布式架构中，如何实现日志链路跟踪？

h、网关如何聚合各个微服务的接口文档？

i、Kubernetes之POD、容器之间的网络通信

j、K8S中的Service的存在理由

k、企业微服务项目如何进入K8S的全过程

l、阿里开源项目Sentinel限流、降级的统一处理

m、大厂二面：Redis的分布式布隆过滤器是什么原理？

1、基于RocketMq的SpringCloud Stream框架实战入门

2、如何搭建消息中间件应用框架之SpringCloud Stream

3、面试必备：网关异常了怎么办？如何做全局异常处理？

4、Gateway网关系列(二)：SpringCloud Gateway入门实战，路由规则

5、Gateway网关系列开篇：SpringCloud的官方网关Gateway介绍

6、API网关在微服务架构中的应用，这一篇就够了

7、学习Lambda表达式看这篇就够了，不会让你失望的哦（续篇）

8、Lambda用在哪里？几种场景？

9、为什么会出现Lambda表达式，你知道吗？

10、不说“分布式事务”理论，直接上大厂阿里的解决方案，绝对实用

11、女程序员问到这个问题，让我思考了半天，Mysql的“三高”架构

12、大厂二面：CAP原则为什么只能满足其中两项？而不能同时满足

13、阿里P7二面：聊聊零拷贝的原理

14、秒杀系统的核心点都在这里，快来取

15、你了解如何利用token方式实现分布式Session吗？

16、Mysql索引结构演变，为什么最终会是那个结构呢？让你一看就懂

17、一场比赛涉及到的知识，用通俗易通的方式介绍并发协调

18、企业实战Redis全方面思考，你思考了吗？

19、面试题：Thread的start和run的区别

20、面试题：什么是CAS？CAS的作用以及缺点

21、如何访问redis中的海量数据？避免事故产生

22、如何解决Redis热点问题？以及如何发现热点？

23、如何设计API接口，实现统一格式返回？

24、你真的知道在生产环境下如何部署tomcat吗？

25、分享一线互联网大厂分布式唯一ID设计 之 snowflake方案

26、分享大厂分布式唯一ID设计方案，快来围观

27、你想了解一线大厂的分布式唯一ID生成方案吗？

28、你知道如何处理大数据量吗？(数据拆分篇)

29、如何永不迁移数据和避免热点? 根据服务器指标分配数据量(揭秘篇)

30、你知道怎么分库分表吗？如何做到永不迁移数据和避免热点吗？

31、你了解大型网站的页面静态化吗？

32、你知道如何更新缓存吗？如何保证缓存和数据库双写一致性？

33、你知道怎么解决DB读写分离，导致数据不一致问题吗？

34、DB读写分离情况下，如何解决缓存和数据库不一致性问题？

35、你真的知道怎么使用缓存吗？

36、如何利用锁，防止缓存击穿？重构思想的重要性

37、海量订单产生的业务高峰期，如何避免消息的重复消费？

38、你知道如何保障生产端100%消息投递成功吗？

39、微服务下的分布式session该如何管理？

40、阿里二面：filter、interceptor、aspect应如何选择？很多人中招

41、互联网架构重要组员CDN，很多高级开发都没有实操过，来看这里

42、阿里二面：CDN缓存控制原理，看看能不能难住你

43、SpringCloud Alibaba之Nacos多环境多项目管理

44、SpringCloud Alibaba系列之Nacos配置中心玩法

45、SpringCloud Alibaba之Nacos注册中心

46、SpringCloud Plus版本之SpringCloud Alibaba

47、SpringCloud Alibaba之Nacos集群、持久化

48、SpringCloud Alibaba之Nacos共享配置、灰度配置

49、SpringCloud Alibaba之Sentinel工作原理

50、SpringCloud Alibaba之Sentinel流控管理

51、SpringCloud Alibaba之Sentinel降级管理

52、SpringCloud Alibaba之Sentinel热点参数限流

53、SpringCloud Alibaba之Sentinel的API实战

,