K8S学习(一)概念

目录

1.K8S相关概念

Cluster

Master

Node

Pod

Controller Manager

Service

NameSpace

2.K8S架构和集群规划

K8S架构

K8S架构拆解图

K8S Master节点

K8S Node节点

K8S中Pod的创建流程


1.K8S相关概念

  • Cluster

Cluster由多台虚拟机或者物理设备组成,是计算、存储和网络等资源的集合,K8S利用这些资源运行各种基于容器的应用。

  • Master

Master是Cluster集群的大脑,它的主要职责是调度、即决定将应用放在哪个节点运行。Master 运行 Linux 操作系统,可以是物理机或者虚拟机。为了实现高可用,可以运行多个 Master。

  • Node

Node是用于运行容器应用的节点。Node由Master管理,Node主要负责监控并汇报容器的状态,并根据Master的要求管理容器的生命周期。Node运行在Linux操作系统上,可以是物理机或者虚拟机。

  • Pod

Pod是K8S的最小工作单元。每个Pod可以包含一个或者多个有紧密联系的容器应用。Pod中的容器回作为一个整体被Master调度到一个Node上运行。(Pod如何创建?通过Master上的Controller Manager


K8S引入Pod主要基于下面两个目的:

  1. 可管理性。
    有些容器天生就是需要紧密联系,一起工作。Pod 提供了比容器更高层次的抽象,将它们封装到一个部署单元中。Kubernetes 以 Pod 为最小单位进行调度、扩展、共享资源、管理生命周期。

  2. 通信和资源共享。
    Pod 中的所有容器使用同一个网络 namespace,即相同的 IP 地址和 Port 空间。它们可以直接用 localhost 通信。同样的,这些容器可以共享存储,当 Kubernetes 挂载 volume 到 Pod,本质上是将 volume 挂载到 Pod 中的每一个容器。

Pods的使用方式:

  1. 运行单一容器。
    one-container-per-Pod 是 Kubernetes 最常见的模型,这种情况下,只是将单个容器简单封装成 Pod。即便是只有一个容器,Kubernetes 管理的也是 Pod 而不是直接管理容器。

  2. 运行多个容器。
    但问题在于:哪些容器应该放到一个 Pod 中? 
    答案是:这些容器联系必须 非常紧密,而且需要 直接共享资源。


Example:

下图的Pod包含两个容器:一个File Puller,一个是Web Server。

K8S学习(一)概念_第1张图片

    

File Puller 会定期从外部的 Content Manager 中拉取最新的文件,将其存放在共享的 volume 中。Web Server 从 volume 读取文件,响应 Consumer 的请求。这两个容器是紧密协作的,它们一起为 Consumer 提供最新的数据;同时它们也通过 volume 共享数据。所以放到一个 Pod 是合适的。

再来看一个反例:是否需要将 Tomcat 和 MySQL 放到一个 Pod 中?

Tomcat 从 MySQL 读取数据,它们之间需要协作,但还不至于需要放到一个 Pod 中一起部署,一起启动,一起停止。同时它们是之间通过 JDBC 交换数据,并不是直接共享存储,所以放到各自的 Pod 中更合适。

  • Controller Manager

Controller Manager作为集群内部的管理控制中心,负责集群内的Node,Pod副本,服务端点(endpoint),命名空间(namespace)等的管理,当某个Node意外宕机,CM会及时发现此故障并执行自动化修复流程,确保集群始终处于预期的工作状态。

K8S通常不会直接创建Pod。而是通过CM来管理Pods的,Controller Manager中定义了Pod的部署特性,比如有几个副本,在哪个Node上运行等,CM有许多不同的Controller,用来提供各种功能。如下图:

每个Controller通过API Server提供的接口实时监控整个集群的每个资源对象的当前状态,当发生各种故障导致系统状态发生变化时,会尝试将系统状态修复到“期望状态”。

  • Service

Deployment Controller为Pod和Replication Set通过声明示更新,通过它够可以创建出多个Pod,每个Pod都有自己的IP,那么外界如何去访问这些Pod呢?通过Pod的IP吗?这肯定是不行对的,Pod可能会被频繁地创建,销毁,或者重启,它们的IP会频繁地变化,用Pod的IP去访问不太现实。

答案是使用Service。

Service在K8S中主要提供的功能是负载均衡和服务自动发现,它提供了我们访问单个或者多个容器应用的能力。每个Service在其生命周期内,都拥有一个固定的IP地址和端口(所以Pod的IP变化,不会影响到这个Pod的上层Service的IP地址变化)。这样也方便后端进行Pod的弹性伸缩等操作。

K8S学习(一)概念_第2张图片

所有说K8S运行Pod和访问Pod这两项任务分别由Controller和Service执行。

  • NameSpace

我们可以认为NameSpace是K8S Cluster中的虚拟化集群。在一个K8S集群中可以有多个命名空间,这些命名空间在逻辑上彼此隔离。常见的pods, services, replication controllers和deployments等都是属于某一个NameSpace的(默认是default)。

类似于default这样的默认NameSpace,K8S集群共有三个:

  •     default:创建资源时如果不指定NameSpace的话,默认将被放到default中
  •     kube-system:kubernetes系统组件使用。
  •     kube-public:公共资源使用。但实际上现在并不常用。

2.K8S架构和集群规划

  • K8S架构

  • K8S架构拆解图

K8S学习(一)概念_第3张图片

K8S Master节点

    从上图可以看到K8S Cluster的大脑,运行着的Daemon服务包括kube-apiserver、kube-scheduler、kube-controller-manager、etcd和Pod网络(例如flannel)。

1. API Server (kube-apiserver)

    API Server提供HTTP/HTTPS RESTful API,即Kubernetes API。API Server是Kubernetes Cluster的前端接口,各种客户端工具(CLI或UI)以及Kubernetes其他组件可以通过它管理Cluster的各种资源。

2. Scheduler(kube-scheduler) 

    Scheduler负责决定将Pod放在哪个Node上运行。Scheduler在调度时会充分考虑Cluster的拓扑结构,当前各个节点的负载,以及应用对高可用、性能、数据亲和性的需求。

3. Controller Manager(kube-controller-manager) 

    Controller Manager负责管理Cluster各种资源,保证资源处于预期的状态。Controller Manager 由多种Controller组成,包括replication controller、endpoint controller、namespace controller、serviceaccounts controller等。 
               不同的controller管理不同的资源。例如,replication controller管理Deployment、StatefulSet、DaemonSet的生命周期,namespace controller管理Namespace资源。

4. etcd
               etcd负责保存Kubernetes Cluster的配置信息和各种资源的状态信息。当数据发生变化时,etcd会快速通知Kubernetes相关组件。

5. Pod网络 

    Pod要能够相同通信,Kubernetes Cluster必须部署Pod网络,flannel是其中一个可选方案。

K8S Node节点

Node是Kubernetes集群架构中运行Pod的服务节点(亦叫agent或minion)。Node是Kubernetes集群操作的单元,用来承载被分配Pod的运行,是Pod运行的宿主机。关联Master管理节点,拥有名称和IP、系统资源信息。运行docker eninge服务,守护进程kunelet及负载均衡器kube-proxy.

  • 每个Node节点都运行着以下一组关键进程
  • kubelet:负责对Pod对于的容器的创建、启停等任务
  • kube-proxy:实现Kubernetes Service的通信与负载均衡机制的重要组件
  • Docker Engine(Docker):Docker引擎,负责本机容器的创建和管理工作

  Node节点可以在运行期间动态增加到Kubernetes集群中,默认情况下,kubelet会向master注册自己,这也是Kubernetes推荐的Node管理方式,kubelet进程会定时向Master汇报自身情报,如操作系统、Docker版本、CPU和内存,以及有哪些Pod在运行等等,这样Master可以获知每个Node节点的资源使用情况,冰实现高效均衡的资源调度策略。

1. Kubelet:kubelet是node的agent,当Scheduler确定在某个Node上运行Pod后,会将Pod的具体配置信息(image、volume等)发送给该节点的kubelet,kubelet会根据这些信息创建和运行容器,并向master报告运行状态。

2. Kube-proxy: service在逻辑上代表了后端的多个Pod,外借通过service访问Pod。service接收到请求就需要kube-proxy完成转发到Pod的。每个Node都会运行kube-proxy服务,负责将访问的service的TCP/UDP数据流转发到后端的容器,如果有多个副本,kube-proxy会实现负载均衡,有2种方式:LVS或者Iptables。

3. 容器运行时环境,如Docker, rkt, runc等:负责节点的容器的管理工作。

K8S中Pod的创建流程

创建Pod 的流程

           1. 用户通过REST API创建一个Pod
           2. apiserver将其写入etcd
           3. scheduluer检测到未绑定Node的Pod,开始调度并更新Pod的Node绑定
           4. kubelet检测到有新的Pod调度过来,通过container runtime运行该Pod
           5. kubelet通过container run

 

参考:《每天5分钟玩转Kubernetes》、https://www.cnblogs.com/linuxk/

你可能感兴趣的:(K8S学习总结,K8S)