K8s概念汇总-笔记

目录

1.Master

1.1在Master上运⾏着以下关键进程

2.什么是Node?

1.2在每个Node上都运⾏着以下关键进程

3.什么是 Pod ?

4. 什么是Label ?

5.Replication Controller

6.Deployment

6.1Deployment的典型场景: 

7.Horizontal Pod Autoscaler TODO

HPA与之前的RC、Deployment⼀样,也属于⼀种Kubernetes资源对象。通过追踪分析指定RC控制的所有⽬标Pod的负载变化情况,来确定是否需要有针对性地调整⽬标Pod的副本数量,这是HPA的实现原理。 当前,HPA有以下两种⽅式作为Pod负载的度量指标。

CPUUtilizationPercentage

8.StatefulSet

StatefulSet特性

9.Service

9.1 外部系统访问Service的问题

10.Job 

11.Volume存储卷

12. Persistent Volume

13.Namespace

14.Annotation

15.ConfigMap

k8s设计:


1.Master

Kubernetes⾥的Master指的是集群控制节点,在每个Kubernetes集群⾥都需要有⼀个Master来负责整个集群的管理和控制,基本上 Kubernetes的所有控制命令都发给它,它负责具体的执⾏过程,我们后 ⾯执⾏的所有命令基本都是在Master上运⾏的。Master通常会占据⼀个独⽴的服务器(⾼可⽤部署建议⽤3台服务器),整个集群的“⾸脑”,如果它宕机或者不可⽤,那么对集群内容器应⽤的管理都将失效。

1.1在Master上运⾏着以下关键进程

Kubernetes API Server(kube-apiserver):提供了HTTP Rest接⼝的关键服务进程,是Kubernetes⾥所有
资源的增、删、改、查等操作的唯⼀⼊⼝,也是集群控制的⼊⼝进程。
Kubernetes Controller Manager(kube-controller-manager): Kubernetes⾥所有资源对象的⾃动化控
制中⼼,可以将其理解为资源对象的“⼤总管”。
Kubernetes Scheduler(kube-scheduler):负责资源调度(Pod调度)的进程,相当于公交公司的“调度
室”。
另外,在Master上通常还需要部署etcd服务,因为Kubernetes⾥的所有资源对象的数据都被保存在etcd中。

2.什么是Node?

与Master⼀样,Node可以是⼀台物理主机,也可以是⼀台虚拟机。Node是Kubernetes集群中的⼯作负载节
点,每个 Node都会被Master分配⼀些⼯作负载(Docker容器),当某个Node宕机时,其上的⼯作负载会被
Master⾃动转移到其他节点上。


1.2在每个Node上都运⾏着以下关键进程

Kubelet: 负责Pod对应的容器创建,启停等任务,同时与Master密切协作,实现集群管理的基本功能。

kube-proxy: 实现Kubernetes Service的通信与负载均衡机制的重要组件。

Docker Engine (Docker):  Docker引擎,负责本机的容器创建和管理⼯作。

kubectl get nodes

3.什么是 Pod ?

Pod是Kubernetes最重要的基本概念

每个Pod都有⼀个特殊的被称为“根容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的⼀部分,除了Pause容器, 每个Pod还包含⼀个或多个紧密相关的⽤户业务容器。

4. 什么是Label ?

⼀个Label是⼀个key=value的键值对,其中key与
value由⽤户⾃⼰指定。Label可以被附加到各种资源对象上,例如Node、Pod、Service、RC等,⼀个资源对象可以定义任意数量的Label,同⼀个Label也可以被添加到任意数量的资源对象上。Label通常在资源对象定义时确定,也可以在对象创建后动态添加或者删除。
我们可以通过给指定的资源对象捆绑⼀个或多个不同的Label来实现多维度的资源分组管理功能,以便灵活、⽅便地进⾏资源分配、调度、配置、部署等管理⼯作。例如,部署不同版本的应⽤到不同的环境中;监控和分析应⽤(⽇志记录、监控、告警)等。⼀些常⽤的Label示例如下。
版本标签:"release":"stable"、"release":"canary"。
环境标签:"environment":"dev"、"environment":"qa"、"environment":"production"。
架构标签:"tier":"frontend"、"tier":"backend"、"tier":"middleware"。
分区标签:"partition":"customerA"、"partition":"customerB"。
质量管控标签:"track":"daily"、"track":"weekly"。
可以通过多个Label Selector表达式的组合实现复杂的条件选择,多个表达式之间⽤“,”进⾏分隔即可,⼏个条件
之间是“AND”的关系,即同时满⾜多个条件,⽐如下⾯的例⼦:

name=redis-slave,env!=production
name notin (php-frontend),env!=production

以myweb Pod为例,Label被定义在其metadata中:

apiVersion: v1
kind: Pod
metadata:name: weblabels:app: web

管理对象RC和Service则通过Selector字段设置需要关联Pod的 Label:

apiVersion: v1
kind: ReplicationController
metadata:name: myweb
spec:replicas: 1selector:app: mywebtemplate:
......
apiVersion: v1
kind: Service
metadata:name: myweb
spec:selector:app: myweb
ports:
- port: 8080

其他管理对象如Deployment、ReplicaSet、DaemonSet和Job则可以在Selector中使⽤基于集合的筛选条件定义

例如:

selector:
matchLables:app: web
matchExpressions:
- {key: tier, operator: In, values: [frontend]}
- {key: environmetn, operator: NotIn, value: [dev]}

matchLabels⽤于定义⼀组Label,与直接写在Selector中的作⽤相同;matchExpressions⽤于定义⼀组基于集合的筛选条件,可⽤的条件 运算符包括In、NotIn、Exists和DoesNotExist。
如果同时设置了matchLabels和matchExpressions,则两组条件为AND关系,即需要同时满⾜所有条件才能完成Selector的筛选。
Label Selector在Kubernetes中的重要使⽤场景如下

kube-controller进程通过在资源对象RC上定义的Label Selector来筛选要监控的Pod副本数量,使Pod副本数
量始终符合预期设定的全⾃动控制流程。
kube-proxy进程通过Service的Label Selector来选择对应的Pod, ⾃动建⽴每个Service到对应Pod的请求转
发路由表,从⽽实现Service的智能负载均衡机制。
通过对某些Node定义特定的Label,并且在Pod定义⽂件中使⽤NodeSelector这种标签调度策略,kube-scheduler进程可以实现Pod定向调度的特性。

5.Replication Controller

RC是Kubernetes系统中的核⼼概念之⼀,简单来说,它其实定义了⼀个期望的场景,即声明某种Pod的副本数量在任意时刻都符合某个预期值,所以RC的定义包括如下⼏个部分。
Pod期待的副本数量
⽤于筛选⽬标Pod的Label Selector
当Pod的副本数量⼩于预期数量时,⽤于创建新Pod的Pod模板(template)

下⾯是⼀个完整的RC定义的例⼦,即确保拥有tier=frontend标签的这个Pod(运⾏Tomcat容器)在整个
Kubernetes集群中始终只有⼀个副本:

apiVersion: v1
kind: ReplicationController
metadata:name: frontend
spec:replicas: 1selector:tier: frontendtemplate:metadata:labels:app: app-demotier: frontendspec:containers:- name: tomcat-demoimage: tomcatimagePullPolicy: IfNotPresentenv:- name: GET_HOSTS_FROMvalue: dnsports:- containerPort: 80

6.Deployment

Deployment相对于RC的⼀个最⼤升级是我们可以随时知道当前Pod“部署”的进度。实际上由于⼀个Pod的创建、调度、绑定节点及在⽬标Node上启动对应的容器这⼀完整过程需要⼀定的时间,所以我们期待系统启动N个Pod副本的⽬标状态,实际上是⼀个连续变化的“部署过程”导致的最终状态。

6.1Deployment的典型场景: 

创建一个Deployment对象来生成对应的Repplicat Set 并完成Pod副本的创建

检查Deployment 的状态来看部署是否完成(Pod 副本数量是否达到预期的值)

更新Deployment以创建新的Pod(⽐如镜像升级)
如果当前Deployment不稳定,则回滚到⼀个早先的Deployment版本
暂停Deployment以便于⼀次性修改多个PodTemplateSpec的配置项,之后再恢复Deployment,进⾏新的发布扩展Deployment以应对⾼负载
查看Deployment的状态,以此作为发布是否成功的指标
清理不再需要的旧版本ReplicaSets

创建⼀个名为tomcat-deployment.yaml的Deployment
描述⽂件,内容如下:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:name: frontend
spec:replicas: 1selector:matchLabels:tier: frontendmatchExpressions:- {key: tier, operator: In, values: [frontend]}
template:metadata:labels:app: app-demotier: frontendspec:containers:- name: tomcat-demoimage: tomcatimagePullPolicy: IfNotPresentports:- containerPort: 8080

对上述输出中涉及的数量解释如下

$ kubectl get deployments

DESIRED:Pod副本数量的期望值,即在Deployment⾥定义的Replica
CURRENT:当前Replica的值,实际上是Deployment创建的Replica Set⾥的Replica值,这个值不断增加,直
到达到DESIRED为⽌,表明整个部署过程完成
UP-TO-DATE:最新版本的Pod的副本数量,⽤于指示在滚动升级的过程中,有多少个Pod副本已经成功升级
AVAILABLE:当前集群中可⽤的Pod副本数量,即集群中当前存活的Pod数量
运⾏下述命令查看对应的Replica Set,我们看到它的命名与Deployment的名称有关系

kubectl get rs

7.Horizontal Pod Autoscaler TODO

Horizontal Pod Autoscaling(Pod横向⾃动扩容,HPA)

HPA与之前的RC、Deployment⼀样,也属于⼀种Kubernetes资源对象。通过追踪分析指定RC控制的所有⽬标
Pod的负载变化情况,来确定是否需要有针对性地调整⽬标Pod的副本数量,这是HPA的实现原理。 当前,HPA有
以下两种⽅式作为Pod负载的度量指标。

CPUUtilizationPercentage


应⽤程序⾃定义的度量指标,⽐如服务在每秒内的相应请求数(TPS或QPS)

CPUUtilizationPercentage是⼀个算术平均值,即⽬标Pod所有副本⾃身的CPU利⽤率的平均值。⼀个Pod⾃
身的CPU利⽤率是该Pod当前CPU的使⽤量除以它的Pod Request的值,⽐如定义⼀个Pod的Pod Request为0.4,
⽽当前Pod的CPU使⽤量为0.2,则它的CPU使⽤率为50%,这样就可以算出⼀个RC控制的所有Pod副本的CPU利⽤
率的算术平均值了。如果某⼀时刻CPUUtilizationPercentage的值超过80%,则意味着当前Pod副本数量很可能不
⾜以⽀撑接下来更多的请求,需要进⾏动态扩容,⽽在请求⾼峰时段过去后,Pod的CPU利⽤率⼜会降下来,此时
对应的Pod副本数应该⾃动减少到⼀个合理的⽔平。如果⽬标Pod没有定义Pod Request的值,则⽆法使⽤
CPUUtilizationPercentage实现Pod横向⾃动扩容。除了使⽤CPUUtilizationPercentage,Kubernetes从1.2版本
开始也在 尝试⽀持应⽤程序⾃定义的度量指标

下⾯是HPA定义的⼀个具体例⼦:

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:name: php-apachenamespace: default
spec:maxReplicas: 10minReplicas: 1scaleTargetRef:kind: Deploymentname: php-apachetargetCPUUtilizationPercentage: 90

根据上⾯的定义,我们可以知道这个HPA控制的⽬标对象为⼀个名为php-apache的Deployment⾥的Pod副
本,当这些Pod副本的 CPUUtilizationPercentage的值超过90%时会触发⾃动动态扩容⾏为,在扩容或缩容时必须
满⾜的⼀个约束条件是Pod的副本数为1~10
除了可以通过直接定义YAML⽂件并且调⽤kubectrl create的命令来创建⼀个HPA资源对象的⽅式,还可以通
过下⾯的简单命令⾏直接创建等价的HPA对象:

$ kubectl autoscale deployment php-apache --cpu-percent=90 --min=1 --max=10

8.StatefulSet

在Kubernetes系统中,Pod的管理对象RC、Deployment、DaemonSet和Job都⾯向⽆状态的服务。但现实中
有很多服务是有状态的,特别是⼀些复杂的中间件集群,例如MySQL集群、MongoDB集群、kafka集群、
ZooKeeper集群等,这些应⽤集群有4个共同点
每个节点都有固定的身份ID,通过这个ID,集群中的成员可以相互发现并通信
集群的规模是⽐较固定的,集群规模不能随意变动
集群中的每个节点都是有状态的,通常会持久化数据到永久存储中
如果磁盘损坏,则集群⾥的某个节点⽆法正常运⾏,集群功能受损

StatefulSet特性


StatefulSet⾥的每个Pod都有稳定、唯⼀的⽹络标识,可以⽤来发现集群内的其他成员。假设StatefulSet的名
称为kafka,那么第1个Pod叫kafka-0,第2个叫kafka-1,以此类推
StatefulSet控制的Pod副本的启停顺序是受控的,操作第n个Pod时,前n-1个Pod已经是运⾏且准备好的状态
StatefulSet⾥的Pod采⽤稳定的持久化存储卷,通过PV或PVC来实现,删除Pod时默认不会删除与StatefulSet
相关的存储卷(为了保证数据的安全)

StatefulSet除了要与PV卷捆绑使⽤以存储Pod的状态数据,还要与Headless Service配合使⽤,即在每个StatefulSet定义中都要声明它属于 哪个Headless Service。Headless Service与普通Service的关键区别在于, 它没有Cluster IP,如果解析Headless Service的DNS域名,则返回的是该 Service对应的全部Pod的Endpoint列表。
StatefulSet在Headless Service的 基础上⼜为StatefulSet控制的每个Pod实例都创建了⼀个DNS域名,这个 域名的
格式为:

$(podname).$(headless service name)

⽐如⼀个3节点的Kafka的StatefulSet集群对应的Headless Service的名称为kafka,StatefulSet的名称为kafka,则
StatefulSet⾥的3个Pod的DNS 名称分别为kafka-0.kafka、kafka-1.kafka、kafka-3.kafka,这些DNS名称可以直接
在集群的配置⽂件中固定下来

9.Service

Service服务也是Kubernetes⾥的核⼼资源对象之⼀,Kubernetes⾥的每个Service其实就是我们经常提起的微服务架构中的⼀个微服务,之前讲解Pod、RC等资源对象其实都是为讲解Kubernetes Service做铺垫的

Service 定义了一个服务的访问入口地址,前端的应用(Pod)通过这个入口访问其背后的一组由Pod 副本组成的集群实例,Service 与其后端Pod 副本集群之间则是通过label  Selector 来实现无缝对接的。RC 的作用实际上是保证Service 的服务能力和服务质量始终符合预期标准。

9.1 外部系统访问Service的问题

Kubernetes⾥ 的3种IP

Node IP:Node的IP地址
Pod IP:Pod的IP地址
Cluster IP:Service的IP地址

Node IP是Kubernetes集群中每个节点的物理⽹卡的IP地址, 是⼀个真实存在的物理⽹络,所有属于这个⽹络的服务器都能通过这个⽹络直接通信,不管其中是否有部分节点不属于这个Kubernetes集群。 这也表明在Kubernetes集群之外的节点访问Kubernetes集群之内的某个节点或者TCP/IP服务时,都必须通过Node IP通信。

Pod IP是每个Pod的IP地址,它是Docker Engine根据docker0 ⽹桥的IP地址段进⾏分配的,通常是⼀个虚拟的⼆层⽹络,前⾯说过, Kubernetes要求位于不同Node上的Pod都能够彼此直接通信,所以 Kubernetes⾥⼀个Pod⾥的容器访问另外⼀个Pod⾥的容器时,就是通过 Pod IP所在的虚拟⼆层⽹络进⾏通信的,⽽真实的TCP/IP流量是通过 Node IP所在的物理⽹卡流出的。

Service的Cluster IP,它也是⼀种虚拟的IP,但更像⼀个“伪造”的IP⽹络,原因有以下⼏点
Cluster IP仅仅作⽤于Kubernetes Service这个对象,并由 Kubernetes管理和分配IP地址(来源于Cluster IP地址池)Cluster IP⽆法被Ping,因为没有⼀个“实体⽹络对象”来响应
Cluster IP只能结合Service Port组成⼀个具体的通信端⼝,单独 的Cluster IP不具备TCP/IP通信的基础,并且它们属于Kubernetes集群这 样⼀个封闭的空间,集群外的节点如果要访问这个通信端⼝,则需要做 ⼀些额外的⼯作在Kubernetes集群内,Node IP⽹、Pod IP⽹与Cluster IP⽹之间的通信,采⽤的是Kubernetes⾃⼰设计的⼀种编程⽅式的特殊路由规 则,与我们熟知的IP路由有很⼤的不同。

根据上⾯的分析和总结,我们基本明⽩了:Service的Cluster IP属于 Kubernetes集群内部的地址,⽆法在集
群外部直接使⽤这个地址。那么 ⽭盾来了:实际上在我们开发的业务系统中肯定多少有⼀部分服务是要提供给
Kubernetes集群外部的应⽤或者⽤户来使⽤的,典型的例⼦就是 Web端的服务模块,⽐如上⾯的tomcat-service,那么⽤户怎么访问它?采⽤NodePort是解决上述问题的最直接、有效的常⻅做法。以 tomcat-service为例,在Service的定义⾥做如
下扩展即可(⻅代码中的粗 体部分):

其中,nodePort:31002这个属性表明⼿动指定tomcat-service的NodePort为31002,否则Kubernetes会⾃动分配⼀个可⽤的端⼝。接下来 在浏览器⾥访问http://:31002/,就可以看到Tomcat的欢迎界⾯了NodePort的实现⽅式是在Kubernetes集群⾥的每个Node上都为需要外部访问的Service开启⼀个对应的TCP监听端⼝,外部系统只要⽤任意⼀个Node的IP地址+具体的NodePort端⼝号即可访问此服务,在任意Node上运⾏netstat命令,就可以看到有NodePort端⼝被监听:

但NodePort还没有完全解决外部访问Service的所有问题,⽐如负载均衡问题。假如在我们的集群中有10个Node,则此时最好有⼀个负载均衡器,外部的请求只需访问此负载均衡器的IP地址,由负载均衡器负责转发流量到后⾯某个Node的NodePort上,如图1.15所示

图1.15中的Load balancer组件独⽴于Kubernetes集群之外,通常是⼀个硬件的负载均衡器,或者是以软件⽅式实现的,例如HAProxy或者 Nginx。对于每个Service,我们通常需要配置⼀个对应的Load balancer实例来转发流量到后端的Node上,这的确增加了⼯作量及出错的概率。于是Kubernetes提供了⾃动化的解决⽅案,如果我们的集群运⾏在⾕歌的公有云GCE上,那么只要把Service的type=NodePort改为 type=LoadBalancer,Kubernetes会⾃动创建⼀个对应的Load balancer实例并返回它的IP地址供外部客户端使⽤。其他公有云提供商只要实现了⽀持此特性的驱动,则也可以达到上述⽬的。此外,裸机上的类似机制 (Bare Metal Service Load Balancers)也在被开发.

10.Job 

批处理任务Job,与RC,Deployment 、ReplicaSet、DaemonSet 类似,Job 也控制一组Pod容器。从这个角度来看,Job 也是特殊的Pod 副本自动控制,同时Job 控制Pod副本与RC 等控制器的工作机制有一下区别: 

(1)Job所控制的Pod副本是短暂运⾏的,可以将其视为⼀组 Docker容器,其中的每个Docker容器都仅仅运
⾏⼀次。当Job控制的所有Pod副本都运⾏结束时,对应的Job也就结束了。Job在实现⽅式上与 RC等副本控制器不
同,Job⽣成的Pod副本是不能⾃动重启的,对应Pod 副本的RestartPoliy都被设置为Never。因此,当对应的Pod副本都执⾏完 成时,相应的Job也就完成了控制使命,即Job⽣成的Pod在Kubernetes中 是短暂存在的。Kubernetes在1.5版本之后⼜提供了类似crontab的定时任 务——CronJob,解决了某些批处理任务需要定时反复执⾏的问题。

(2)Job所控制的Pod副本的⼯作模式能够多实例并⾏计算,以TensorFlow框架为例,可以将⼀个机器学习的计算任务分布到10台机器上,在每台机器上都运⾏⼀个worker执⾏计算任务,这很适合通过Job⽣成10个Pod副本同时启动运算。

11.Volume存储卷

Volume(存储卷)是Pod中能够被多个容器访问的共享⽬录。 Kubernetes的Volume概念、⽤途和⽬的与Docker的Volume⽐较类似,但 两者不能等价。⾸先,Kubernetes中的Volume被定义在Pod上,然后被 ⼀个Pod⾥的多个容器挂载到具体的⽂件⽬录下;其次,Kubernetes中的 Volume与Pod的⽣命周期相同,但与容器的⽣命周期不相关,当容器终 ⽌或者重启时,Volume中的数据也不会丢失。最后,Kubernetes⽀持多种类型的Volume,例如GlusterFS、Ceph等先进的分布式⽂件系统。

在Pod上声明 ⼀个Volume,然后在容器⾥引⽤该Volume并挂载(Mount)到容器⾥的 某个⽬录上。举例来说,我们要给之前的Tomcat Pod增加⼀个名为 datavol的Volume,并且挂载到容器的/mydata-data⽬录上,则只要对Pod 的定义⽂件做如下修正即可(注意代码中的粗体部分):

12. Persistent Volume

之前提到的Volume是被定义在Pod上的,属于计算资源的⼀部分, ⽽实际上,⽹络存储是相对独⽴于计算资源⽽存在的⼀种实体资源。⽐ 如在使⽤虚拟机的情况下,我们通常会先定义⼀个⽹络存储,然后从中 划出⼀个“⽹盘”并挂接到虚拟机上。Persistent Volume(PV)和与之相 关联的Persistent Volume Claim(PVC)也起到了类似的作⽤。

PV可以被理解成Kubernetes集群中的某个⽹络存储对应的⼀块存储,它与Volume类似,但有以下区别。
PV只能是⽹络存储,不属于任何Node,但可以在每个Node上访问。
PV并不是被定义在Pod上的,⽽是独⽴于Pod之外定义的。

PV⽬前⽀持的类型包括:gcePersistentDisk、 AWSElasticBlockStore、AzureFile、AzureDisk、FC(FibreChannel)、
Flocker、NFS、iSCSI、RBD(Rados Block Device)、CephFS、 Cinder、GlusterFS、VsphereVolume、Quobyte Volumes、VMware Photon、Portworx Volumes、ScaleIO Volumes和HostPath(仅供单机测试)

下⾯给出了NFS类型的PV的⼀个YAML定义⽂件,声明了需要5Gi 的存储空间:

 ⽐较重要的是PV的accessModes属性,⽬前有以下类型。
ReadWriteOnce:读写权限,并且只能被单个Node挂载。
ReadOnlyMany:只读权限,允许被多个Node挂载。
ReadWriteMany:读写权限,允许被多个Node挂载。

如果某个Pod想申请某种类型的PV,则⾸先需要定义⼀个 PersistentVolumeClaim对象

然后,在Pod的Volume定义中引⽤上述PVC即可:

最后说说PV的状态。PV是有状态的对象,它的状态有以下⼏种。
Available:空闲状态。
Bound:已经绑定到某个PVC上。
Released:对应的PVC已经被删除,但资源还没有被集群收 回。
Failed:PV⾃动回收失败。

13.Namespace

Namespace(命名空间)是Kubernetes系统中的⾮常重要的概念,Namespace在很多情况下⽤于实现多租户的资源隔离。Namespace 通过将集群内部的资源对象“分配”到不同的Namespace中,形成逻辑上分组的不同项⽬、⼩组或⽤户组,便于不同的分组在共享使⽤整个集群的资源的同时还能被分别管理。

Kubernetes集群在启动后会创建⼀个名为default的Namespace,通过kubectl可以查看:

14.Annotation

Annotation(注解)与Label类似,也使⽤key/value键值对的形式进⾏定义。不同的是Label具有严格的命名规则,它定义的是Kubernetes对象的元数据(Metadata),并且⽤于Label Selector。Annotation则是⽤户 任意定义的附加信息,以便于外部⼯具查找。在很多时候,Kubernetes的模块⾃身会通过Annotation标记资源对象的⼀些特殊信息通常来说,⽤Annotation来记录的信息如下
build信息、release信息、Docker镜像信息等,例如时间戳、 release id号、PR号、镜像Hash值、DockerRegistry地址等⽇志库、监控库、分析库等资源库的地址信息程序调试⼯具信息,例如⼯具名称、版本号等团队的联系信息,例如电话号码、负责⼈名称、⽹址等。

15.ConfigMap

为了能够准确和深刻理解Kubernetes ConfigMap的功能和价值,我们需要从Docker说起。我们知道,
Docker通过将程序、依赖库、数据及配置⽂件“打包固化”到⼀个不变的镜像⽂件中的做法,解决了应⽤的部署的难
题,但这同时带来了棘⼿的问题,即配置⽂件中的参数在运⾏期如何修改的问题。我们不可能在启动Docker容器后
再修改容器⾥的配置⽂件,然后⽤新的配置⽂件重启容器⾥的⽤户主进程。为了解决这个问题,Docker提供了两种⽅式:
在运⾏时通过容器的环境变量来传递参数
通过Docker Volume将容器外的配置⽂件映射到容器内

这两种⽅式都有其优势和缺点,在⼤多数情况下,后⼀种⽅式更合适我们的系统,因为⼤多数应⽤通常从⼀个或多个配置⽂件中读取参数。但这种⽅式也有明显的缺陷:我们必须在⽬标主机上先创建好对应的配置⽂件,然后才能映射到容器⾥。

k8s设计:


⾸先,把所有的配置项都当作key-value字符串,当然value可以来⾃ 某个⽂本⽂件,⽐如配置项
password=123456、user=root、 host=192.168.8.4⽤于表示连接FTP服务器的配置参数。这些配置项可以 作为Map表中的⼀个项,整个Map的数据可以被持久化存储在 Kubernetes的Etcd数据库中,然后提供API以⽅便Kubernetes相关组件或客户应⽤CRUD操作这些数据,上述专⻔⽤来保存配置参数的Map就是Kubernetes  ConfigMap资源对象

Kubernetes提供了⼀种内建机制,将存储在etcd中的ConfigMap通过Volume映射的⽅式变成⽬标
Pod内的配置⽂件,不管⽬ 标Pod被调度到哪台服务器上,都会完成⾃动映射。进⼀步地,如果ConfigMap中的
key-value数据被修改,则映射到Pod中的“配置⽂件”也会随之⾃动更新。于是,Kubernetes ConfigMap就成了分
布式系统中最为简单(使⽤⽅法简单,但背后实现⽐较复杂)且对应⽤⽆侵⼊的配置中⼼

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/120711.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

【MATLAB源码-第57期】基于matlab的IS95前向链路仿真,输出误码率曲线。

操作环境: MATLAB 2022a 1、算法描述 IS-95,也被称为cdmaOne,是第一代的CDMA(Code Division Multiple Access,码分多址)数字蜂窝通信标准。IS-95的全称是Interim Standard-95,最初由Qualcomm…

春运压力如何破?V2X技术来解题

近日,国务院发布了2024春节放假方案。春节作为每年中国交通运输系统最繁忙的时期,车流的快速增长带来了道路运载压力和事故风险率。如果想拥有一个不堵车又平安的春节?那就不得不提V2X 技术,以及它在提升交通安全与交通效率、助力…

TVRNet网络PyTorch实现

文章目录 文章地址网络各层结构代码实现 文章地址 An End-to-End Traffic Visibility Regression Algorithm文章通过训练搜集得到的真实道路图像数据集(Actual Road dense image Dataset, ARD),通过专业的能见度计和多人标注,获得…

图像语义分割 pytorch复现DeepLab v1图像分割网络以及网络详解(骨干网络基于VGG16)

图像语义分割 pytorch复现DeepLab v1图像分割网络以及网络详解(骨干网络基于VGG16) 背景介绍2、 网络结构详解2.1 LarFOV效果分析 2.2 DeepLab v1-LargeFOV 模型架构2.3 MSc(Multi-Scale,多尺度(预测))2.3 以VGG16为特…

1-多媒体通信概述

文章目录 媒体和多媒体媒体多媒体VarityIntergrationInteraction 多媒体通信(MMC)业务类型 MMC主要问题和关键技术主要问题关键技术 MMC发展动向重要事件趋势 标准化组织 媒体和多媒体 媒体 承载信息的载体. 感知媒体, 表示媒体, 显示媒体, 存储媒体, 传输媒体. 多媒体 Var…

电脑定时关机

电脑定时关机 1.右键 管理 2. 3. 4. 5. shutdown.exe/s /f /t 06.点击完成就好了 7.这里面可以 看到定时任务和启动 右键有运行 结束 禁用

世微 宽电压降压 DC-DC 电源管理芯片 以太网平衡车工业控制电源驱动12V6A AP8854

1,产品描述 AP8854 一款宽电压范围降压型 DC-D 电源管理芯片,内部集成使能开关控制、基 准电源、误差放大器、过热保护、限流保 护、短路保护等功能,非常适合宽电压输 入降压使用。 AP8854 带使能控制,可以大大节省外 围器件&…

广州华锐互动:VR虚拟现实物理学习平台,开启数字化教学新格局

随着虚拟现实(VR)技术的不断发展,越来越多的领域开始应用这一技术。广州华锐互动开发的VR虚拟现实物理学习平台就得到了广泛应用,平台涉及力学、光学、热学等初中物理知识,还包含了物理名人、实验器具、物理现象的还原和学习,相比…

CSS色域、色彩空间、CSS Color 4新标准 | 京东云技术团队

引言 近期,三大主流浏览器引擎均发布最新版本,支持W3C的CSS Color 4标准,包含新的取色方法color()和相应语法,可展示更多的色域及色彩空间,这意味着web端能展示更丰富更高清的色彩。虽然目前只有最新版本的现代浏览器…

java时间解析生成定时Cron表达式工具类

Cron表达式工具类CronUtil 构建Cron表达式 /****方法摘要:构建Cron表达式*param taskScheduleModel*return String*/public static String createCronExpression(TaskScheduleModel taskScheduleModel){StringBuffer cronExp new StringBuffer("");if(…

k8s-----26、细粒度权限管理 RBAC

0、导读 每一个用户对API资源进行操作都需要通经过以下三个步骤: 第一步:对客户端访问进行认证操作,确认是否具有访问k8s权限(也就是通过serviceaccount) token(共享秘钥) SSL(双向SSL认证) …通过任何一个认证即表示认证通过,进入下一步第二步:授权检查,确认是否对资源…

JAVAEE初阶相关内容第十六弹--网络编程

写在前 这一节的内容首先是对十五弹(UDP回显服务器)进行简单的改进,在这基础上开始介绍TCP流套接字编程。 目录 写在前 1.改进回显服务器 1.1完整代码实现 1.2运行输出结果 2.TCP流套接字编程 2.1ServerSocketAPI 2.2SocketAPI 3.TC…

echarts的柱状图的重叠和堆叠实现两个柱体的显示和之前的差值显示

效果图 主要思路 准备三个柱体(原计划,实际进度,差值) 原计划和实际进度设置成重叠 {barWidth: 20,// yAxisIndex: 1,z: 1,name: 原计划,type: bar,stack: ab,emphasis: { // 点击柱体其他柱体颜色会变浅disabled: true},label…

代码随想录打卡第五十天|198.打家劫舍 ● 213.打家劫舍II ● 337.打家劫舍III

198.打家劫舍 题目: 你是一个专业的小偷,计划偷窃沿街的房屋。每间房内都藏有一定的现金,影响你偷窃的唯一制约因素就是相邻的房屋装有相互连通的防盗系统,如果两间相邻的房屋在同一晚上被小偷闯入,系统会自动报警。 …

AWTK实现汽车仪表Cluster/DashBoard嵌入式GUI开发(六):一个AWTK工程

一个AWTK工程基于C/C++编写,可以分为如下几步: 结合下图,看懂启动的部分。一般一个AWTK工程,需要实现哪些部分,就是其中开始之后白色的部分,比如调用main函数和gui_app_start时会做一些操作,比如asset_init和application_init时要做一些设置,还有退出的函数application…

【ARM AMBA Q_Channel 详细介绍】

文章目录 1.1 Q_Channel 概述1.2 Q-Channel1.2.1 Q-Channel 接口1.2.2 Q-Channel 接口的握手状态1.2.3 握手信号规则 1.3 P_Channel的握手协议1.3.1 device 接受 PMU 的 power 请求1.3.2 device 拒绝 PMU 的 power 请求 1.4 device 复位信号与 Q _Channel 的结合1.4.1 RESETn 复…

Xcode iOS app启用文件共享

在info.plist中添加如下两个配置 Supports opening documents in place Application supports iTunes file sharing 结果都为YES,如下图所示: 然后,iOS设备查看,文件->我的iPhone列表中有一个和你工程名相同的文件夹出现&…

工作小计-GPU硬编以及依赖库 nvcuvidnvidia-encode

工作小计-GPU编码以及依赖库 已经是第三篇关于编解码的记录了。项目中用到GPU编码很久了,因为yuv太大,所以编码显得很重要。这次遇到的问题是环境的搭建问题。需要把开发机上的环境放到docker中,以保证docker中同样可以进行GPU的编码。 1 定…

三代自动驾驶系统及主流科技公司自动驾驶技术方案简介

截止目前,按技术特点,自动驾驶技术大致经历了三代发展:第一代自动驾驶技术以后融合感知技术,高精度地图,基于惯导、GPS定位系统,预测模块,基于优化、搜索的规控等组成。第一代比较成熟的自动驾驶…

是顺流还是逆流?未来物流作业是否将被机器人全面取代?

原创 | 文 BFT机器人 随着人工智能的加速发展,各行业为适应数字时代的潮流,纷纷引入智能制造,帮助企业实现产业升级。而物流行业也不例外,现今人们的生活速度加快,为了快捷便利,很多的人喜欢通过网购、快递…