Kubernetes集群概述/体系结构/相关核心概念

共计 2845 个字符，预计需要花费 8 分钟才能阅读完成。

Kubernetes 是什么？

业界简称为：K8S，是首字母和末尾之母之间有 8 个字母，所以叫 K8S，不知为何这样起名？

1、它是一个全新的基于容器技术的分布式架构方案。Kubernetes 是谷歌严格保密十几年的秘密武器 —Borg 的一个开源版本，据说在 GG 员工都签署了保密协议，即使离职也不能泄露机密（业界大数据框架：Hadoop，也是受 GG 公开文献启发 GFS 和 BigTable）。

2、若我们的系统设计遵循 Kubernetes 的设计思想，可以说那些传统系统架构中和业务没有多大关系的底层代码或功能模块，可以消除，我们不必再为应用的负载均衡和部署等问题而烦恼

3、Kubernetes 是一个开放的开放平台。有 Google、RedHat 等开源基础设施的大碗们共同发起了一个为：CNCF(Cloud Native Computing Foundation) 的基金会。

4、Kubernetes 是一个完备的分布式系统支撑平台。

为什么要用 Kubernetes？

1、可以和微服务完美结构，构成微服务架构。

2、K8S 内的服务的弹性扩容机制可以应对突发流量

3、K8S 架构的灵活及超强的横向扩容能力可以提高我们的竞争力

4、基于容器技术，构建公司 DevOps、CI/CD、持续交付，缩短开发周期

Kuberntes 的体系架构

下图为 K8S 的体系架构

Kubernetes 的主要核心组件：

在上图中的左侧节点则是 Master 节点，右侧是 Node 节点：

Master 节点的主要作用是控制和管理整个集群的状态并接收外部用户的操作请求。它主要运行三中服务进程，分别是：kube-apiserver、kube-scheduler、kube-controller-manager, 具体作用如下：

kube-apiserver

kube-apiserver 是整个 Kubernetes 集群的核心，也是部署 Kubernetes 最先启动的组件，其他所有的组件都会在启动时接入这个服务，主要是提供资源操作的统一入口，通过 RestAPI 将集群的状态信息存储 etcd 集群。

kube-scheduler

主要负责资源的调度，根据集群当前的资源使用情况及复杂的调度算法将 Pod 调度到适合运行或特定的服务节点上。

kube-controller-manager

kube-controller-manager 服务负责管理 K8S 集群中各种资源的状态，诸如：故障检测、滚动更新等。

Node 节点是实际执行用户任务的地方，其上有两种服务进程，分别是：kube-proxy 和 kubelet，具体作用如下：

kube-proxy

设计 kube-proxy 服务是为了解决从 Node 节点中的 Pod 对 K8S 特定 Service 访问时的路由问题，每当 K8S 创建一个 Service 的 Endpoint，各个 Node 节点上的 kube-proxy 进程就会修改节点系统的 iptables 规则，使得当该节点上的 Pod 访问相应 Endpoint 的虚拟 Ip 和端口时，请求会被分发到正确的节点和容器进行处理

kubelet

kubelet 直接负责节点上容器的生命周期，同时也负责 Volume 和网络（CNI）的管理

其他的核心组件：

etcd：保存集群的状态，整个集群的状态数据都存于此，因此构建 K8S 集群时，etcd 也最好是集群的，同时要对 etcd 的数据进行备份

Heapster：提供资源监控

kube-dns：负责为整个集群提供 DNS 服务

Kuberntes 核心概念

在 Kubernetes 集群中，服务器的角色分为 Master 和 Node, 此两种不同角色分别运行着不同的服务进程。

Pod

Pod 表示的是一个或多个容器的组合，它是 K8S 最基本的调度和操作单位，每个 Pod 里都有一个特殊的容器，被称为：”根容器“的 pause 容器。

在同一个 Pod 中的容器总会被调度和部署到同一个节点上，并共享相同的数据卷和网络栈，也即是 Pod 里的多个容器能够同时挂载同一个外部数据卷，这对于部署紧密的服务是十分有作用的。

Label

Labe（标签）其实是一个 K - V 的键值对形式，用于标记 Pod、Node、Namespace 或其他任何资源对象的键值对。主要用于在查询或选择时对资源进行条件过滤。

Service

Service 是 Kubernetes 集群对外提供的用户业务功能抽象，表现为一个独立的虚拟 IP 和端口，其实这个 Service 就是我们经常提起的微服务架构中的一个微服务。

其实它的后端是由单个 Pod 或多个 Pod 的副本组成的容器结合，有 K8S 提供实际访问的路由能力。通过这层，K8S 能够在后端完成诸如：服务和切换、负载均衡、依据资源情况的节点调度等。

那这个 Service 和 RC、Pod 是什么关系呢？见下图

若公司有上百个或上千 Service，这些 Service 之间有链路调用关系，那如何进行监控这些服务呢？

一是在这些 service 中打印日志信息，通过 ELK 或 EFK 进行收集分析，二是通过服务网格来构建（Service Mesh）监控

RC（Replication Controller）

RC 是在早期 K8S 版本中用于管理 Pod 副本对象的概念，其实其也包含了 ReplicaSet 和 Deployment 的作用，但不具有部署版本管理的功能，所以在 1.2 以后的版本中，建议使用 Deployment 和 ReplicaSet 替代它，不过优先使用 Deployment

Deployment

Deployment 是 K8S 在 1.2 版本引入的新概念，用于更好的解决 Pod 的编排问题。其实 Deployment 在内部使用了 Replica Set 来实现的，也即是说：Deployment 所保存的部署描述信息是用来创建 ReplicaSet 对象，每个 Deployment 对象都会对应一个运行着的 ReplicaSet 对象，后者实际管理 Pod 副本的运行：

大致方向如下：

Deployment->ReplicaSet->Pod

Ingress

Ingress 本质上是一个负载均衡，它被用来将集群中的用户服务通过统一的 IP 地址暴露给外界。

Namespace

Namespace（命名空间）在很多情况下用于实现多租户的资源隔离，K8S 中除了 Node 和 Label 以外的大多数资源，例如：Pod，Service、LimitRange 等，都是在创建特定 Namespace 里的（default 是默认的 namespace）

sts（StatefulSet）

STS 是在 Kubernetes1.5 版本前称为 PetSet，用于部署和运行有持久化状态服务的方式。在 K8S 中，Pod 的管理对象 RC、Deployment、Job 都是面向无状态的服务，利用 STS 可以部署 MySQL 集群、MongoDB 集群、ZK 集群、Redis 集群等

Job

Job 是用来批量执行一次性任务。每个 Job 同样会对应一个或多个 Pod，这些 Pod 执行是有 时间限制的，程序结束后，Job 将被标记为成功或失败。

Volume

Volume（存储卷）是 Pod 中能够被多个容器访问的共享目录。

：