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

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中能够被多个容器访问的共享目录。