1.k8s：架构，组件，基础概念

目录

一、k8s了解

1.什么是k8s

2.为什么要k8s

（1）部署方式演变

（2）k8s作用

（3）Mesos，Swarm，K8S三大平台对比

二、k8s架构、组件

1.k8s架构

2.k8s基础组件

3.k8s附加组件

三、k8s基础概念

1.服务的分类

（1）无状态

（2）有状态

2.资源的分类

（1）元数据型

*1）Horizontal Pod Autoscaler（HPA）

*2）Pod Template

*3）LimitRange

（2）集群级

*1）Namespace

*2）Node

*3）ClusterRole

*4）ClusterRoleBinding

（3）命名空间级pod型资源

*1）适用于无状态服务的pod型资源

^1） 副本

^2）Replication Controller （RC）

^3）ReplicaSet（RS）

^4）Deployment controller

*2）适用于有状态服务的pod型资源（StatefulSet ）

^1） 主要特点

^2） Headless Service

^3）volumeClaimTemplate

^4）注意事项

*3）守护进程（DaemonSet）

*4）任务/定时任务

3.服务发现

（1）service

（2）Ingress

4.存储

（1）Volume

（2）CSI

5.特殊类型配置

（1）ConfigMap

（2）Secret

（3）DownwardAPI

（4）Role

（5）RoleBinding

6.规约（spec）

7.状态（Status）

四、感谢支持

---

前面我们有了解过一些k8s，但是那个版本比较老，因此会产生很多的bug和不兼容的问题以及依赖或者链接丢失的问题，我们用比较新的版本重头学一遍k8s。

一、k8s了解

1.什么是k8s

k8s是管理容器化应用的平台，且能够管理云平台多主机，能让我们容器化部署更高效更容易。

2.为什么要k8s

（1）部署方式演变

传统服务：

环境不隔离，并发修改，内存、cpu、带宽资源争抢

虚拟化部署：

虚拟机占用过多，扩展也不大好扩展

容器化部署：

大大缩短容器生命周期

（2）k8s作用

当容器生命周期大大缩短之后，ip、数据可能就会不稳定就需要k8s去管理他们：

• 自我监控，自我修复
• 弹性伸缩
• 自动部署和回滚
• 服务发现、负载均衡
• 配置管理
• 存储编排：存储资源抽象成虚拟磁盘，然后虚拟磁盘映射物理磁盘
• 批处理

（3）Mesos，Swarm，K8S三大平台对比

Mesos：

主要用于资源管理，发布最早，能管理5W+机器。主要面向节点，而非面向容器。

Docker Swarm：

docker官方都不用了，无缝集成docker，用于节点不多，简单的业务场景。

k8s：

复杂容器管理。

二、k8s架构、组件

1.k8s架构

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

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

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

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

• Kubelet : 负责维护容器的生命周期，即通过控制docker，来创建、更新、销毁容器
• KubeProxy : 负责提供集群内部的服务发现和负载均衡
• Container runtime：负责镜像管理以及 Pod 和容器的真正运行

下面，以部署一个nginx服务来说明kubernetes系统各个组件调用关系：

1. 首先要明确，一旦kubernetes环境启动之后，master和node都会将自身的信息存储到etcd数据库中
2. 一个nginx服务的安装请求会首先被发送到master节点的apiServer组件
3. apiServer组件会调用scheduler组件来决定到底应该把这个服务安装到哪个node节点上
4. 在此时，它会从etcd中读取各个node节点的信息，然后按照一定的算法进行选择，并将结果告知apiServer
5. apiServer调用controller-manager去调度Node节点安装nginx服务
6. kubelet接收到指令后，会通知docker，然后由docker来启动一个nginx的pod
7. pod是kubernetes的最小操作单元，容器必须跑在pod中
8. 至此，一个nginx服务就运行了，如果需要访问nginx，就需要通过kube-proxy来对pod产生访问的代理
9. 这样，外界用户就可以访问集群中的nginx服务了

2.k8s基础组件

• Master：集群控制节点，每个集群需要至少一个master节点负责集群的管控
• Node：工作负载节点，由master分配容器到这些node工作节点上，然后node节点上的docker负责容器的运行
• Pod：kubernetes的最小控制单元，容器都是运行在pod中的，一个pod中可以有1个或者多个容器
• Controller：控制器，通过它来实现对pod的管理，比如启动pod、停止pod、伸缩pod的数量等等
• Service：pod对外服务的统一入口，下面可以维护者同一类的多个pod
• Label：标签，用于对pod进行分类，同一类pod会拥有相同的标签
• NameSpace：命名空间，用来隔离pod的运行环境

3.k8s附加组件

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

三、k8s基础概念

1.服务的分类

（1）无状态

代表应用：Nginx、Apache

优点：对客户端透明，无依赖关系，可以高效实现扩容、迁移

缺点：不能存储数据，需要额外的数据服务支撑

（2）有状态

代表应用：MySQL、Redis

优点：可以独立存储数据，实现数据管理

缺点：集群环境下需要实现主从、数据同步、备份、水平扩容复杂

2.资源的分类

（1）元数据型

*1）Horizontal Pod Autoscaler（HPA）

用于Pod 自动扩容：可以根据 CPU 使用率或自定义指标（metrics）自动对 Pod 进行扩/缩容

• 每隔30s查询metrics的资源使用情况
• 支持的metrics：预定义metrics、自定义的Pod metrics、自定义的object metrics
• metrics查询方式：Heapster、自定义的REST API

*2）Pod Template

控制器通过 Pod Template 信息来创建 Pod。

*3）LimitRange

批量设置了某一个范围内（某个命名空间）的 Pod 的资源使用限制

（2）集群级

*1）Namespace

用于实现多团队/环境的资源隔离。

*2）Node

Node 本质上不是Kubernetes 来创建的，Kubernetes 只是管理 Node 上的资源。

*3）ClusterRole

ClusterRole 是一组权限的集合，可以进行鉴权。

*4）ClusterRoleBinding

将 Subject 绑定到 ClusterRole、使规则在所有命名空间中生效。

（3）命名空间级pod型资源

*1）适用于无状态服务的pod型资源

^1） 副本

一个 Pod 可以被复制成多份，每一份可被称之为一个副本

^2）Replication Controller （RC）

RC 可以保证在任意时间运行的 Pod 的副本数量总是可用的，它实现了 Pod 的高可用性。

^3）ReplicaSet（RS）

RS主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数。

注：​Kubernetes 官方建议使用 RS替代 RC进行部署

^4）Deployment controller

Deployment 为 Pod 和 RS 提供声明式更新，你只需要在 Deployment 中描述你想要的目标状态是什么，Deployment controller 就会帮你将 Pod 和 Replica Set 的实际状态改变到你的目标状态。

Deployment controller可以用来创建 Replica Set / Pod

*2）适用于有状态服务的pod型资源（StatefulSet ）

^1） 主要特点

• 稳定的持久化存储

• 稳定的网络标志

• 有序部署，有序扩展。有序收缩，有序删除

^2） Headless Service

用于定义网络标志（DNS domain）。

Domain Name Server：域名服务，将域名与 ip 绑定映射关系
 

^3）volumeClaimTemplate

用于创建 PersistentVolumes

^4）注意事项

• 有状态的pod型，kubernetes v1.5 版本以上才支持

• 所有Pod的Volume必须使用PersistentVolume或者是管理员事先创建好

• 为了保证数据安全，删除StatefulSet时不会删除Volume

• StatefulSet 需要一个 Headless Service 来定义 DNS domain，需要在 StatefulSet 之前创建好

*3）守护进程（DaemonSet）

DaemonSet 保证会在每个 Node 上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用

*4）任务/定时任务

有一次性任务和定时任务。

3.服务发现

（1）service

Pod 不能直接提供给外网访问，而是应该使用 service。Service 就是把 Pod 暴露出来提供服务

（2）Ingress

Ingress 可以提供外网访问 Service 的能力。可以把某个请求地址映射、路由到特定的 service。

ingress 需要配合 ingress controller 一起使用才能发挥作用，ingress 只是相当于路由规则的集合而已，真正实现路由功能的，是 Ingress Controller，ingress controller 和其它 k8s 组件一样，也是在 Pod 中运行。

4.存储

（1）Volume

数据卷，共享 Pod 中容器使用的数据。用来放持久化的数据，比如数据库数据。

（2）CSI

CSI 规范定义了存储提供商实现 CSI 兼容的 Volume Plugin 的最小操作集和部署建议，是一种规范

5.特殊类型配置

（1）ConfigMap

用来放配置， ConfigMap 放的是明文的数据

（2）Secret

用来放配置， Secret放的是密文的数据

（3）DownwardAPI

让 pod 里的容器能够直接获取到这个 pod 对象本身的一些信息。

（4）Role

Role 是一组权限的集合

（5）RoleBinding

Subject 绑定到 Role，RoleBinding 使规则在命名空间内生效。

6.规约（spec）

描述了对象的期望状态（Desired State）—— 希望对象所具有的特征。当创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态，以及关于对象的一些基本信息

7.状态（Status）

k8s 会通过一系列的控制器对对应对象进行管理，让对象尽可能的让实际状态与期望状态重合。

四、感谢支持

感谢各位大佬支持，如果觉得满意可以请喝一杯咖啡吗：