Docker系列(十一):Kubernetes集群集群部署实践

Kubernetes分布式集群架构

Docker系列(十一):Kubernetes集群集群部署实践_第1张图片
Docker系列(十一):Kubernetes集群集群部署实践_第2张图片
Docker系列(十一):Kubernetes集群集群部署实践_第3张图片
服务注册和服务发现问题怎么解决的?
分布式通讯的核心就是ip加端口
每个服务分配一个不变的虚拟IP+端口
系统env环境变量里有每个服务的服务名称到IP的映射
如下:
Docker系列(十一):Kubernetes集群集群部署实践_第4张图片

client = new redis\Client([
'scheme' => 'tcp',
'host' => getenv('REDIS_MASTER_SERVICE_HOST') , 
'port' => $read_port,
]);

对程序没有任何的入侵

服务的负载均衡问题怎么解决的?
每个节点上都有一个软件实现的服务代理来实现负载均衡
Docker系列(十一):Kubernetes集群集群部署实践_第5张图片
kube-proxy每个node上都会部署,一个任务是代理,一个任务是负载均衡。
kube-proxy如上图所示,既可以转发给本地的po的,也可以转发给其他的node中pod

服务的规模部署问题怎么解决的?
Docker系列(十一):Kubernetes集群集群部署实践_第6张图片
服务运维问题如何解决的?
自动监控、自我修复
Docker系列(十一):Kubernetes集群集群部署实践_第7张图片
Docker系列(十一):Kubernetes集群集群部署实践_第8张图片

Kubernetes 集群架构例子

Docker系列(十一):Kubernetes集群集群部署实践_第9张图片
Docker系列(十一):Kubernetes集群集群部署实践_第10张图片

1.创建redis-master Pod和服务

redis-master-controller.yaml,下面给出了该文件的完整内容
Docker系列(十一):Kubernetes集群集群部署实践_第11张图片
Docker系列(十一):Kubernetes集群集群部署实践_第12张图片

2. 创建redis-slave Pod和服务

Docker系列(十一):Kubernetes集群集群部署实践_第13张图片
Docker系列(十一):Kubernetes集群集群部署实践_第14张图片
Docker系列(十一):Kubernetes集群集群部署实践_第15张图片

3. 创建php frontend Pod和服务

Docker系列(十一):Kubernetes集群集群部署实践_第16张图片
Docker系列(十一):Kubernetes集群集群部署实践_第17张图片
注意:type:nodeport每一个node上开一个端口,访问任何一个node的30001就可以到容器里面的80,相当于docker中的端口映射,就是讲容器中的端口映射到主机上的端口,为了让集群之外的能访问容器的port,应为容器是属于内部的,集群之外的是访问不了的。
Docker系列(十一):Kubernetes集群集群部署实践_第18张图片
根据是读操作还是写操作来判断走哪个
Docker系列(十一):Kubernetes集群集群部署实践_第19张图片
注意:访问的地址是node节点的ip而不是master加点的ip

集群运维常见问题

资源隔离与调度问题

怎么把某些服务调度到特定的节点上去?
Docker系列(十一):Kubernetes集群集群部署实践_第20张图片
给node加入lable
rc上面设置nodeselector

扩容与升级问题

Docker系列(十一):Kubernetes集群集群部署实践_第21张图片
扩容:kubectl scale。。。。中的replicas参数
滚动升级:加入A中有二十个用例,在升级的过程中是会终端的,希望是不间断的服务,先减一个pod,更新一个pod加进去,再减去一个pod。。。。。。用法升级版本号
image:v2

资源配额问题

Docker系列(十一):Kubernetes集群集群部署实践_第22张图片
如果用到资源配额,需要增加插件 如上图右上角的命令LimitRanger,ResourceQuota
kubernetes权威指南:
当Kubernetes启动一个容器时,会将CPU配额值乘以1024并转为整数传递给docker run的–cpu-shares参数,之所以乘以1024是因为Docker的cpu-shares参数是以1024 为基数计算CPU时间的。另外,Docker官方文档里解释说cpu-shares是一个相对权 重值 (relative weight),因此Kubernetes官方文档里解释cpu: 0.5表示该容器占用0.5 个CPU计算时间的说法其实是不准确的。仅当该节点是单核心CPU而且只运行两个 容器,每个容器的CPU配额设定为0.5时,上述说法才成立。假如一个节点上同时运 行了3个容器A,B,C,其中A容器的CPU配额设置为1,B与C设置为0.5。那么,当 系统的CPU利用率达到100%时,A容器只占用了1X100/(1+0.5+0.5)=50%的CPU时 间,而B与C分别占用25%的CPU时间。如果此时我们加入一个新的容器D,它的 CPU配额也设置为1,则通过计算我们得到A此时只占据33%的CPU时间。对于目前 主流的多核CPU,容器的CPU配额会在多核心上进行承担。因此在多核CPU上,即 使某个容器声明CPU<1,它也可能会占满多个CPU核。例如2个设定cpu=0.5的容器 运行在4核的CPU上,每个容器可能会用光4*0.5/(0.5+0.5)=2个CPU核。

你可能感兴趣的:(#,Big,Data,------,Docker)