【云原生 | 从零开始学Kubernetes】十四、k8s核心技术-Controller

简介: 前面我们学习了 Pod,那我们在定义 pod 资源时,可以直接创建一个 kind:Pod 类型的自主式 pod, 但是这存在一个问题,假如 pod 被删除了,那这个 pod 就不能自我恢复,就会彻底被删除,线上这种情况非常危险,所以今天就给大家讲解下 pod 的控制器,所谓控制器就是能够管理 pod,监测 pod 运行状况,当 pod 发生故障,可以自动恢复 pod。

前面我们学习了 Pod,那我们在定义 pod 资源时,可以直接创建一个 kind:Pod 类型的自主式 pod, 但是这存在一个问题,假如 pod 被删除了,那这个 pod 就不能自我恢复,就会彻底被删除,线上这种情况非常危险,所以今天就给大家讲解下 pod 的控制器,所谓控制器就是能够管理 pod,监测 pod 运行状况,当 pod 发生故障,可以自动恢复 pod。也就是说能够代我们去管理 pod 中间层,并帮助我们确保每一个 pod 资源始终处于我们所定义或者我们所期望的目标状态,一旦 pod 资源出现故障,那么控制器会尝试重启 pod 或者里面的容器,如果一直重启有问题的话那么它可能会基于某种策略来进行重新布派或者重新编排;如果 pod 副本数量低于用户所定义的目标数量,它也会自动补全;如果多余,也会自动终止 pod 资源。


什么是Controller


Controller是在集群上管理和运行容器的对象,Controller是实际存在的,Pod是虚拟机的


Pod和Controller的关系


Pod是通过Controller实现应用的运维,比如弹性伸缩,滚动升级等


Pod 和 Controller之间是通过label标签来建立关系,同时Controller又被称为控制器工作负载


45.png


Replicaset 控制器


Replication Controller 简称 RC,是K8S中的复制控制器。RC是K8S集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个;少于指定数目,RC就会启动新的Pod副本;多于指定数目,RC就会杀死多余的Pod副本。


即使在指定数目为1的情况下,通过RC运行Pod也比直接运行Pod更明智,因为RC也可以发挥它高可用的能力,保证永远有一个Pod在运行。RC是K8S中较早期的技术概念,只适用于长期伺服型的业务类型,比如控制Pod提供高可用的Web服务。


ReplicaSet 简称 RS,也就是副本集。RS是新一代的RC,提供同样高可用能力,区别主要在于RS后来居上,能够支持更多种类的匹配模式。副本集对象一般不单独使用,而是作为Deployment的理想状态参数来使用


Replicaset 概述


ReplicaSet 简称 RS,也就是副本集。RS是新一代的RC,提供同样高可用能力,区别主要在于RS后来居上,能够支持更多种类的匹配模式。副本集对象一般不单独使用,而是作为Deployment的理想状态参数来使用,它的主要作用是控制由其管理的 pod,使 pod 副本的数量始终维持在预设的个数。它的主要作用就是保证一定数量的 Pod 能够在集群中正常运行,它会持续监听这些 Pod 的运行状态,在 Pod 发生故障时重启pod,pod数量减少时重新运行新的Pod副本。


官方推荐不要直接使用ReplicaSet,用Deployments取而代之,Deployments 是比 ReplicaSet 更高级的概念,它会管理 ReplicaSet 并提供很多其它有用的特性,最重要的是 Deployments 支持声明式更新,声明式更新的好处是不会丢失历史变更。所以 Deployment 控制器不直接管理 Pod 对象,而是由 Deployment 管理 ReplicaSet,再由 ReplicaSet 负责管理 Pod 对象。


Replicaset 工作原理:如何管理 Pod?


Replicaset 核心作用在于代用户创建指定数量的 pod 副本,并确保 pod 副本一直处于满足用户期望的数量, 起到多退少补的作用,并且还具有自动扩容缩容等机制。


Replicaset 控制器主要由三个部分组成:


1、用户期望的 pod 副本数:用来定义由这个控制器管控的 pod 副本有几个


2、标签选择器:选定哪些 pod 是自己管理的,如果通过标签选择器选到的 pod 副本数量少于我们 指定的数量,需要用到下面的组件


3、pod 资源模板:如果集群中现存的 pod 数量不够我们定义的副本中期望的数量怎么办,需要新 建 pod,这就需要 pod 模板,新建的pod 是基于模板来创建的。


Replicaset 资源清单文件编写技巧


#查看定义 Replicaset 资源需要的字段有哪些? 
[root@k8smaster ~]# kubectl explain replicaset
KIND:     ReplicaSet
VERSION:  apps/v1
DESCRIPTION:
     ReplicaSet ensures that a specified number of pod replicas are running at
     any given time.
FIELDS:
   apiVersion <string>    #当前资源使用的 api 版本,跟 VERSION: apps/v1 保持一致 
   kind <string>        #资源类型,跟 KIND: ReplicaSet 保持一致
   metadata <Object>      #元数据,定义 Replicaset 名字的 
   spec <Object>        #定义副本数、定义标签选择器、定义 Pod 模板 
   status <Object>      #状态信息,不能改 
#查看 replicaset 的 spec 字段如何定义? 
[root@k8smaster ~]# kubectl explain rs.spec
KIND:     ReplicaSet
VERSION:  apps/v1
RESOURCE: spec <Object>
DESCRIPTION:
     Spec defines the specification of the desired behavior of the ReplicaSet.
     More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
     ReplicaSetSpec is the specification of a ReplicaSet.
FIELDS:
   minReadySeconds  <integer>
   replicas <integer>       #定义的 pod 副本数,根据我们指定的值创建对应数量的 pod 
   selector <Object> -required-   #用于匹配 pod 的标签选择器 
   template <Object>        #定义 Pod 的模板,基于这个模板定义的所有 pod 是一样的 
#查看 replicaset 的 spec.template 字段如何定义? 
#对于 template 而言,其内部定义的就是 pod,pod 模板是一个独立的对象 
[root@k8smaster ~]# kubectl explain rs.spec.template 
KIND:     ReplicaSet
VERSION:  apps/v1
RESOURCE: template <Object>
DESCRIPTION:
     Template is the object that describes the pod that will be created if
     insufficient replicas are detected. More info:
     https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template
     PodTemplateSpec describes the data a pod should have when created from a
     template
FIELDS:
   metadata <Object>
   spec <Object>
[root@k8smaster ~]# kubectl explain rs.spec.template.spec 
通过上面可以看到,ReplicaSet 资源中有两个 spec 字段。第一个 spec 声明的是 ReplicaSet 定义多少个 Pod 副本(默认将仅部署 1 个 Pod)、匹配 Pod 标签的选择器、创建 pod 的模板。第二个 spec 是spec.template.spec,主要用于 Pod 里的容器属性等配置。 
.spec.template 里的内容是声明 Pod 对象时要定义的各种属性,所以这部分也叫做 PodTemplate(Pod 模板)。还有一个值得注意的地方是:在.spec.selector 中定义的标签选择器必须能够匹配到 spec.template.metadata.labels 里定义的 Pod 标签,否则 Kubernetes 将不允许创建 ReplicaSet。 
3、Replicaset 使用案例:部署 Guestbook 留言板 
[root@k8snode2 ~]# docker pull konradkleine/docker-registry-frontend:v2
[root@k8snode ~]# docker pull konradkleine/docker-registry-frontend:v2
#编写一个 ReplicaSet 资源清单
[root@k8smaster node]# vim replicaset.yaml 
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: konradkleine/docker-registry-frontend:v2
        imagePullPolicy: IfNotPresent
        command: ["/bin/bash","-ce","tail -f /dev/null"]
[root@k8smaster node]# kubectl apply -f replicaset.yaml 
replicaset.apps/frontend created
[root@k8smaster node]# kubectl get rs 
NAME              DESIRED   CURRENT   READY   AGE
frontend          3         3         3       17s
[root@k8smaster node]# kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
frontend-6x5gl          1/1     Running   0          28s
frontend-ncgcj          1/1     Running   0          28s
frontend-z74hg          1/1     Running   0          28s
#pod 的名字是由控制器的名字-随机数组成的 如果yaml怕写错可以explain rs 看一下字段或者复制
#资源清单详细说明 
apiVersion: apps/v1 #ReplicaSet 这个控制器属于的核心群组 
kind: ReplicaSet #创建的资源类型 
metadata: 
 name: frontend #控制器的名字 
 labels: 
 app: guestbook 
 tier: frontend 
spec:
 replicas: 3 #管理的 pod 副本数量 
 selector: 
 matchLabels: 
 tier: frontend #管理带有 tier=frontend 标签的 pod 
 template: #定义 pod 的模板 
 metadata: 
 labels: 
 tier: frontend 
#pod 标签,一定要有,这样上面控制器就能找到它要管理的 pod 是哪些了 
 spec: 
 containers: #定义 pod 里运行的容器 
 - name: php-redis #定义容器的名字 
 image:  konradkleine/docker-registry-frontend:v2
 ports: #定义端口 
- name: http #定义容器的名字 
containerPort: 80 #定义容器暴露的端口


Replicaset 管理 pod:扩容、缩容、更新


#Replicaset 实现 pod 的动态扩容 
ReplicaSet 最核心的功能是可以动态扩容和回缩,如果我们觉得两个副本太少了,想要增加,只需要修改配置文件 replicaset.yaml 里的 replicas 的值即可,原来 replicas: 3,现在变成 replicaset: 5,修改之后,执行如下命令更新
[root@k8smaster node]# kubectl apply -f replicaset.yaml 
replicaset.apps/frontend configured
[root@k8smaster node]# kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
frontend-6x5gl          1/1     Running   0          61m
frontend-fk5vl          1/1     Running   0          8s
frontend-lvclg          1/1     Running   0          8s
frontend-ncgcj          1/1     Running   0          61m
frontend-z74hg          1/1     Running   0          61m
[root@k8smaster node]# kubectl get rs
NAME              DESIRED   CURRENT   READY   AGE
frontend          5         5         5       61m
 #也可以直接编辑控制器实现扩容 
#这个是我们把请求提交给了 apiserver,实时修改 
[root@k8smaster node]# kubectl edit rs frontend
replicaset.apps/frontend edited
#可以开两个窗口 动态查看
[root@k8smaster node]# kubectl get pods -w
#Replicaset 实现 pod 的动态缩容 
如果我们觉得 5 个 Pod 副本太多了,想要减少,只需要修改配置文件 replicaset.yaml 里的replicas 的值即可,把 replicaset:4 变成 replicas: 3,修改之后,执行如下命令更新
[root@k8smaster node]# kubectl apply -f replicaset.yaml 
[root@k8smaster node]# kubectl get rs
NAME              DESIRED   CURRENT   READY   AGE
frontend          3         3         3       64m
[root@xianchaomaster1 ~]# kubectl get pods 
NAME READY STATUS RESTARTS AGE 
frontend-j6twz 1/1 Running 0 70m 
frontend-lcnq6 1/1 Running 0 70m
#Replicaset 实现 pod 的更新
#修改镜像变成image: nginx,修改之后保存退出 
[root@k8smaster node]# vim replicaset.yaml 
#把里面 command: ["/bin/bash","-ce","tail -f /dev/null"]删除 并且image改成nginx
[root@k8smaster node]# kubectl get rs -o wide
NAME              DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES   SELECTOR
frontend          3         3         3       67m   php-redis    nginx    tier=frontend
#上面可以看到镜像变成了 nginx,说明滚动升级成功了 
[root@k8smaster node]# kubectl get pods -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP            NODE       NOMINATED NODE   READINESS GATES
frontend-6x5gl          1/1     Running   0          68m   10.244.1.11   k8snode2   <none>           <none>
frontend-ncgcj          1/1     Running   0          68m   10.244.2.26   k8snode    <none>           <none>
frontend-z74hg          1/1     Running   0          68m   10.244.1.12   k8snode2   <none>           <none>
#虽然镜像已经更新了,但是原来的 pod 使用的还是之前的镜像,新创建的 pod 才会使用最新的镜像
[root@k8smaster node]# kubectl delete pods frontend-6x5gl     第一个终端删除
pod "frontend-6x5gl" deleted
[root@k8smaster node]# kubectl get pods -w              第二个终端
NAME                    READY   STATUS    RESTARTS   AGE
frontend-6x5gl          1/1     Running   0          71m
frontend-ncgcj          1/1     Running   0          71m
frontend-z74hg          1/1     Running   0          71m
frontend-6x5gl          1/1     Terminating   0          71m
frontend-t8x72          0/1     Pending       0          0s
frontend-t8x72          0/1     Pending       0          0s
frontend-t8x72          0/1     ContainerCreating   0          0s
frontend-t8x72          1/1     Running             0          1s
#重新生成了一个新的 pod:frontend-t8x72
[root@k8smaster node]# curl 10.244.2.30
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
#新生成的 pod 的镜像已经变成了nginx 的,说明更新完成了 


生产环境如果升级,可以删除一个 pod,观察一段时间之后没问题再删除另一个 pod,但是这样需要人工干预多次;实际生产环境一般采用蓝绿发布,原来有一个 rs1,再创建一个 rs2(控制器),通过修改 service 标签,修改 service 可以匹配到 rs2 的控制器,这样才是蓝绿发布,这个也需要我们精心的部署规划,我们有一个控制器就是建立在 rs 之上完成的,叫做 Deployment。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
17天前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
16天前
|
Cloud Native 持续交付 开发者
云原生技术在现代企业中的应用与实践####
本文深入探讨了云原生技术的核心概念及其在现代企业IT架构转型中的关键作用,通过具体案例分析展示了云原生如何促进企业的敏捷开发、高效运维及成本优化。不同于传统摘要仅概述内容,本部分旨在激发读者对云原生领域的兴趣,强调其在加速数字化转型过程中的不可或缺性,为后续详细论述奠定基础。 ####
|
5天前
|
Cloud Native
邀您参加云原生高可用技术沙龙丨云上高可用体系构建:从理论到实践
云原生高可用技术专场,邀您从理论到实践一起交流,探索云上高可用体系构建!
|
16天前
|
Cloud Native JavaScript Docker
云原生技术:构建现代应用的基石
在数字化转型的浪潮中,云原生技术如同一艘承载梦想的航船,引领企业驶向创新与效率的新海域。本文将深入探索云原生技术的核心价值,揭示其如何重塑软件开发、部署和运维模式,同时通过一个简易代码示例,展现云原生应用的构建过程,让读者领略到云原生技术的魅力所在。
|
16天前
|
运维 Cloud Native 持续交付
云原生技术深度探索:重塑现代IT架构的无形之力####
本文深入剖析了云原生技术的核心概念、关键技术组件及其对现代IT架构变革的深远影响。通过实例解析,揭示云原生如何促进企业实现敏捷开发、弹性伸缩与成本优化,为数字化转型提供强有力的技术支撑。不同于传统综述,本摘要直接聚焦于云原生技术的价值本质,旨在为读者构建一个宏观且具体的技术蓝图。 ####
|
17天前
|
Cloud Native 持续交付 云计算
云原生技术的崛起与未来展望
本文探讨了云原生技术的核心概念、发展历程及其在现代IT架构中的关键作用。随着云计算的普及,云原生作为一种优化云应用构建和部署的方法,正逐渐成为企业数字化转型的重要推力。文章分析了容器化、微服务、持续集成/持续部署(CI/CD)等关键技术如何支撑起灵活、高效、可扩展的云原生架构,并讨论了面临的挑战与未来的发展趋势。
30 2
|
17天前
|
Kubernetes Cloud Native 持续交付
云端之旅:云原生技术引领未来
在数字时代的浪潮中,云原生技术如同一艘承载梦想的航船,带领企业驶向数字化转型的彼岸。本文将揭示云原生技术的核心价值,探讨其在现代IT架构中的应用,并分享实现云原生转型的实践案例。从容器化和微服务到持续集成与持续部署(CI/CD),我们将一同见证云原生技术如何塑造灵活、高效、自动化的未来。
|
19天前
|
运维 Cloud Native 持续交付
深入理解云原生架构及其在现代企业中的应用
随着数字化转型的浪潮席卷全球,企业正面临着前所未有的挑战与机遇。云计算技术的迅猛发展,特别是云原生架构的兴起,正在重塑企业的IT基础设施和软件开发模式。本文将深入探讨云原生的核心概念、关键技术以及如何在企业中实施云原生策略,以实现更高效的资源利用和更快的市场响应速度。通过分析云原生架构的优势和面临的挑战,我们将揭示它如何助力企业在激烈的市场竞争中保持领先地位。
|
26天前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
40 3
|
28天前
|
Cloud Native 持续交付 云计算
云原生架构的演进与挑战
随着云计算技术的不断发展,云原生架构已成为企业数字化转型的重要支撑。本文深入探讨了云原生架构的概念、发展历程、核心技术以及面临的挑战,旨在为读者提供一个全面了解云原生架构的视角。通过分析Kubernetes、Docker等关键技术的应用,以及微服务、持续集成/持续部署(CI/CD)等实践案例,本文揭示了云原生架构在提高应用开发效率、降低运维成本、增强系统可扩展性等方面的显著优势。同时,也指出了云原生架构在安全性、复杂性管理等方面所面临的挑战,并提出了相应的解决策略。