河南做网站多少钱做视频网站容易收录吗

当前位置： 首页 > news >正文

河南做网站多少钱,做视频网站容易收录吗,建设玩外汇平台网站,无锡手机网站制作目录 1.Master 1.1在Master上运⾏着以下关键进程 2.什么是Node? 1.2在每个Node上都运⾏着以下关键进程 3.什么是 Pod ?

1. 什么是Label #xff1f; 5.Replication Controller 6.Deployment 6.1Deployment的典型场景#xff1a;
   7.Horizontal Pod Autoscaler TODO…目录 1.Master 1.1在Master上运⾏着以下关键进程 2.什么是Node? 1.2在每个Node上都运⾏着以下关键进程 3.什么是 Pod ?
2. 什么是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存储卷
3. Persistent Volume 13.Namespace 14.Annotation 15.ConfigMap k8s设计 1.Master Kubernetes⾥的Master指的是集群控制节点在每个Kubernetes集群⾥都需要有⼀个Master来负责整个集群的管理和控制基本上 Kubernetes的所有控制命令都发给它它负责具体的执⾏过程我们后 ⾯执⾏的所有命令基本都是在Master上运⾏的。Master通常会占据⼀个独⽴的服务器⾼可⽤部署建议⽤3台服务器),整个集群的“⾸脑”如果它宕机或者不可⽤那么对集群内容器应⽤的管理都将失效。 1.1在Master上运⾏着以下关键进程 Kubernetes API Serverkube-apiserver提供了HTTP Rest接⼝的关键服务进程是Kubernetes⾥所有 资源的增、删、改、查等操作的唯⼀⼊⼝也是集群控制的⼊⼝进程。Kubernetes Controller Managerkube-controller-manager Kubernetes⾥所有资源对象的⾃动化控 制中⼼可以将其理解为资源对象的“⼤总管”。Kubernetes Schedulerkube-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是⼀个keyvalue的键值对其中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”的关系即同时满⾜多个条件⽐如下⾯的例⼦ nameredis-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定义的例⼦即确保拥有tierfrontend标签的这个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 DESIREDPod副本数量的期望值即在Deployment⾥定义的ReplicaCURRENT当前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 AutoscalingPod横向⾃动扩容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横向⾃动扩容。除了使⽤CPUUtilizationPercentageKubernetes从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的副本数为110 除了可以通过直接定义YAML⽂件并且调⽤kubectrl create的命令来创建⼀个HPA资源对象的⽅式还可以通 过下⾯的简单命令⾏直接创建等价的HPA对象 \) kubectl autoscale deployment php-apache –cpu-percent90 –min1 –max10 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的名称为kafkaStatefulSet的名称为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 IPNode的IP地址 Pod IPPod的IP地址 Cluster IPService的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的typeNodePort改为 typeLoadBalancerKubernetes会⾃动创建⼀个对应的Load balancer实例并返回它的IP地址供外部客户端使⽤。其他公有云提供商只要实现了⽀持此特性的驱动则也可以达到上述⽬的。此外裸机上的类似机制 Bare Metal Service Load Balancers也在被开发. 10.Job  批处理任务Job,与RC,Deployment 、ReplicaSet、DaemonSet 类似Job 也控制一组Pod容器。从这个角度来看Job 也是特殊的Pod 副本自动控制同时Job 控制Pod副本与RC 等控制器的工作机制有一下区别  1Job所控制的Pod副本是短暂运⾏的可以将其视为⼀组 Docker容器其中的每个Docker容器都仅仅运 ⾏⼀次。当Job控制的所有Pod副本都运⾏结束时对应的Job也就结束了。Job在实现⽅式上与 RC等副本控制器不 同Job⽣成的Pod副本是不能⾃动重启的对应Pod 副本的RestartPoliy都被设置为Never。因此当对应的Pod副本都执⾏完 成时相应的Job也就完成了控制使命即Job⽣成的Pod在Kubernetes中 是短暂存在的。Kubernetes在1.5版本之后⼜提供了类似crontab的定时任 务——CronJob解决了某些批处理任务需要定时反复执⾏的问题。 2Job所控制的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 VolumePV和与之相 关联的Persistent Volume ClaimPVC也起到了类似的作⽤。 PV可以被理解成Kubernetes集群中的某个⽹络存储对应的⼀块存储它与Volume类似但有以下区别。 PV只能是⽹络存储不属于任何Node但可以在每个Node上访问。 PV并不是被定义在Pod上的⽽是独⽴于Pod之外定义的。 PV⽬前⽀持的类型包括gcePersistentDisk、 AWSElasticBlockStore、AzureFile、AzureDisk、FCFibreChannel、 Flocker、NFS、iSCSI、RBDRados 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已经被删除但资源还没有被集群收 回。 ◎ FailedPV⾃动回收失败。 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可以来⾃ 某个⽂本⽂件⽐如配置项 password123456、userroot、 host192.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就成了分 布式系统中最为简单使⽤⽅法简单但背后实现⽐较复杂且对应⽤⽆侵⼊的配置中⼼