1.Kubernetes是什么？
    ①一个全新的基于容器技术的分布式架构领先方案
    ②Kubernetes是一个开放的开发平台。各种语言编写的服务，都可以被映射为Kubernetes的Service，并通过标准的TCP通信协议进行交互
    ③Hubernetes是一个完备的分布式系统支撑平台。

    • 多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册与发现机制、内建的智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。
    • 提供完善的管理工具，这些工具涵盖了包括开发、部署测试、运维监控在内的各个环节

    2.Kubernetes中的Service
    ①分布式集群架构的核心，一个Service对象拥有如下关键特征

    • 拥有唯一指定的名称（比如mysql-server）
    • 拥有一个虚拟IP（Cluster IP，Service IP或VIP）和端口号
    • 能够提供某种远辰服务能力
    • 被映射到提供这种服务能力的一组容器应用上

    ②Service的服务进程目前都基于Socket通信方式对外提供服务
    ③容器提供了强大的隔离功能，所以有必要把为Service提供服务的这组进程放入容器中进行隔离

    • Kubernetes设计了pod对象，将每个服务进程都包装到相应的pod中，使其成为在Pod中运行的一个容器
    • 为了建立Service和Pod间的关联关系，Kubernetes首先给每个Pod都贴上一个标签（Label），给运行MySQL的Pod贴上name=mysql标签，然后给相应的Service定义标签选择器（Label Selector），比如MySQL Service的标签选择器的选择条件为name=mysql，意为该Service要作用于所有包含name=mysql Label的Pod

    3.Pod的概念简介
    ①Pod运行在一个被称为节点（Node）的环境中，这个节点既可以是物理机，也可以是私有云或公有云中的一个虚拟机，通常在一个Node上运行几百个Pod
    ②每个Pod都运行着一个特殊的被称为Pause的容器，其他容器则被称为业务容器，业务容器共享Pause容器的网络栈和Volume挂在卷
    ③并不是每个Pod和它里面运行的容器都能被映射到一个Service上，只有提供服务的那组Pod才会被映射为一个服务

    4.在集群管理方面，Kubernetes将集群划分为了一个Master和一些Node
    ①Master上运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错机制等管理功能，并且都是自动完成的
    ②在kubernetes集群中，只需要为扩容的Service关联的Pod创建一个RC，RC定义文件包含如下信息：

    • 目标Pod的定义
    • 目标Pod需要运行的副本数量
    • 需要监控的目标Pod的标签

    5.Master
    ①Master是集群的控制节点，每一个kubernetes集群都需要有一个Master节点来负责整个集群的管理和控制
    ②基本上Kubernetes的所有控制命令都发给Master，master负责集体的执行过程
    ③Master通常会占据一个独立的服务器（高可用部署建议用三台服务器），主要因为master太重要了，是整个集群的首脑，如果master宕机或者不可用，那么集群内容器应用的管理都将失效
    ④Master上运行着以下关键进程

    • Kubernetes API Server：提供了HTTP Rest接口的关键服务进程，是Kubernetes里所有资源增删改查等操作的唯一入口，也是集群控制的入口
    • Kubernetes Controller Manager：Kubernetes里所有资源对象的自动化控制中心，可以理解为资源对象的“大总管”
    • Kubernetes Schedule：负责资源调度（Pod调度）的进程，相当于公交公司的“调度室”
    • Master上通常还需要部署etcd服务，因为Kubernetes里的所有资源对象的数据都被保存在etcd中

    6.Node
    ①Node可以是一台物理主机，也可以是一台虚拟机。
    ②Node是Kubernetes集群中的工作负载节点，每个Node都会被Master分配一些工作负载（Docker容器），当某个Node宕机时，其上的工作负载会被Master自动转移到其他节点上
    ③每个Node节点上都运行着以下关键进程

    • kubelet：负责Pod对应容器的创建、启停等任务，同时与master密切协作，实现集群管理的基本功能
    • kube-proxy:实现Kubernetes Service的通信与负载均衡机制的重要组件
    • Docker Engine（Docker）：Docker引擎，负责本机的容器创建于管理工作

    ④Node可以在运行期间动态增加到Kubernetes集群中，前提是在这个节点上已经正确安装、配置和启动了上述关键进程，在默认情况下kubelet会向Master注册自己
    ⑤一旦Node被纳入集群管理范围，kubelet进程就会定时向Master汇报自身的情报，例如操作系统版本、Docker版本、机器的CPU和内存情况，以及当前有哪些Pod在运行等，这样master就可以获知每个Node的资源使用情况，并实现高效的资源调度策略。
    ⑥某个Node在超过指定时间不上报信息时，会被master判定为“失联”，Node状态被标记为不可用，随后Master会触发“工作负载大转移”的自动流程
    ⑦Node的关键信息;

    • Node的基本信息：名称、标签、创建时间等
    • Node当前的运行状态：Node启动后会做一系列的自检工作，比如磁盘空间是否不足、内存是否不足、网络是否正常、PID资源是否充足。在一切正常时设置Node为Ready状态，该状态表示Node处于健康状态，Master可以在其上调度新的任务了
    • Node的主机地址与主机名
    • Node上的资源数量：描述Node可用的系统资源，包括CPU、内存数量、最大可调度Pod数量等
    • Node可分配的资源量：描述Node当前可用于分配的资源量
    • 主机系统信息：包括主机ID、系统UUID、Linux kernel版本号、操作系统类型与版本、Docker版本号、kubelet与kube-proxy的版本号等
    • 当前运行的Pod列表概要信息
    • 已分配的资源使用概要信息，例如资源申请的最低、最大允许使用量占系统总量的百分比
    • Node相关的 事件信息

    7.Pod
    ①每个Pod都有一个特殊的被称为“根容器”的pause容器
    ②每个Pod还包含一个或多个紧密相关的用户业务容器
    ③Pod设计原因：

    • 在一组容器作为一个单元的情况下，我们难以简单地对“整体”进行判断及有效的行动。引入业务无关的并且不易死亡的Pause容器作为Pod的根容器，以它的状态代表整个容器组的状态。
    • Pod里多个业务容器共享Pause容器的IP，共享Pause容器挂接的Volume，这样既简化了密切关联的业务容器之间的通信问题，也很好地解决了他们之间的文件共享问题
    • Kubernetes为每个Pod都分配了唯一的IP地址，称之为Pod IP，一个Pod里的多个容器共享Pod IP。
    • Kubernetes要求底层网络支持集群内任意两个Pod之间的TCP/IP直接通信，这通常采用虚拟二层网络技术来实现。在Kubernetes里，一个Pod里的容器与另外主机上的Pod容器能够直接通信

    ④Pod有两种类型：

    • 普通的Pod：一旦被创建，就会被放入etcd中存储，随后会被kubernetes Master调度到某个具体的Node上进行绑定，随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器并启动。在默认情况下，当Pod里的某个容器停止时，Kubernetes会自动检测到这个问题并且重新启动这个Pod(重启这个Pod里的所有容器)，如果Pod所在的Node宕机，就会将这个Node上的所有Pod重新调度到其他节点上
    • 静态的Pod：没被存放在kubernetes的etcd存储里，而是被存放在某个具体的Node上的一个具体文件中，并且只在此Node上启动、运行

    8.Kubernetes里所有资源对象都可以采用yaml或者json格式文件来定义或描述

    1. apiVersion: v1
    2. kind: Pod        //表明这是一个Pod的定义
    3. metadata: 
    4.     name: myweb    //Pod的名称
    5.   labels:
    6.       name: myweb  //资源对象的标签
    7. spec:
    8.     containers:    //定义容器组
    9.   - name: myweb
    10.       image: kubeguide/tomcat-app:v1
    11.     ports:
    12.     - containerPort: 8080     //在8080端口启动容器
    13.     env:
    14.     - name:MYSQL_SERVICE_HOST
    15.         value: 'mysql'
    16.     - name: MYSQL_SERVICE_PORT
    17.         value: '3306'

    ①Pod的IP加上容器的端口，组成了一个新的概念——EndPoint，代表此Pod里的一个服务进程的对外通信地址。一个Pod也存在多个Endpoint的情况

    9.Event
    ①Event是一个事件的记录，记录了事件的最早产生时间、最后重现时间、重复次数、发起者、类型，以及导致此时间的原因等众多信息

    10.每个Pod都可以对其能使用的服务器上的计算资源设置限额，当前可以设置限额的计算资源有CPU和Memory两种
    ①通常一个容器的CPU配额被定义为100~300m，及占用0.1~0.3个CPU。由于CPU的配额是一个绝对值，所以无论在拥有一个Core的机器上，还是在拥有48个Core的机器上，100m这个配额所代表的CPU使用量都是一样的
    ②Memory配额也是一个绝对值，单位是内存字节数
    ③kubernetes里，一个计算资源进行配额限定时需要设定以下两个参数

    • Requests:该资源的最小申请量，系统必须满足要求
    • Limits:该资源最大允许使用量，不能被突破，当容器平时试图使用超过这个量的资源时，可能会被Kubernetes杀掉并重启
      spec: 
container:
- name: db
 image: mysql
resources:
   requests:
     memory: '64Mi'
   cpu: '250m'
 limits:
     memory: '128Mi'
   cpu: '500m'

    11.Label
    ①一个Label是一个key=value的键值对，其中key与Value由用户自己指定
    ②Label可以被附加到各种资源对象上，例如Node、Pod、Service、RC等
    ③一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上
    ④Label通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除
    ⑤给某个资源对象定义一个Label，就相当于给它打了一个标签，随后可以通过Label Selector查询和筛选拥有某些Label的资源对象

    12.Replication Controller
    ①定义了一个期望的场景，即声明某种Pod的副本数量在任意时刻都符合某个预期值

    • Pod期待的副本数量
    • 用于筛选目标Pod的Label Selector
    • 当Pod的副本数量小于预期数量时，用于创建新的Pod的Pod模板

    ②定义了一个RC提交到Kubernetes集群后，Master上的Controller Manager组件就得到通知，定期巡检系统当前存活的目标Pod,并确保目标Pod的数量刚好等于此RC的期望值，如果过多的Pod在运行，系统会停掉一些Pod，否者系统会创建一些Pod
    ③在运行时，可以通过修改RC的副本数量，来实现Pod的动态缩放，也可以通过执行kubectl scale命令来一键完成

    kubectl scale rc redis-slave --replicas=3

    ④RC的特性和作用：

    • 大多数情况下，定义一个RC实现Pod的创建及副本数量的自动控制
    • 在RC里包括完整的Pod定义模板
    • RC通过Label Selector机制实现对Pod副本的自动控制
    • 通过改变RC里的Pod副本数量，可以实现Pod的扩容和缩容
    • 通过改变RC里Pod模板中的镜像版本，可以实现Pod的滚动升级

    13.Deployment
    ①Deployment相对于RC的一个最大升级是我们可以随时知道当前Pod“部署”的进度。
    ②Deployment的典型使用场景有以下几个

    • 创建一个Deployment对象来生成对应的Replica Set并完成Pod副本创建
    • 检查Deployment的状态来看部署动作是否完成（Pod副本数量是否达到预期的值）
    • 更新Deployment以创建新的Pod（比如镜像升级）
    • 如果当前Deployment不稳定，则回滚到一个早先的Deployment版本
    • 暂停当前Deployment以便于一次性修改多个PodTemplateSpec的配置项，之后再恢复Deployment，进行新的发布
    • 扩展Deployment以应对高负载
    • 查看Deployment的状态，以此作为发布是否成功的指标
    • 清理不再需要的旧版本ReplicaSets

    14.Horizontal Pod Autoscaler
    ①HPA有两种方式作为Pod负载度量指标：

    • CPUUtilizationPercentage：一个算术平均值，即目标Pod所有副本自身的CPU利用率平均值。如果某一时刻CPUUtilizationPercentage的值超过80%，则意味着当前Pod副本数量很可能不足以支撑接下来更多的请求，需要进行动态扩容，而请求高峰时段过去后，Pod的CPU利用率又会降下来，此时对应的Pod副本数应该自动减少到一个合理的水平
    • 应用程序自定义的度量指标，比如服务在每秒内的相应请求数（TPS或QPS）

    15.StatefulSet
    ①Stateful里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。假设StatefulSet的名称为kafka，那么第一个Pod叫kafka-0,第二个叫kafka-1，以此类推
    ②StatefulSet控制的Pod副本的启停顺序是受控制的,操作第n个Pod时,前n-1个Pod已经是运行且准备好的状态
    ③StatefulSet里的Pod采用稳定持久化存储卷，通过PV或PVC来实现，删除Pod时默认不会删除与StatefulSet相关的存储卷（为了保证数据安全）

    16.Service
    ①Kubernetes里的每个Service其实就是我们经常提起的微服务架构中的一个微服务
    ②Service定义了一个服务访问入口地址，前端的应用Pod通过这个入口地址访问其背后的一组由Pod副本组织成的集群实例，Service与其后端Pod副本之间则是通过Label Selector来实现无缝对接的
    ③RC的作用是来保证Service的服务能力和服务质量始终符合预期标准