Kubernetes入门学习

kubernetes技术架构模型

一、kubernetes的Label标签

        1.标签是以key=value的格式通过用户自定义指定，目的是将其加入到各种资源对象上来实现多维度的资源分组管理使其更方便的进行资源分配、调度、配置和部署管理工作。

        2.标签可以结合Label Selector(标签选择器)查询和筛选拥有某些标签的资源对象。

           label 和 label selector两者结合使被管理的对象能更精细的分组管理实现集群的高可用。

        3.label selector 的使用场景：

                kube-controller进程通过资源对象RC上定义的label selector 来筛选要监控的Pod副本的数量，使Pod的数量始终符合预期设定的全自动控制流程。

                kube-proxy进程通过Service的label selector来选择对应的pod,自动建立每个Service到对应Pod的请求转发路由表

二、Replication Controller(RC)

             1. RC主要是定义了一个期望的场景声明某种pod的副本数量在任意时刻都符合预期值

             2.  RC包括：

                  pod期待的副本数

                  用于筛选目标pod的label selector

                  用于创建新pod的template模板

              3.RC中的replicas表示期望pod的副本数

                  rc中动态缩放命令： kubectl scale rc  pod名称 --replicas=x （x表示期望的pod副本数）

                  可以通过这个命令修改rc的副本数来实现pod的动态缩放功能

                  注：删除rc不会影响rc已经创建好的pod，可以通过上述操作命令设置replicas=0来删除已经存在的rc

                    RC的应用场景：在做应用的平滑升级时，设置rc中期待的副本数为x,表示系统中发始终运行10个pod,每次终止一个旧的版本就会自动生成一个新的版本。

三、Deployment

                  1.引入deployment的目的是更好的解决pod的编排问题，其内部使用的是replica set来实现前面所说的RC（它和RC的区别在于它支持集合的方式去声明label selector）。

                  2.deployment相对于RC的的亮点在于它可以随时知道pod的部署进度。

                  3.depolyment的使用场景：

•           创建deployment对象来生成对对应的replica set完成pod副本的创建造
•           通过deployment的状态来查看部署动作是否完成
•           更新depolument来创建新的pod（版本升级），如果不稳定可以回滚到上一个版               本 
•           可以挂起或者恢复

                  4.通过kubectl create -f xxx-deployment.yaml可以创建deployment

                      通过 kubectl get deployment 来查看已创建的deployment的信息

四、Horizontal Pod Autoscaler(HPA)

                 1.HPA的提出需求：因为google对于kubernetes的定位是自动化和智能化，即当前的分布式系统可以根据当前系统中不同主机的负载情况然后自动触发水平扩展或缩容行为，而目前的手动控制的方式明显不符合kubernetes的设计理念，所以HPA应运而生。

                 2.HPA的实现原理：通过追踪RC控制的所有pod的负载情况来确定是否要针对性的调整期望的pod数量。

                    依据pod的实现原理可以知道hpa的实现首先需要衡量pod的负载情况的指标

               第一种是 CPUUtilizationPercentage

                               

                        CPUUtil是一个算术平均值（目标POD所有副本自身CPU1分钟内利用率的平均值），如果超过了80%则意味当前的副本数目不足以支撑更多的请求需要进行动态扩容，当高峰期过去后pod的利用率降下来则pod的副本数自动减少到一个适当的值。

                        当前这个参数值需要通过Heapster扩展组件来获取这个值

               第二种是应用程序自定义的度量指标，如服务在每秒内的请求数

                        上图示例中该参考值超过90%会触发自动动态扩容行为

                 3.kubectl autoscale deployment xxx --cpu-percent=90 --min=1  --max=10,该命令可以创建上述图片的等价效果。

四、Service(微服务)

           

上图为service的工作位置

        1.kubernetes中多个pod组成的集群被客户端访问过程：客户端通过负载均衡器（kube-proxy）将service接收到的请求转发到后端的某个pod实例并在内部实现服务的负载均衡和会话保持机制。

         2.kubernetes的服务发现

            机制：kubernetes中的Service都有唯一的cluster IP 和唯一的名字，名字由自己定义（固定在配置中）

              通过Service的名字找到cluster ip (通过 add-on增值包引入dns系统，将服务名作为dns域名)，直接使用服务名来建立通信连接。

          3.外部系统访问service的问题

                node ip : node节点的ip地址（集群中每个节点的物理网卡的ip地址，真实存在的物理网络）

                pod ip :pod的ip地址（docker engine 根据docker 0网桥的ip地址段进行分配）

                cluster ip:service 的ip 地址（虚拟ip,需要结合service port组成具体的通信端口，集群外的节点不能直接访问）

                 通过nodePort实现从外部访问集群内部：

              上述通过nodeport的方法是在kubernetes集群里每个node上为需要外部访问的service开启一个对应的tcp监听端口。

                可以通过设置一个负载均衡器对上述通信方式进行优化，主要是通过访问设置的负载均衡的ip地址来对访问的流量进行调度，实现集群内部的负载均衡。

五、Volume(存储卷)

              1.Volume是pod中可以被多个容器访问的共享目录，其生命周期和pod的生命周期相同但与容器的生命周期不相关，即容器终止或者重启时其卷中的数据不会丢失

上图示例是数据卷相关的配置文件写法

                 2.kubernetes的数据卷类型：empthDir(pod分配到Node是创建，初始内容为空，无需指定宿主机对应的文件目录，pod移除之后会被永久删除)、hostPath(pod挂载宿主机的文件或目录)、gcePersistentDisk(谷歌公有云提供的永久磁盘)、awsElasticBlockStore(亚马逊公有云提供的)、NFS(NFS网络文件系统提供共享存储目录)

六、Persistent Volume(某个网络存储中对应的一块存储)：简称PV（有状态的对象）

        1.pv和volume的区别：

        pv只能是网络存储，不属于任何node,可以在每个node上访问

        pv不是定义在pod上，独立于pod之外定义

        2.pv的accesModes属性：
             readWriteOnce:读写权限，只能被单个node 挂载

             readOnlyMany:只读权限，允许多个node挂载

             readWriteMany:读写权限，允许多个node挂载

七、namespace(命名空间)

        1.namespace是将集群内部的资源对象分配到不同的namespace中，形成逻辑上分组的不同项目，使不同的分组在共享使用集群内部整个资源同时还可以被分别管理。

         2.集群启动后会创建一个default的namespace,可以通过kubectl get namespaces来查看命名空间的信息，如果用户不指明，则其创建的pod和rc、service将会被系统创建到default的namespace的命名空间下