3.2.1 K8S核心概念及名词讲解(kubernetes 前言篇)

目录

1、Docker 容器的优势

2、使用 Docker 时有哪些限制

3、为什么需要kubernetes

4、kubernetes的用途

5、kubernetes核心概念

    5.1、kubernetes对象都有两个关键字段

    5.2、kubernetes集群的两种角色

        5.2.1、Master

        5.2.2、Node

5.3、Pod

        5.3.1、Pod的特殊组成结构

        5.3.2、Pod的两种类型

5.4、Label（标签）

5.5、Replication Controller(RC)

5.6、Deployment

5.7、StatefulSet(状态集)

5.8、Service(服务)

5.9、Volume(存储卷)

5.10、Namespace

5.11、Annotation(注解)

5.12、Kubelet

5.13、kubectl

6、kubernetes术语

6.1、k8s核心概念

---

视频中老师打开的文档路径：E:\meWork\study\project\subject-3\subject-3-k8s\专题三-Kubernetes_学习文档-N.docx

1、Docker 容器的优势

模块化、层和镜像版本控制、回滚、快速部署

2、使用 Docker 时有哪些限制

Docker 本身非常适合管理单个容器。但随着您开始使用越来越多的容器和容器化应用程序，并把它们划分成数百个部分，很可能会导致管理和编排变得非常困难。最终，您需要后退一步，对容器实施分组，以便跨所有容器提供网络、安全、遥测等服务。于是，Kubernetes 应运而生。

3、为什么需要kubernetes

Kubernetes：又称为k8s,或简称为kube
k8s：首字母为k,首字母与尾字母之间有8个字符、尾字母为s,所以简称k8s

        由于真实的生产型应用会涉及多个容器。这些容器必须跨多个服务器主机进行部署。
提供了一个便捷有效的平台，在物理机和虚拟机集群上调度、运行容器，可以将许多相同任务交给容器来执行。
            Kubernetes还提供了与联网、存储、安全性、遥测，等其他服务集成整合，来提供全面的容器基础架构。

4、kubernetes的用途

        1、跨多台主机进行容器编排
        2、更加充分地利用硬件，最大程度获取运行企业应用所需的资源
        3、有效管控应用部署和更新，并实现自动化操作
        4、挂载和增加存储，用于运行有状态的应用
        5、快速、按需扩展容器化应用及其资源
        6、对服务进行声明式管理，保证所部署的应用始终按照部署的方式运行
        7、利用自动布局、自动重启、自动复制、自动扩展功能，对应用实施状况检查、自我修复。
    但是Kubernetes需要依赖其他项目来全面提供这些经过编排的服务，这些功能、项目如下：
              功能   ：    项目
        1、注册表：Atomic注册表、Docker注册表
        2、联网：OpenSwitch和智能边缘路由
        3、遥测：heapster、kibana、hawkular、elastic
        4、安全性：LDAP、SELinux、RBAC、OAUTH等项目，以及多租户层来实现
        5、自动化：参照Ansible手册进行安装、集群生命周期管理
        6、服务：自带预建版的应用模式的内容目录来提供 

5、kubernetes核心概念

        Kubernetes由各种资源对象来描述整个集群的运行状态。
        可以看作资源对象的有：Node、Pod、Replication Controller、Service
        这些对象都需要通过调用Kubernetes api来进行创建、修改、删除，并保存在etcd库。

    5.1、kubernetes对象都有两个关键字段

        每个kubernetes对象都有两个关键字段：
            Object Spec：描述对象所期望达到的状态
            Object Status：描述该对象的实际状态

    5.2、kubernetes集群的两种角色

        5.2.1、Master

            master是集群的控制节点，通常会占据一个独立的服务器(如果要达到高可用部署：建议用3台服务器)。
            master是整个集群的“首脑”，如果它宕机或不可用，那么对集群内容器应用的管理都将失效。
            master也可以作为工作负载节点，但在企业中尽量将master只作为一个控制节点

master节点上运行的一组关键进程：
    kube-apiserver(Kubernetes API Server)：提供HTTP Rest接口的关键服务进程，是集群控制的入口进程
                                                                        是Kubernetes里所有资源的增、删、改、查等操作的唯一入口
    kube-controller-manager(Kubernetes Controller Manager)：Kubernetes里所有资源对象的“大总管”
    kube-scheduler(Kubernetes Scheduler)：负责资源调度的进程(Pod调度),相当于公交公司的“调度室”

另外，在master节点上需要启动一个etcd服务，来保存kubernetes里的所有资源对象。

        5.2.2、Node

除了Master，Kubernetes集群中的其他机器被称为Node节点，在较早的版本中也被称为Minion。
Node节点是Kubernetes集群的工作负载节点，每个Node都会被Master分配一下工作(Docker容器),当某个Node宕机时，其上的工作会被master自动转移到其他节点上去。

Node节点上运行的一组关键进程：
    kubelet：负责Pod对应的容器创建、启动、停止等任务，与master节点密切协作，实现集群管理的基本功能
    kube-proxy：实现Kubernetes Service的通信与负载均衡机制
    Docker Engine(Docker引擎)：负责本机的容器创建和管理工作
默认情况下kubelet会向master注册自己，一旦node被纳入集群管理范围，kubelet进尺就会定时向master汇报自身的情况。
汇报的内容如：操作系统、Docker版本、机器的CPU、内存情况、当前有哪些Pod在运行
当某个node超过指定时间不上报信息时，会被master判断为“失联”，node的状态被标记为不可用(Not Ready)，随后master会触发“负载大转移”的自动流程。

5.3、Pod

Pod是Kubernetes最重要、最基本的概念，每个Pod都有一个特殊的Pause容器(根容器)，每个Pod还包含一个或多个紧密相关的用户业务容器(User container)

Pause容器：保证Pod的健康

用户业务容器：真实的docker容器

        5.3.1、Pod的特殊组成结构

            1、在一组容器作为一个单元时，需要一个与业务无关、不容易死亡的容器(Pause容器)，用这个容器的状态代表整组容器的状态。
            2、Pod里的多个业务容器：共享Pause容器的IP、共享Pause容器挂接的Volume(数据卷)
                这样就简化了业务容器之间的通信、文件共享的问题。
        在Kubernetes中，一个Pod里的容器与另外主机上的Pod能够直接通信，这是采用虚拟网络层技术实现的(eg：Flannel、OpenSwitch等)

        5.3.2、Pod的两种类型

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

Pod、容器与Node的关系图如下图：

5.4、Label（标签）

一些常用等label示例如下：

版本标签："release" : "stable"

                 "release" : "canary"

环境标签："environment" : "dev"

                 "environment" : "production"

dev就是development(开发)
pro就是production(生产)

架构标签："tier" : "frontend"

                 "tier" : "backend"

                 "tier" : "middleware"

分区标签："partition" : "customerA"

                 "partition" : "customerB"

质量管控标签："track" : "daily"

                        "track" : "weekly"

5.5、Replication Controller(RC)

    RC也是kubernetes系统中的核心概念之一
    RC是定义一个期望的场景，声明某种Pod的副本数量在任意时刻都符合某个预期值。
    RC定义的3个部分：
        1、Pod期待的副本数(replicas)；
        2、用于筛选目标Pod的Label Selector；
        3、当Pod的副本数量小于预期数量时，用于创建新Pod的Pod模板(template)。

5.6、Deployment

    是kubernetes v1.2引入的概念，目的是为了更好的解决Pod的编排问题。Deployment内部使用Replica Set实现。
    Deployment可以看作RC的一次升级，两者的相似度超过90%。
    Deployment相对于RC的一个最大升级是我们随时知道当前Pod“部署”的进度。实际上由于一个Pod的创建、调度、绑定节点及在目标Node上启动对应的容器这一完整过程需要一定的时间，所以我们期待系统启动N个Pod副本的目标状态，实际上是一个连续变化的“部署过程”导致的最终状态。
Deployment的使用场景：
    1、创建一个Deplyment对象来生成对应的Replica Set，并完成Pod副本的创建过程。
    2、检查Deployment的状态来看部署动作是否完成(Pod副本的数量是否达到预期的值)。
    3、更新Deployment以创建新的Pod(eg：镜像升级)。
    4、如果当前Deployment不稳定，则回滚到一个早先的Deployment版本。
    5、暂停Deployment，以便于一次性修改多个PodTemplateSpec 的配置项，之后再恢复Deployment，进行新的发布。
    6、扩展Deployment以应对高负载。
    7、查看Deployment的状态，以此作为发布是否成功的指标。
    8、清理不再需要的旧版本ReplicaSets。

5.7、StatefulSet(状态集)

    Pod的管理对象都是无状态的服务。(RC、Deployment、DaemonSet、Job)
    MySQL集群、MongoDB集群、Kafka集群、Zookeepere集群，有如下4个共同点：
        1、每个节点都有固定的身份ID,集群中的成员通过这个ID相互发现、通信
        2、集群的规模是比较固定的，集群规模不能随意变动
        3、集群里的每个节点都是有状态的，通常会持久化数据到永久存储中
        4、如果磁盘损坏，则集群里的某个节点无法正常运行，集群功能受损
        StatefulSet是集群中Pod挂接的某种共享存储，为了在其他节点上恢复某个失败的节点时使用
    Kubernetes从v1.4版本开始引入PetSet这个新的资源对象，在v1.5版本更名为StatefulSet。
    StatefulSet：可以看作Deployment/RC的一个特殊变种，它有如下3个特性：
        1、StatefulSet里的每个Pod都有稳定、唯一的网络标识，用来与集群内其他成员发现、通信
            假设StatefulSet的名字叫kafka，那么第一个Pod叫kafka-0，第二个Pod叫kafka-1......以此类推
        2、StatefulSet控制Pod副本的启动、停止顺序
            操作第n个Pod时，前n-1个Pod已经是运行且准备好的状态
        3、StatefulSet里的Pod采用稳定的持久化存储卷
            通过PV/PVC来实现，删除Pod时，默认不会删除与StatefulSet相关的存储卷(为了保证数据的安全)
    在每个StatefulSet的定义中要声明它属于哪个Headless Service。
    Headless Service与普通Service的关键区别在于，它没有Cluster IP。
    StatefulSet在Headless Service的基础上又为StatefulSet控制的每个Pod实例创建了一个DNS域名，这个域名的格式为：
$(podname).$(headless service name)
eg：一个3节点的Kafka的StatefulSet集群，对应的Headless Service的名字为kafka，StatefulSet的名字为kafka，则StatefulSet里面的3个Pod的DNS名称分别为kafka-0.kafka、kafka-1.kafka、kafka-2.kafka，这些DNS名称可以直接在集群的配置文件中固定下来

5.8、Service(服务)

    Service也是Kubernetes里最核心的资源对象之一。
    Service其实就是我们说的微服务架构中的一个“微服务”。
    Pod、RC、Service的逻辑关系如下图：

5.9、Volume(存储卷)

    与docker的Volume比较类似，但不等价。
    Volume是Pod中能够被多个容器访问的共享目录。
    Kubernetes支持多种类型的Volume，eg：Gluster、Ceph

5.10、Namespace

    Namespace(命名空间)：用于实现多租户的资源隔离
                            通过将集群内部的资源对象“分配”到不同的Namespace中，形成逻辑上的分组，便于不同分组在共享使用集群资源的同时，还能被分别管理。

5.11、Annotation(注解)

    与Label类似，也使用key/value键值对的形式进行定义。
    只是Annotation可以用户任意命名。
    用Annotation记录的信息如下：
        1、build信息、release信息、Docker镜像信息等
            eg：时间戳、release id号、PR号、镜像hash值、docker registry地址
        2、日志库、监控库、分析库、等资源库的地址信息
        3、程序调试工具信息
            eg：工具、版本号
        4、团队等联系信息
            eg：电话号码、负责人名称、网址

5.12、Kubelet

    运行在节点上的服务，可读取容器清单(container manifest)，确保指定的容器启动并运行。

5.13、kubectl

    Kubernetes 的命令行配置工具

在Kubernetes系统中还有许多辅助配置的资源对象，eg：LimitRange、Resurce。另外，一些系统内部使用的对象Binding、Event等请参考Kubernetes的API文档。

6、kubernetes术语

官方把 kubernetes 术语分为 12 个分类：系统结构、社区、核心对象、扩展、基础、网络、操作、安全、存储、工具、用户类型、工作负载

想要了解更多 kubernetes 术语，请参照官方术语表，地址：https://kubernetes.io/docs/reference/glossary/?fundamental=true

常用的术语有(这里列了23个)：Pods、Labels、Namespace、Replication Controller、Node、ReplicaSets、Services、
Volumes、PV/PVC/StorageClass、Deployment、Secret、StatefulSet、DaemonSet、ervice Account、CronJob、
Job、Security Context 和 PSP、Resource Quotas、Network Policy、Ingress、ThirdPartyResources、ConfigMap、
PodPreset。
Replication Controller的一次升级是ReplicaSets，ReplicaSets的一次升级是Deployment

6.1、k8s核心概念