做淘宝那样的网站麻烦吗,文化网站前置审批,网站建设音乐插件怎么弄,凡科网小程序怎么样1、基础架构 1.1 Master Master节点上面主要由四个模块组成#xff1a;APIServer、scheduler、controller manager、etcd。 APIServer。APIServer负责对外提供RESTful的Kubernetes API服务#xff0c;它是系统管理指令的统一入口#xff0c;任何对资源进行增删改查的操作都要… 1、基础架构 1.1 Master Master节点上面主要由四个模块组成APIServer、scheduler、controller manager、etcd。 APIServer。APIServer负责对外提供RESTful的Kubernetes API服务它是系统管理指令的统一入口任何对资源进行增删改查的操作都要交给APIServer处理后再提交给etcd。如架构图中所示kubectlKubernetes提供的客户端工具该工具内部就是对Kubernetes API的调用是直接和APIServer交互的。 schedule。scheduler的职责很明确就是负责调度pod到合适的Node上。如果把scheduler看成一个黑匣子那么它的输入是pod和由多个Node组成的列表输出是Pod和一个Node的绑定即将这个pod部署到这个Node上。Kubernetes目前提供了调度算法但是同样也保留了接口用户可以根据自己的需求定义自己的调度算法。 controller manager。如果说APIServer做的是“前台”的工作的话那controller manager就是负责“后台”的。每个资源一般都对应有一个控制器而controller manager就是负责管理这些控制器的。比如我们通过APIServer创建一个pod当这个pod创建成功后APIServer的任务就算完成了。而后面保证Pod的状态始终和我们预期的一样的重任就由controller manager去保证了。 etcd。etcd是一个高可用的键值存储系统Kubernetes使用它来存储各个资源的状态从而实现了Restful的API。 1.2 Node 每个Node节点主要由三个模块组成kubelet、kube-proxy、runtime。 runtime。runtime指的是容器运行环境目前Kubernetes支持docker和rkt两种容器。 kube-proxy。该模块实现了Kubernetes中的服务发现和反向代理功能。反向代理方面kube-proxy支持TCP和UDP连接转发默认基于Round Robin算法将客户端流量转发到与service对应的一组后端pod。服务发现方面kube-proxy使用etcd的watch机制监控集群中service和endpoint对象数据的动态变化并且维护一个service到endpoint的映射关系从而保证了后端pod的IP变化不会对访问者造成影响。另外kube-proxy还支持session affinity。 kubelet。Kubelet是Master在每个Node节点上面的agent是Node节点上面最重要的模块它负责维护和管理该Node上面的所有容器但是如果容器不是通过Kubernetes创建的它并不会管理。本质上它负责使Pod得运行状态与期望的状态一致。 至此Kubernetes的Master和Node就简单介绍完了。下面我们来看Kubernetes中的各种资源/对象。 2、Pod Pod 是Kubernetes的基本操作单元也是应用运行的载体。整个Kubernetes系统都是围绕着Pod展开的比如如何部署运行Pod、如何保证Pod的数量、如何访问Pod等。另外Pod是一个或多个机关容器的集合这可以说是一大创新点提供了一种容器的组合的模型。 2.1 基本操作 创建 kubectl create -f xxx.yaml 查询 kubectl get pod yourPodName kubectl describe pod yourPodName 删除 kubectl delete pod yourPodName 更新 kubectl replace /path/to/yourNewYaml.yaml 2.2 Pod与容器 在Docker中容器是最小的处理单元增删改查的对象是容器容器是一种虚拟化技术容器之间是隔离的隔离是基于Linux Namespace实现的。而在Kubernetes中Pod包含一个或者多个相关的容器Pod可以认为是容器的一种延伸扩展一个Pod也是一个隔离体而Pod内部包含的一组容器又是共享的包括PID、Network、IPC、UTS。除此之外Pod中的容器可以访问共同的数据卷来实现文件系统的共享。 2.3 镜像 在kubernetes中镜像的下载策略为 Always每次都下载最新的镜像 Never只使用本地镜像从不下载 IfNotPresent只有当本地没有的时候才下载镜像 Pod被分配到Node之后会根据镜像下载策略进行镜像下载可以根据自身集群的特点来决定采用何种下载策略。无论何种策略都要确保Node上有正确的镜像可用。 2.4 其他设置 通过yaml文件可以在Pod中设置 启动命令如spec--containers--command 环境变量如spec--containers--env--name/value 端口桥接如spec--containers--ports--containerPort/protocol/hostIP/hostPort使用hostPort时需要注意端口冲突的问题不过Kubernetes在调度Pod的时候会检查宿主机端口是否冲突比如当两个Pod均要求绑定宿主机的80端口Kubernetes将会将这两个Pod分别调度到不同的机器上; Host网络一些特殊场景下容器必须要以host方式进行网络设置如接收物理机网络才能够接收到的组播流在Pod中也支持host网络的设置如spec--hostNetworktrue 数据持久化如spec--containers--volumeMounts--mountPath; 重启策略当Pod中的容器终止退出后重启容器的策略。这里的所谓Pod的重启实际上的做法是容器的重建之前容器中的数据将会丢失如果需要持久化数据那么需要使用数据卷进行持久化设置。Pod支持三种重启策略Always默认策略当容器终止退出后总是重启容器、OnFailure当容器终止且异常退出时重启、Never从不重启 2.5 Pod生命周期 Pod被分配到一个Node上之后就不会离开这个Node直到被删除。当某个Pod失败首先会被Kubernetes清理掉之后ReplicationController将会在其它机器上或本机重建Pod重建之后Pod的ID发生了变化那将会是一个新的Pod。所以Kubernetes中Pod的迁移实际指的是在新Node上重建Pod。以下给出Pod的生命周期图。 生命周期回调函数PostStart容器创建成功后调研该回调函数、PreStop在容器被终止前调用该回调函数。以下示例中定义了一个Pod包含一个JAVA的web应用容器其中设置了PostStart和PreStop回调函数。即在容器创建成功后复制/sample.war到/app文件夹中。而在容器终止之前发送HTTP请求到http://monitor.com:8080/waring即向监控系统发送警告。具体示例如下 ………..
containers:
- image: sample:v2 name: warlifecycleposrStart:exec:command:- “cp”- “/sample.war”- “/app”prestop:httpGet:host: monitor.compsth: /waringport: 8080scheme: HTTP 3、Replication Controller Replication ControllerRC是Kubernetes中的另一个核心概念应用托管在Kubernetes之后Kubernetes需要保证应用能够持续运行这是RC的工作内容它会确保任何时间Kubernetes中都有指定数量的Pod在运行。在此基础上RC还提供了一些更高级的特性比如滚动升级、升级回滚等。 3.1 RC与Pod的关联——Label RC与Pod的关联是通过Label来实现的。Label机制是Kubernetes中的一个重要设计通过Label进行对象的弱关联可以灵活地进行分类和选择。对于Pod需要设置其自身的Label来进行标识Label是一系列的Key/value对在Pod--metadata--labeks中进行设置。 Label的定义是任一的但是Label必须具有可标识性比如设置Pod的应用名称和版本号等。另外Lable是不具有唯一性的为了更准确的标识一个Pod应该为Pod设置多个维度的label。如下 release : stable, release : canary environment : dev, environment : qa, environment : production tier : frontend, tier : backend, tier : cache partition : customerA, partition : customerB track : daily, track : weekly 举例当你在RC的yaml文件中定义了该RC的selector中的label为app:my-web那么这个RC就会去关注Pod--metadata--labeks中label为app:my-web的Pod。修改了对应Pod的Label就会使Pod脱离RC的控制。同样在RC运行正常的时候若试图继续创建同样Label的Pod是创建不出来的。因为RC认为副本数已经正常了再多起的话会被RC删掉的。 3.2 弹性伸缩 弹性伸缩是指适应负载变化以弹性可伸缩的方式提供资源。反映到Kubernetes中指的是可根据负载的高低动态调整Pod的副本数量。调整Pod的副本数是通过修改RC中Pod的副本是来实现的示例命令如下 扩容Pod的副本数目到10 $ kubectl scale relicationcontroller yourRcName --replicas10 缩容Pod的副本数目到1 $ kubectl scale relicationcontroller yourRcName --replicas1 3.3 滚动升级 滚动升级是一种平滑过渡的升级方式通过逐步替换的策略保证整体系统的稳定在初始升级的时候就可以及时发现、调整问题以保证问题影响度不会扩大。Kubernetes中滚动升级的命令如下 $ kubectl rolling-update my-rcName-v1 -f my-rcName-v2-rc.yaml --update-period10s 升级开始后首先依据提供的定义文件创建V2版本的RC然后每隔10s--update-period10s逐步的增加V2版本的Pod副本数逐步减少V1版本Pod的副本数。升级完成之后删除V1版本的RC保留V2版本的RC及实现滚动升级。 升级过程中发生了错误中途退出时可以选择继续升级。Kubernetes能够智能的判断升级中断之前的状态然后紧接着继续执行升级。当然也可以进行回退命令如下 $ kubectl rolling-update my-rcName-v1 -f my-rcName-v2-rc.yaml --update-period10s --rollback 回退的方式实际就是升级的逆操作逐步增加V1.0版本Pod的副本数逐步减少V2版本Pod的副本数。 3.4 新一代副本控制器replica set 这里所说的replica set可以被认为 是“升级版”的Replication Controller。也就是说。replica set也是用于保证与label selector匹配的pod数量维持在期望状态。区别在于replica set引入了对基于子集的selector查询条件而Replication Controller仅支持基于值相等的selecto条件查询。这是目前从用户角度肴两者唯一的显著差异。 社区引入这一API的初衷是用于取代vl中的Replication Controller也就是说当v1版本被废弃时Replication Controller就完成了它的历史使命而由replica set来接管其工作。虽然replica set可以被单独使用但是目前它多被Deployment用于进行pod的创建、更新与删除。Deployment在滚动更新等方面提供了很多非常有用的功能关于DeplOymCn的更多信息读者们可以在后续小节中获得。 4、Job 从程序的运行形态上来区分我们可以将Pod分为两类长时运行服务jboss、mysql等和一次性任务数据计算、测试。RC创建的Pod都是长时运行的服务而Job创建的Pod都是一次性任务。 在Job的定义中restartPolicy重启策略只能是Never和OnFailure。Job可以控制一次性任务的Pod的完成次数Job--spec--completions和并发执行数Job--spec--parallelism当Pod成功执行指定次数后即认为Job执行完毕。 5、Service 为了适应快速的业务需求微服务架构已经逐渐成为主流微服务架构的应用需要有非常好的服务编排支持。Kubernetes中的核心要素Service便提供了一套简化的服务代理和发现机制天然适应微服务架构。 5.1 原理 在Kubernetes中在受到RC调控的时候Pod副本是变化的对于的虚拟IP也是变化的比如发生迁移或者伸缩的时候。这对于Pod的访问者来说是不可接受的。Kubernetes中的Service是一种抽象概念它定义了一个Pod逻辑集合以及访问它们的策略Service同Pod的关联同样是居于Label来完成的。Service的目标是提供一种桥梁 它会为访问者提供一个固定访问地址用于在访问时重定向到相应的后端这使得非 Kubernetes原生应用程序在无须为Kubemces编写特定代码的前提下轻松访问后端。 Service同RC一样都是通过Label来关联Pod的。当你在Service的yaml文件中定义了该Service的selector中的label为app:my-web那么这个Service会将Pod--metadata--labeks中label为app:my-web的Pod作为分发请求的后端。当Pod发生变化时增加、减少、重建等Service会及时更新。这样一来Service就可以作为Pod的访问入口起到代理服务器的作用而对于访问者来说通过Service进行访问无需直接感知Pod。 需要注意的是Kubernetes分配给Service的固定IP是一个虚拟IP并不是一个真实的IP在外部是无法寻址的。真实的系统实现上Kubernetes是通过Kube-proxy组件来实现的虚拟IP路由及转发。所以在之前集群部署的环节上我们在每个Node上均部署了Proxy这个组件从而实现了Kubernetes层级的虚拟转发网络。 5.2 Service代理外部服务 Service不仅可以代理Pod还可以代理任意其他后端比如运行在Kubernetes外部Mysql、Oracle等。这是通过定义两个同名的service和endPoints来实现的。示例如下 redis-service.yaml apiVersion: v1
kind: Service
metadata:name: redis-service
spec:ports:- port: 6379targetPort: 6379protocol: TCP redis-endpoints.yaml apiVersion: v1
kind: Endpoints
metadata:name: redis-service
subsets:- addresses:- ip: 10.0.251.145ports:- port: 6379protocol: TCP 基于文件创建完Service和Endpoints之后在Kubernetes的Service中即可查询到自定义的Endpoints。 [rootk8s-master demon]# kubectl describe service redis-service
Name: redis-service
Namespace: default
Labels: none
Selector: none
Type: ClusterIP
IP: 10.254.52.88
Port: unset 6379/TCP
Endpoints: 10.0.251.145:6379
Session Affinity: None
No events.
[rootk8s-master demon]# etcdctl get /skydns/sky/default/redis-service
{host:10.254.52.88,priority:10,weight:10,ttl:30,targetstrip:0} 5.3 Service内部负载均衡 当Service的Endpoints包含多个IP的时候及服务代理存在多个后端将进行请求的负载均衡。默认的负载均衡策略是轮训或者随机有kube-proxy的模式决定。同时Service上通过设置Service--spec--sessionAffinityClientIP来实现基于源IP地址的会话保持。 5.4 发布Service Service的虚拟IP是由Kubernetes虚拟出来的内部网络外部是无法寻址到的。但是有些服务又需要被外部访问到例如web前段。这时候就需要加一层网络转发即外网到内网的转发。Kubernetes提供了NodePort、LoadBalancer、Ingress三种方式。 NodePort在之前的Guestbook示例中已经延时了NodePort的用法。NodePort的原理是Kubernetes会在每一个Node上暴露出一个端口nodePort外部网络可以通过任一Node[NodeIP]:[NodePort]访问到后端的Service。 LoadBalancer在NodePort基础上Kubernetes可以请求底层云平台创建一个负载均衡器将每个Node作为后端进行服务分发。该模式需要底层云平台例如GCE支持。 Ingress是一种HTTP方式的路由转发机制由Ingress Controller和HTTP代理服务器组合而成。Ingress Controller实时监控Kubernetes API实时更新HTTP代理服务器的转发规则。HTTP代理服务器有GCE Load-Balancer、HaProxy、Nginx等开源方案。 5.5 servicede 自发性机制 Kubernetes中有一个很重要的服务自发现特性。一旦一个service被创建该service的service IP和service port等信息都可以被注入到pod中供它们使用。Kubernetes主要支持两种service发现 机制环境变量和DNS。 环境变量方式 Kubernetes创建Pod时会自动添加所有可用的service环境变量到该Pod中如有需要这些环境变量就被注入Pod内的容器里。需要注意的是环境变量的注入只发送在Pod创建时且不会被自动更新。这个特点暗含了service和访问该service的Pod的创建时间的先后顺序即任何想要访问service的pod都需要在service已经存在后创建否则与service相关的环境变量就无法注入该Pod的容器中这样先创建的容器就无法发现后创建的service。 DNS方式 Kubernetes集群现在支持增加一个可选的组件——DNS服务器。这个DNS服务器使用Kubernetes的watchAPI不间断的监测新的service的创建并为每个service新建一个DNS记录。如果DNS在整个集群范围内都可用那么所有的Pod都能够自动解析service的域名。Kube-DNS搭建及更详细的介绍请见基于Kubernetes集群部署skyDNS服务 5.6 多个service如何避免地址和端口冲突 此处设计思想是Kubernetes通过为每个service分配一个唯一的ClusterIP所以当使用ClusterIPport的组合访问一个service的时候不管port是什么这个组合是一定不会发生重复的。另一方面kube-proxy为每个service真正打开的是一个绝对不会重复的随机端口用户在service描述文件中指定的访问端口会被映射到这个随机端口上。这就是为什么用户可以在创建service时随意指定访问端口。 5.7 service目前存在的不足 Kubernetes使用iptables和kube-proxy解析service的人口地址在中小规模的集群中运行良好但是当service的数量超过一定规模时仍然有一些小问题。首当其冲的便是service环境变量泛滥以及service与使用service的pod两者创建时间先后的制约关系。目前来看很多使用者在使用Kubernetes时往往会开发一套自己的Router组件来替代service以便更好地掌控和定制这部分功能。 6、Deployment Kubernetes提供了一种更加简单的更新RC和Pod的机制叫做Deployment。通过在Deployment中描述你所期望的集群状态Deployment Controller会将现在的集群状态在一个可控的速度下逐步更新成你所期望的集群状态。Deployment主要职责同样是为了保证pod的数量和健康90%的功能与Replication Controller完全一样可以看做新一代的Replication Controller。但是它又具备了Replication Controller之外的新特性 Replication Controller全部功能Deployment继承了上面描述的Replication Controller全部功能。 事件和状态查看可以查看Deployment的升级详细进度和状态。 回滚当升级pod镜像或者相关参数的时候发现问题可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。 版本记录: 每一次对Deployment的操作都能保存下来给予后续可能的回滚使用。 暂停和启动对于每一次升级都能够随时暂停和启动。 多种升级方案Recreate----删除所有已存在的pod,重新创建新的; RollingUpdate----滚动升级逐步替换的策略同时滚动升级时支持更多的附加参数例如设置最大不可用pod数量最小升级间隔时间等等。 6.1 滚动升级 相比于RCDeployment直接使用kubectl edit deployment/deploymentName 或者kubectl set方法就可以直接升级原理是Pod的template发生变化例如更新label、更新镜像版本等操作会触发Deployment的滚动升级。操作示例——首先 我们同样定义一个nginx-deploy-v1.yaml的文件副本数量为2 apiVersion: extensions/v1beta1
kind: Deployment
metadata:name: nginx-deployment
spec:replicas: 3template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.7.9ports:- containerPort: 80 创建deployment $ kubectl create -f nginx-deploy-v1.yaml --record
deployment nginx-deployment created
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 0 0 0 1s
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 18s 正常之后将nginx的版本进行升级从1.7升级到1.9。第一种方法直接set镜像 $ kubectl set image deployment/nginx-deployment2 nginxnginx:1.9
deployment nginx-deployment2 image updated 第二种方法直接edit $ kubectl edit deployment/nginx-deployment
deployment nginx-deployment2 edited 查看Deployment的变更信息以下信息得以保存是创建时候加的“--record”这个选项起的作用 $ kubectl rollout history deployment/nginx-deployment
deployments nginx-deployment:
REVISION CHANGE-CAUSE
1 kubectl create -f docs/user-guide/nginx-deployment.yaml --record
2 kubectl set image deployment/nginx-deployment nginxnginx:1.9.1
3 kubectl set image deployment/nginx-deployment nginxnginx:1.91$ kubectl rollout history deployment/nginx-deployment --revision2
deployments nginx-deployment revision 2Labels: appnginxpod-template-hash1159050644Annotations: kubernetes.io/change-causekubectl set image deployment/nginx-deployment nginxnginx:1.9.1Containers:nginx:Image: nginx:1.9.1Port: 80/TCPQoS Tier:cpu: BestEffortmemory: BestEffortEnvironment Variables: noneNo volumes. 最后介绍下Deployment的一些基础命令。 $ kubectl describe deployments #查询详细信息获取升级进度
$ kubectl rollout pause deployment/nginx-deployment2 #暂停升级
$ kubectl rollout resume deployment/nginx-deployment2 #继续升级
$ kubectl rollout undo deployment/nginx-deployment2 #升级回滚
$ kubectl scale deployment nginx-deployment --replicas 10 #弹性伸缩Pod数量 关于多重升级举例当你创建了一个nginx1.7的Deployment要求副本数量为5之后Deployment Controller会逐步的将5个1.7的Pod启动起来当启动到3个的时候你又发出更新Deployment中Nginx到1.9的命令这时Deployment Controller会立即将已启动的3个1.7Pod杀掉然后逐步启动1.9的Pod。Deployment Controller不会等到1.7的Pod都启动完成之后再依次杀掉1.7启动1.9。 7、Volume 在Docker的设计实现中容器中的数据是临时的即当容器被销毁时其中的数据将会丢失。如果需要持久化数据需要使用Docker数据卷挂载宿主机上的文件或者目录到容器中。在Kubernetes中当Pod重建的时候数据是会丢失的Kubernetes也是通过数据卷挂载来提供Pod数据的持久化的。Kubernetes数据卷是对Docker数据卷的扩展Kubernetes数据卷是Pod级别的可以用来实现Pod中容器的文件共享。目前Kubernetes支持的数据卷类型如下 1) EmptyDir 2) HostPath 3) GCE Persistent Disk 4) AWS Elastic Block Store 5) NFS 6) iSCSI 7) Flocker 8) GlusterFS 9) RBD 10) Git Repo 11) Secret 12) Persistent Volume Claim 13) Downward API 7.1本地数据卷 EmptyDir、HostPath这两种类型的数据卷只能最用于本地文件系统。本地数据卷中的数据只会存在于一台机器上所以当Pod发生迁移的时候数据便会丢失。该类型Volume的用途是Pod中容器间的文件共享、共享宿主机的文件系统。 7.1.1 EmptyDir 如果Pod配置了EmpyDir数据卷在Pod的生命周期内都会存在当Pod被分配到 Node上的时候会在Node上创建EmptyDir数据卷并挂载到Pod的容器中。只要Pod 存在EmpyDir数据卷都会存在容器删除不会导致EmpyDir数据卷丟失数据但是如果Pod的生命周期终结Pod被删除EmpyDir数据卷也会被删除并且永久丢失。 EmpyDir数据卷非常适合实现Pod中容器的文件共享。Pod的设计提供了一个很好的容器组合的模型容器之间各司其职通过共享文件目录来完成交互比如可以通过一个专职日志收集容器在每个Pod中和业务容器中进行组合来完成日志的收集和汇总。 7.1.2 HostPath HostPath数据卷允许将容器宿主机上的文件系统挂载到Pod中。如果Pod需要使用宿主机上的某些文件可以使用HostPath。 7.2网络数据卷 Kubernetes提供了很多类型的数据卷以集成第三方的存储系统包括一些非常流行的分布式文件系统也有在IaaS平台上提供的存储支持这些存储系统都是分布式的通过网络共享文件系统因此我们称这一类数据卷为网络数据卷。 网络数据卷能够满足数据的持久化需求Pod通过配置使用网络数据卷每次Pod创建的时候都会将存储系统的远端文件目录挂载到容器中数据卷中的数据将被水久保存即使Pod被删除只是除去挂载数据卷数据卷中的数据仍然保存在存储系统中且当新的Pod被创建的时候仍是挂载同样的数据卷。网络数据卷包含以下几种NFS、iSCISI、GlusterFS、RBDCeph Block Device、Flocker、AWS Elastic Block Store、GCE Persistent Disk 7.3 Persistent Volume和Persistent Volume Claim 理解每个存储系统是一件复杂的事情特别是对于普通用户来说有时候并不需要关心各种存储实现只希望能够安全可靠地存储数据。Kubernetes中提供了Persistent Volume和Persistent Volume Claim机制这是存储消费模式。Persistent Volume是由系统管理员配置创建的一个数据卷目前支持HostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、iSCSI、GlusterFS、RBD它代表了某一类存储插件实现而对于普通用户来说通过Persistent Volume Claim可请求并获得合适的Persistent Volume而无须感知后端的存储实现。Persistent Volume和Persistent Volume Claim的关系其实类似于Pod和NodePod消费Node资源Persistent Volume Claim则消费Persistent Volume资源。Persistent Volume和Persistent Volume Claim相互关联有着完整的生命周期管理 1) 准备系统管理员规划或创建一批Persistent Volume 2) 绑定用户通过创建Persistent Volume Claim来声明存储请求Kubernetes发现有存储请求的时候就去查找符合条件的Persistent Volume最小满足策略。找到合适的就绑定上找不到就一直处于等待状态 3) 使用创建Pod的时候使用Persistent Volume Claim 4) 释放当用户删除绑定在Persistent Volume上的Persistent Volume Claim时Persistent Volume进入释放状态此时Persistent Volume中还残留着上一个Persistent Volume Claim的数据状态还不可用 5) 回收是否的Persistent Volume需要回收才能再次使用。回收策略可以是人工的也可以是Kubernetes自动进行清理仅支持NFS和HostPath 7.4信息数据卷 Kubernetes中有一些数据卷主要用来给容器传递配置信息我们称之为信息数据卷比如Secret处理敏感配置信息密码、Token等、Downward API通过环境变量的方式告诉容器Pod的信息、Git Repo将Git仓库下载到Pod中都是将Pod的信息以文件形式保存然后以数据卷方式挂载到容器中容器通过读取文件获取相应的信息。 8、Pet Sets/StatefulSet K8s在1.3版本里发布了Alpha版的PetSet功能。在云原生应用的体系里有下面两组近义词第一组是无状态stateless、牲畜cattle、无名nameless、可丢弃disposable第二组是有状态stateful、宠物pet、有名having name、不可丢弃non-disposable。RC和RS主要是控制提供无状态服务的其所控制的Pod的名字是随机设置的一个Pod出故障了就被丢弃掉在另一个地方重启一个新的Pod名字变了、名字和启动在哪儿都不重要重要的只是Pod总数而PetSet是用来控制有状态服务PetSet中的每个Pod的名字都是事先确定的不能更改。PetSet中Pod的名字的作用是用来关联与该Pod对应的状态。 对于RC和RS中的Pod一般不挂载存储或者挂载共享存储保存的是所有Pod共享的状态Pod像牲畜一样没有分别对于PetSet中的Pod每个Pod挂载自己独立的存储如果一个Pod出现故障从其他节点启动一个同样名字的Pod要挂在上原来Pod的存储继续以它的状态提供服务。 适合于PetSet的业务包括数据库服务MySQL和PostgreSQL集群化管理服务Zookeeper、etcd等有状态服务。PetSet的另一种典型应用场景是作为一种比普通容器更稳定可靠的模拟虚拟机的机制。传统的虚拟机正是一种有状态的宠物运维人员需要不断地维护它容器刚开始流行时我们用容器来模拟虚拟机使用所有状态都保存在容器里而这已被证明是非常不安全、不可靠的。使用PetSetPod仍然可以通过漂移到不同节点提供高可用而存储也可以通过外挂的存储来提供高可靠性PetSet做的只是将确定的Pod与确定的存储关联起来保证状态的连续性。 9、ConfigMap 很多生产环境中的应用程序配置较为复杂可能需要多个config文件、命令行参数和环境变量的组合。并且这些配置信息应该从应用程序镜像中解耦出来以保证镜像的可移植性以及配置信息不被泄露。社区引入ConfigMap这个API资源来满足这一需求。 ConfigMap包含了一系列的键值对用于存储被Pod或者系统组件如controller访问的信息。这与secret的设计理念有异曲同工之妙它们的主要区别在于ConfigMap通常不用于存储敏感信息而只存储简单的文本信息。 10、Horizontal Pod Autoscaler 自动扩展作为一个长久的议题一直为人们津津乐道。系统能够根据负载的变化对计算资源的分配进行自动的扩增或者收缩无疑是一个非常吸引人的特征它能够最大可能地减少费用或者其他代价如电力损耗。自动扩展主要分为两种其一为水平扩展针对于实例数目的增减其二为垂直扩展即单个实例可以使用的资源的增减。Horizontal Pod AutoscalerHPA属于前者。 10.1 Horizontal Pod Autoscaler如何工作 Horizontal Pod Autoscaler的操作对象是Replication Controller、ReplicaSet或Deployment对应的Pod根据观察到的CPU实际使用量与用户的期望值进行比对做出是否需要增减实例数量的决策。controller目前使用heapSter来检测CPU使用量检测周期默认是30秒。 10.2 Horizontal Pod Autoscaler的决策策略 在HPA Controller检测到CPU的实际使用量之后会求出当前的CPU使用率实际使用量与pod 请求量的比率)。然后HPA Controller会通过调整副本数量使得CPU使用率尽量向期望值靠近另外考虑到自动扩展的决策可能需要一段时间才会生效甚至在短时间内会引入一些噪声 例如当pod所需要的CPU负荷过大从而运行一个新的pod进行分流在创建的过程中系统的CPU使用量可能会有一个攀升的过程。所以在每一次作出决策后的一段时间内将不再进行扩展决策。对于ScaleUp而言这个时间段为3分钟Scaledown为5分钟。再者HPA Controller允许一定范围内的CPU使用量的不稳定也就是说只有当aVgCurrentPodConsumptionTarget低于0.9或者高于1.1时才进行实例调整这也是出于维护系统稳定性的考虑。 转载于:https://www.cnblogs.com/WayneZeng/p/9290794.html
