K8S基本架构设计&专业术语

基本的架构设计

下面是一个简单的单Master的集群架构图，我们从这一张图作为切入点来进行学习

一个kubernetes集群主要是由控制节点（master）+ 工作节点（node）构成，每个节点上都会安装不同的组件

控制节点（master）

master节点作为Kubenetes中的控制节点，他主要的作用是负责集群的管理，根据上面的架构图，我们发现master节点中主要包含一下几个组件

ApiServer

作为K8S中资源对象的唯一操作入口，其他所有的组件都必须通过它提供的API来操作资源数据 API Server 内部有一套完备的安全机制，包括认证、授权、准入控制等实现资源数据的安全保证

Controller Manager

主要负责的就是集群内部应用的部署、状态监控、恢复的自动化工作

Scheduler

负责集群资源的调度，按照预定的调度策略将Pod调度分配到相应的工作节点node上

Etcd

  • 可以理解K8S的储存系统,负责存储集群中各种资源对象的信息,Api Server提供的接口就是用来操作Etcd中的数据

工作节点（node）

  • node节点又被称为工作节点，主要的作用为我们运行容器提供一个被K8S监控的环境，在node节点中主要包含以下几个组件

kube-proxy

  • 提供集群内部服务访问、对外暴露访问的网络代理,以及访问时的负载均衡

kubelet

  • 负责本Node节点上的Pod的创建、修改、监控、删除等全生命周期管理，同时Kubelet定时“上报”本Node的状态信息到API Server里。

  • 可以理解为，这就是master节点派来此node节点的使臣，用于实现master对本node节点上容器的全生命周期管理

container

  • 容器的运行时环境，这里我们仍然以docker做为典型，真名应该叫：container runtime

  • 环境运行容器,因为K8S的出现就是为了容器编排，而这里做为最底层的容器docker是可以被替代的

  • 比如：containerd、Podman、LXC/LXD、rkt、OpenVZ、 Singularity、CRI-O

  • 在K8S的官方也明确表示出在1.20开始放弃docker,原因是K8S编排docker的时候，需要桥接服务才能和docker通信，桥接服务也是由K8S维护的，目前市面上兼容了CRI接口的容器技术已经出现了很多，换掉维护成本高的docker也是理所当然

  • 但在目前的发展中，docker也在推动本身实现CRI，以至于不被诸多资源编排技术排斥

业务流程如下所示

  1. 编写kubenetes的资源清单文件，定义我们要创建的资源对象规格数据

  2. 通过kebectl apply 或者kubectl create 指定我们的资源清单文件，进行构建资源对象

  3. kubectl会将这个资源对象的构建请求发送给API Server , 然后写入到etcd中

  4. 此时Controller Manager通过 API Server暴露的资源变化端口感知到该资源对象创建事件

  5. 然后获取K8S的资源列表发现没有该资源对象，于是根据资源清单文件定义了该资源，并通过API Server写入到了etcd中

  6. 然后该资源对象被scheduler检测到，进过调度分许，为这个资源对象选定了一个node节点作为运行环境并补充写入到etcd中

  7. 然后node节点上运行的kubelet组件通过API Server监听到该资源对象，并按照它的定义，创建了该资源并负责它的全生命周期

核心概念&专业术语

有状态服务

  • 会储存数据到本地，对本地数据产生依赖，比如MySQL、Redis等应用就会有数据管理的需求

无状态服务

  • 不会对本地环境产生任何依赖，随便在某个节点上都能运行，完全独立的个体，可以随时高效的进行扩容/迁移的服务，比如Nginx

Pod

  • 是K8S最小的部署单元，一个Pod内可以运行一个或者多个容器，一般情况下一个Pod运行一个容器

  • 每个Pod中都有一个pause容器, 该容器使得该Pod中的多个容器之间的网络、文件系统实现共享

replicas

  • 一个 Pod 可以被复制成多份，这些复制出来的Pod提供相同的功能

RC（Replication Controller）

  • Pod的控制器之一 ,适用于无状态服务的部署 , 后来被RS替代

  • 帮助我们动态的更新Pod的运行副本数到我们的预期副本数

RS（Replica Set）

  • Pod的控制器之一 , 适用于无状态服务的部署 , 后来被Deployment替代

  • 帮助我们动态的更新Pod的运行副本数到我们的预期副本数，和RC区别不大，只是支持了label和selector

  • label:附加到资源对象的标签

  • selector:匹配某类资源对象

  • RS通过selector来关联Pod的label,实现动态的更新关联pod的副本数

Deployment

  • Pod的控制器之一 , 适用于无状态服务的部署 , 目前部署无状态服务的推荐控制器

  • Deployment对RS做了更好的包装 , 包括但不限于:自动伸缩(RS) 、滚动升级&回滚 、 平滑伸缩 、 暂停与恢复

StatefulSet

  • Pod的控制器之一 , 适用于有状态服务的部署 , 目前部署有状态服务的推荐控制器

  • 【特点】基于PVC实现Pod即使重新调度后仍然能访问到之前相同的持久化数据 , 下面会细说PVC

  • 【特点】基于Headless Service使Pod重新调度后PodName和HostName也不会变化，拥有稳定的网络标志

  • 【特点】有序部署 、 有序扩展 , 即Pod是有顺序的，在部署或者扩展时依次进行，从0-N

  • 【特点】有序收缩 、 有序删除 , 即Pod是有顺序的，在部收缩或删除时依次进行，从N-

  • 【组成】headless Service

    • 用于定义网络标志（DNS domain）, DNS = Domain Name Server = 域名服务

    • 服务名 --> 域名 --> ip

  • 【组成】volumeClaimTemplate

    • 用于创建PersistentVolumes , 关于PersistentVolumes 简称PV，下面亦会和PV一起做详细说明

  • 【注意事项】Pod需要使用的Volumn必须使用PV或者管理员事先创建准备好

  • 【注意事项】为了保证数据安全 , 删除StatefulSet时不会删除Volume

  • 【注意事项】statefulSet需要一个headless Service来定义DNS domain , 需要在statefulSet创建之前准备好

DaemonSet

  • Pod的控制器之一 , 适用于部署每一个Node上都需要部署该容器的的环境

  • 典型的应用比如:

    • 日志收集: fluents 、 logstash ...

    • 系统监控: 普罗米修斯 ...

    • 系统程序: kube-proxy 、 kube-dns ...

Job

  • Pod的控制器之一 , 适用于一次性任务 , 运行完成后Pod销毁 ， 不会在重新启动容易;

CronJob

  • Pod的控制器之一 , 在Job的基础上加了定时的功能;

SVC（Service）

  • 服务发现组件之一 , 用于服务暴露 , 一般作用于K8S集群内部的服务暴露 , 东西流量的实现;

  • Pod不能直接提供给外网访问，而是应该使用Service做为该Pod对外暴露的代理;

  • Service对外表现为一个访问入口 , 从Service进来的请求会经过负载均衡转发到Pod中的容器里;

Ingress

  • 服务发现组件之一 , 用于服务暴露 , 一般作用于Service暴露给公网 , 南北流量的实现;

  • Ingress可以把某个请求地址映射 、 路由到特定的Service上 , Service再分发到Pod中的容器里;

  • Ingress只是相当于路由规则的集合，真正实现路由功能的是Ingress Controller;

Volume

  • 数据卷 , 用于存放需要持久化的数据 , 共享Pod中容器使用的数据 , 比如数据库的数据;

ConfigMap

  • 特殊类型配置实现之一 , 用于存放配置数据 , 明文储存;

Secret

  • 特殊类型配置实现之一 , 用于存放配置数据 , 密文储存

  • Secret避免了密码 、 Token 、密钥等敏感数据直接暴露在镜像的配置文件或者Pod的资源清单中

  • Secret可以以Volume或者环境变量的方式进行使用

  • Secret有三种类型

    • Service Account: 用来访问Kubernetes的API，由Kubernetes自动创建;

    • Opaque: base64编码格式的Secret , 用来存储密码、密钥等;

    • kubernetes.io/dockerconfigjson: 用来存储私有docker registry的认证信息;

DownwardAPI

  • downwardAPI这个模式和其他模式不一样的地方在于:

    • 它不是为了存放容器的数据 , 也不是用来进行容器和宿主机的数据交换的;

    • 而是让Pod里的容器能够直接获取到这个Pod对象本身的一些信息;

  • downwardAPI提供了两种方式用于将Pod的信息注入到容器内部:

    • 环境变量: 用于单个变量 , 可以将Pod信息和容器信息直接注入容器内部;

    • volume挂载: 将Pod信息生成为文件，直接挂载到容器内部中去;

Role

  • Role是一组权限的集合 , 列如可以包含列出Pod权限以及列出Deployment权限 , Role用于给某个Namespace中的资源进行鉴权

Role Binding

  • 将Subject绑定到Role , RoleBinding使规则在命名空间内生效

  •  
posted @ 2020-12-05 00:47  鞋破露脚尖儿  阅读(870)  评论(0)  编辑  收藏  举报