一、Pod的滚动升级

        1.服务升级的一般思路：停止与该服务相关的所有服务pod，重新拉去更新后的镜像并启动。这种方法存在一个比较现实的问题是逐步升级导致较长时间的服务不可用。

        2.Kubernetes滚动升级的思路：通过滚动升级的命令创建新的rc，自动控制旧的rc中pod副本的数量逐渐减少到0，新的rc中的pod的数量从0逐步增加到目标值，但这些过程的前提是要求旧的rc要和新的rc在相同的命名空间。

        pod滚动升级的示例图：

        3.具体配置文件需要注意的是：

                新rc的name不能和旧rc的名字相同

                需要在selector中至少有一个label与旧rc的label不同用来标识其为新的rc，比如一般在升级的过程中会增加名为version的label用来和旧的rc进行区分。

        4.滚动升级的命令：

                kubectl rolling-update redis-master -f redis-master-controller.yam   (使用配置文件)

                kubectl rolling-update redis-master  --image=redis-master:2.0  (不使用配置文件)

        5.pod版本回滚

                kubectl rolling-update redis-master --image=kubeguide/redis-master:2.0 --rollback

二、Sercice

        1.概念：通过创建Service 可以为一组具有相同功能的容器应用提供一个统一的入口地址并能够将请求进行负载分发到后端的各个容器上。

        2.对外提供服务的应用程序需要通过TCP/IP机制及监听IP和端口号来实现

        例如上例通过pod的ip地址和端口号访问容器的应用。这种访问方式存在的弊端是：pod的ip地址不可靠，比如pod所在的node发生故障时，pod将被kubernetes重新调度到另一台node上启动，其ip地址也必将发生变化；其次存在的弊端：容器的应用为分布式的部署方式，需要通过多个实例共同提供服务，且这些实例需要在前端设置负载均衡器来实现请求的分发。

        针对上述问题的解决方法：

                

        3.kubernetes两种负载分发策略：

                RoundRobin(轮询模式)：通过轮询的方式将请求转发到后端的各个pod上。

                SessionAffinity:基于客户端的ip地址进行会话保持模式，即第一次将某个客户端发起的请求转发到后端的某个pod上，之后从相同的客户端发起的请求都转发到后端相同的pod上。

         默认情况下采用的负载分发策略是轮询模式进行路由选择。

三、DNS服务搭建

        1.需求：在kubernetes中，主要是为了能够通过服务名在集群内部进行服务的相互访问，则需要创建虚拟的dns服务来完成服务名到clusterIP的解析

        2.kubernetes中提供的虚拟dns服务名为skydns

                组成：etcd(dns存储)        kube2sky(将kubernetes master中的service 注册到etcd)        skyDNS(提供dns域名解析服务)        healthz(提供对skydns服务的健康检查功能)

        上图中，kube2sky容器调用kubernetes master 的api获得集群中所有service的信息并持续监控新的service的生成。

        3.在配置上述服务过程需要注意的问题：

                skydns使用的clusterIP需要指定固定的ip地址，因为每个node的kubelet进程都要使用这个ip地址而不是通过kubernetes自动分配。

                

        kubelet设置启动参数会在每个新创建的pod中设置dns域名解析配置文件/etc/resolv.conf，在其中会增加一条nameserver的配置和一条search配置。

四、Ingress（http7层路由机制）

        1.提出需求：在基于http服务来说，不同的url地址对应到不同的后端服务或者虚拟服务器，如果仅通过kubernetes的service机制是无法实现，ingress的诞生，可以将不同的url请求访问转发到后端不同的service，实现http层的业务路由机制。

        

        2.Ingress的实现：

                创建ingress controller

                        ingress controller的部署时为了实现为后端service提供一个统一的入口，基于不通风的http url向后转发的负载分发规则。

                        ingress controller是以pod的形式运行，监控ingress接口后端的service。

                使用nginx 实现 ingress controller的基本逻辑：

                        监听apiserver,获取全部的ingress的定义

                        基于Ingress的定义，生成nginx所需的配置文件/etc/nginx/nginx.conf

                        执行 nginx -s reload 命令重新加载nginx.conf配置文件

                定义ingress

                访问方式：

                        由于 ingress controller 设置了hostPort,可以通过其所在的物理机进行访问

                         curl  --resolve  mywebsite.com:80:192.168.18.3  mywebsite.com/foo