【k8s】核心概念篇

文章目录

- 应用部署方式演变
- 容器编排问题
- k8s简介
- k8s组件
- - master节点
  - node节点
  - 附加组件
  - 组件之间调用流
- 架构图
- 核心概念
- - 服务的分类(无状态&有状态)
  - 专业术语

应用部署方式演变

在部署应用程序的方式上，主要经历了三个时代：传统部署 -> 虚拟化部署 -> 容器化部署

传统部署：互联网早期，会直接将应用程序部署在物理机上

优点：简单，不需要其它技术的参与

缺点：不能为应用程序定义资源使用边界，很难合理地分配计算资源，而且程序之间容易产生影响
虚拟化部署：可以在一台物理机上运行多个虚拟机，每个虚拟机都是独立的一个环境

优点：程序环境不会相互产生影响，提供了一定程度的安全性

缺点：增加了操作系统，浪费了部分资源
容器化部署：与虚拟化类似，但是共享了操作系统

优点：

可以保证每个容器拥有自己的文件系统、CPU、内存、进程空间等

运行应用程序所需要的资源都被容器包装，并和底层基础架构解耦

容器化的应用程序可以跨云服务商、跨Linux操作系统发行版进行部署

容器编排问题

一个容器故障停机了，怎么样让另外一个容器立刻启动去替补停机的容器

当并发访问量变大的时候，怎么样做到横向扩展容器数量

Swarm：Docker自己的容器编排工具，适合中小型项目
Mesos：Apache的一个资源统一管控的工具，需要和Marathon结合使用，早于docker，支持5w+节点的控制
Kubernetes：Google开源的的容器编排工具

k8s简介

kubernetes，是一个全新的基于容器技术的分布式架构领先方案，是谷歌严格保密十几年的秘密武器----Borg系统的一个开源版本，于2014年9月发布第一个版本，2015年7月发布第一个正式版本。

kubernetes的本质是一组服务器集群，它可以在集群的每个节点上运行特定的程序，来对节点中的容器进行管理。目的是实现资源管理的自动化，主要提供了如下的主要功能：

自我修复：一旦某一个容器崩溃，能够在1秒中左右迅速启动新的容器
弹性伸缩：可以根据需要，自动对集群中正在运行的容器数量进行调整
服务发现：服务可以通过自动发现的形式找到它所依赖的服务
负载均衡：如果一个服务起动了多个容器，能够自动实现请求的负载均衡
版本回退：如果发现新发布的程序版本有问题，可以立即回退到原来的版本
存储编排：可以根据容器自身的需求自动创建存储卷

k8s组件

master节点

集群的控制平面，负责集群的决策(管理)。

ApiServer : 资源操作的唯一入口，接收用户输入的命令，提供认证、授权、API注册和发现等机制
Scheduler : 负责集群资源调度，按照预定的调度策略将Pod调度到相应的node节点上
ControllerManager : 负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等
Etcd ：负责存储集群中各种资源对象的信息

node节点

集群的数据平面，负责为容器提供运行环境(干活的)

Kubelet : 负责维护容器的生命周期，即通过控制docker，来创建、更新、销毁容器
KubeProxy : 负责提供集群内部的服务发现和负载均衡
Docker : 负责节点上容器的各种操作

附加组件

kube-dns：负责为整个集群提供 DNS 服务
Ingress Controller：为服务提供外网入口
Prometheus：提供资源监控
Dashboard：提供 GUI
Federation：提供跨可用区的集群
Fluentd-elasticsearch：提供集群日志采集、存储与查询

组件之间调用流

以部署一台nginx为例进行说明

首先明确一点：一旦k8s启动之后，master和node都会将自身的数据存储在etcd数据库中
一个nginx服务的安装请求，首先会被发送到master节点的apiserver组件上
apiserver组件调用scheduler组件去决定到底将服务安装在哪个node节点上

在此时，它会从etcd中读取node节点的信息，然后按照一定的算法进行选择，并将结果告知apiserver)
apiserver调用controller-manager去调度node节点安装nginx服务
kubelet接收到指令之后，会通知docker，然后由docker来启动nginx的pod

pod：k8s的最小操作单元，容器必须跑在pod中
到这里，一个nginx服务就运行成功了

架构图

核心概念

服务的分类(无状态&有状态)

无状态 -> 不依赖本地服务器环境
- 代表服务：nginx、Apache
- 优点：对客户端透明，无依赖关系，可以高效实现扩容、迁移
- 缺点：不能存储数据，需要额外的数据服务支撑
有状态 -> 依赖本地服务器环境，需要数据迁移
- 代表服务：MySQL、Redis
- 优点：可以独立存储数据，实现数据管理
- 缺点：集群环境下需要实现主从、数据同步、备份、水平扩容复杂

专业术语

资源和对象：资源是通过资源清单配置的；资源约等于类
对象规约与状态：状态(status)属性由 k8s 自己维护，k8s 会通过一系列的控制器对对应对象进行管理，让对象尽可能的让实际状态与期望状态(spec)重合。
资源分类：集群级资源 -> 命名空间级资源 -> 元数据级资源
- 元数据类型：Horizontal Pod Autoscaler（HPA）、PodTemplate、LimitRange
  
  Horizontal Pod Autoscaler（HPA）:Pod 自动扩容：可以根据 CPU 使用率或自定义指标（metrics）自动对 Pod 进行扩/缩容。
  
  Pod Template 是关于 Pod 的定义，但是被包含在其他的 Kubernetes 对象中（例如 Deployment、StatefulSet、DaemonSet 等控制器）。控制器通过 Pod Template 信息来创建 Pod。
  
  LimitRange：可以对集群内 Request 和 Limits 的配置做一个全局的统一的限制，相当于批量设置了某一个范围内（某个命名空间）的 Pod 的资源使用限制。
- 集群级别：Namespace命名空间、Node节点资源、ClusterRoles声明权限组、ClusterRoleBinding对集群级别进行绑定
- 命名空间：
  - 工作负载Pod
    
    Pod（容器组）是 Kubernetes 中最小的可部署单元。一个 Pod（容器组）包含了一个应用程序容器（某些情况下是多个容器）、存储资源、一个唯一的网络 IP 地址、以及一些确定容器该如何运行的选项。Pod 容器组代表了 Kubernetes 中一个独立的应用程序运行实例，该实例可能由单个容器或者几个紧耦合在一起的容器组成。
    
    一个 Pod 中只运行一个容器。“one-container-per-pod” 是 Kubernetes 中最常见的使用方式。此时，您可以认为 Pod 容器组是该容器的 wrapper，Kubernetes 通过 Pod 管理容器，而不是直接管理容器。
    - 副本(replicas)
      
      先引入“副本”的概念——一个 Pod 可以被复制成多份，每一份可被称之为一个“副本”，这些“副本”除了一些描述性的信息（Pod 的名字、uid 等）不一样以外，其它信息都是一样的，譬如 Pod 内部的容器、容器数量、容器里面运行的应用等的这些信息都是一样的，这些副本提供同样的功能。
      
      Pod 的***“控制器”***通常包含一个名为 “replicas” 的属性。“replicas”属性则指定了特定 Pod 的副本的数量，当当前集群中该 Pod 的数量与该属性指定的值不一致时，k8s 会采取一些策略去使得当前状态满足配置的要求。
    - 控制器
      
      当 Pod 被创建出来，Pod 会被调度到集群中的节点上运行，Pod 会在该节点上一直保持运行状态，直到进程终止、Pod 对象被删除、Pod 因节点资源不足而被驱逐或者节点失效为止。Pod 并不会自愈，当节点失效，或者调度 Pod 的这一操作失败了，Pod 就该被删除。如此，单单用 Pod 来部署应用，是不稳定不安全的。
      
      Kubernetes 使用更高级的资源对象 “控制器” 来实现对Pod的管理。控制器可以为您创建和管理多个 Pod，管理副本和上线，并在集群范围内提供自修复能力。例如，如果一个节点失败，控制器可以在不同的节点上调度一样的替身来自动替换 Pod。
      - 适用无状态服务
        
        ReplicationController（RC）
        
        RC 可以保证在任意时间运行 Pod 的副本数量，能够保证 Pod 总是可用的。如果实际 Pod 数量比指定的多那就结束掉多余的，如果实际数量比指定的少就新启动一些Pod，当 Pod 失败、被删除或者挂掉后，RC 都会去自动创建新的 Pod 来保证副本数量，所以即使只有一个 Pod，我们也应该使用 RC 来管理我们的 Pod。可以说，通过 ReplicationController，Kubernetes 实现了 Pod 的高可用性。
        
        已被RS替换~~
        
        ReplicaSet（RS）：只支持扩容、缩容
        
        label （标签）是附加到 Kubernetes 对象（比如 Pods）上的键值对，用于区分对象（比如Pod、Service）。 label 旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。 label 可以用于组织和选择对象的子集。label 可以在创建时附加到对象，随后可以随时添加和修改。可以像 namespace 一样，使用 label 来获取某类对象，但 label 可以与 selector 一起配合使用，用表达式对条件加以限制，实现更精确、更灵活的资源查找。
        
        label 与 selector 配合，可以实现对象的“关联”，“Pod 控制器” 与 Pod 是相关联的 —— “Pod 控制器”依赖于 Pod，可以给 Pod 设置 label，然后给“控制器”设置对应的 selector，这就实现了对象的关联。
        
        Deployment：对RS做了进一步封装
        
        Deployment controller 就会帮你将 Pod 和 Replica Set 的实际状态改变到你的目标状态。你可以定义一个全新的 Deployment，也可以创建一个新的替换旧的 Deployment。
        
        创建 Replica Set / Pod
        
        滚动升级/回滚 -> 升级后的RS1会保留着，用于回滚
        
        平滑扩容和缩容
        
        暂停与恢复 Deployment
        
        升级回滚，是自动的 -> 可以利用暂停与恢复
      - StatefulSet：适用于有状态服务
        
        StatefulSet 中每个 Pod 的 DNS 格式为 statefulSetName-{0…N-1}.serviceName.namespace.svc.cluster.local
        
        serviceName 为 Headless Service 的名字
        
        0…N-1 为 Pod 所在的序号，从 0 开始到 N-1
        
        statefulSetName 为 StatefulSet 的名字
        
        namespace 为服务所在的 namespace，Headless Servic 和 StatefulSet 必须在相同的 namespace
        
        .cluster.local 为 Cluster Domain
        
        特点
        
        稳定的持久化存储
        
        稳定的网络标志
        
        有序部署，有序扩展
        
        有序收缩，有序删除
        
        组成
        
        Headless Service
        
        用于定义网络标志（DNS domain）
        
        Domain Name Server：域名服务，将域名与 ip 绑定映射关系
        
        服务名 => 访问路径（域名） => ip
        
        volumeClaimTemplate
        
        用于创建 PersistentVolumes
      - DaemonSet 守护进程
        
        DaemonSet 保证在每个 Node 上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括：
        
        日志收集，比如 fluentd，logstash 等
        
        系统监控，比如 Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond 等
        
        系统程序，比如 kube-proxy, kube-dns, glusterd, ceph 等
      - 任务/定时任务
        
        JOB
        
        一次性任务，运行完成后Pod销毁，不再重新启动新容器。
        
        CronJob
        
        CronJob 是在 Job 基础上加上了定时功能。
  - 服务发现
    - Service(集群内部通信，横向流量(东西流量))
      
      “Service” 简写 “svc”。Pod 不能直接提供给外网访问，而是应该使用 service。Service 就是把 Pod 暴露出来提供服务，Service 才是真正的“服务”，它的中文名就叫“服务”。
      
      可以说 Service 是一个应用服务的抽象，定义了 Pod 逻辑集合和访问这个 Pod 集合的策略。Service 代理 Pod 集合，对外表现为一个访问入口，访问该入口的请求将经过负载均衡，转发到后端 Pod 中的容器。
    - Ingress(纵向流量(南北流量))
      
      Ingress 可以提供外网访问 Service 的能力。可以把某个请求地址映射、路由到特定的 service。
      
      ingress 需要配合 ingress controller 一起使用才能发挥作用，ingress 只是相当于路由规则的集合而已，真正实现路由功能的，是 Ingress Controller，ingress controller 和其它 k8s 组件一样，也是在 Pod 中运行。
  - 存储
    - Volume
      
      数据卷，共享 Pod 中容器使用的数据。用来放持久化的数据，比如数据库数据。
    - CSI
      
      Container Storage Interface 是由来自 Kubernetes、Mesos、Docker 等社区成员联合制定的一个行业标准接口规范，旨在将任意存储系统暴露给容器化应用程序。
      
      CSI 规范定义了存储提供商实现 CSI 兼容的 Volume Plugin 的最小操作集和部署建议。CSI 规范的主要焦点是声明 Volume Plugin 必须实现的接口。
  - 特殊类型配置
    - ConfigMap
      
      用来放配置，与 Secret 是类似的，只是 ConfigMap 放的是明文的数据，Secret 是密文存放。
    - Secret
      Secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec 中。Secret 可以以 Volume 或者环境变量的方式使用。
      
      Secret 有三种类型：
      
      Service Account：用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中；
      
      Opaque：base64 编码格式的 Secret，用来存储密码、密钥等；
      
      kubernetes.io/dockerconfigjson：用来存储私有 docker registry 的认证信息。
    - DownwardAPI(将pod的信息共享搭配容器内)
      
      downwardAPI 这个模式和其他模式不一样的地方在于它不是为了存放容器的数据也不是用来进行容器和宿主机的数据交换的，而是让 pod 里的容器能够直接获取到这个 pod 对象本身的一些信息。
      
      downwardAPI 提供了两种方式用于将 pod 的信息注入到容器内部：
      
      环境变量：用于单个变量，可以将 pod 信息和容器信息直接注入容器内部
      
      volume 挂载：将 pod 信息生成为文件，直接挂载到容器内部中去
  - 权限
    - Role
      
      Role 是一组权限的集合，例如 Role 可以包含列出 Pod 权限及列出 Deployment 权限，Role 用于给某个 Namespace 中的资源进行鉴权。
    - RoleBinding
      
      RoleBinding ：将 Subject 绑定到 Role，RoleBinding 使规则在命名空间内生效。文章来源地址https://uudwc.com/A/4rnDW