Skip to content

Introduction to Kubernetes

VodkaSoul edited this page Nov 12, 2019 · 1 revision

Table of Content

Kubernetes 介绍

Kubernetes 目标:

通过现代的 Web 服务,用户希望应用程序能够 24/7 全天候使用,开发人员希望每天可多次发布部署新版本。 容器化使应用程序能够以简单快速的方式发布和更新,而无需停机。Kubernetes 帮助您确保这些容器化的应用程序在您想要的时间和地点运行,并帮助应用程序找到它们需要的资源和工具。 是一个可用于生产的开源平台,根据 Google 容器集群方面积累的经验以及来自社区的最佳实践设计。

概述

要使用 Kubernetes需要用 Kubernetes API 对象来描述集群的 预期状态(desired state): 包括你需要运行的应用或者负载,它们使用的镜像、副本数,以及所需网络和磁盘资源等等。你可以使用命令行工具 kubectl 来调用Kubernetes API 创建对象,通过所创建的这些对象来配置预期状态。你也可以直接调用 Kubernetes API 和集群进行交互,设置或者修改预期状态。

一旦你设置了你所需的目标状态,Kubernetes 控制面(control plane)会通过 Pod 生命周期事件生成器( PLEG ),促成集群的当前状态符合其预期状态。为此,Kubernetes 会自动执行各类任务,比如运行或者重启容器、调整给定应用的副本数等等。Kubernetes 控制面由一组运行在集群上的进程组成:

  • Kubernetes 主控组件(Master) 包含三个进程,都运行在集群中的某个节上,通常这个节点被称为 master 节点。这些进程包括:kube-apiserverkube-controller-managerkube-scheduler
  • 集群中的每个非 master 节点都运行两个进程
    • kubelet,和 master 节点进行通信。
    • kube-proxy,一种网络代理,将 Kubernetes 的网络服务代理到每个节点上。

Kubernetes 对象

Kubernetes 包含若干抽象用来表示系统状态,包括:已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。参阅 Kubernetes 对象概述以了解详细信息。

基本的 Kubernetes 对象包括:

另外,Kubernetes 包含大量的被称作控制器(controllers) 的高级抽象。控制器基于基本对象构建并提供额外的功能和方便使用的特性。具体包括:

Kubernetes 控制面

关于 Kubernetes 控制平面的各个部分,(如 Kubernetes 主控组件和 kubelet 进程),管理着 Kubernetes 如何与你的集群进行通信。控制平面维护着系统中所有的 Kubernetes 对象的状态记录,并且通过连续的控制循环来管理这些对象的状态。在任意的给定时间点,控制面的控制环都能响应集群中的变化,并且让系统中所有对象的实际状态与你提供的预期状态相匹配。

比如, 当你通过 Kubernetes API 创建一个 Deployment 对象,你就为系统增加了一个新的目标状态。Kubernetes 控制平面记录着对象的创建,并启动必要的应用然后将它们调度至集群某个节点上来执行你的指令,以此来保持集群的实际状态和目标状态的匹配。

Kubernetes Master 节点

Kubernetes master 节点负责维护集群的目标状态。当你要与 Kubernetes 通信时,使用如 kubectl 的命令行工具,就可以直接与 Kubernetes master 节点进行通信。

“master” 是指管理集群状态的一组进程的集合。通常这些进程都跑在集群中一个单独的节点上,并且这个节点被称为 master 节点。master 节点也可以扩展副本数,来获取更好的可用性及冗余。

Kubernetes Node 节点

集群中的 node 节点(虚拟机、物理机等等)都是用来运行你的应用和云工作流的机器。Kubernetes master 节点控制所有 node 节点;你很少需要和 node 节点进行直接通信。

Kubernetes 架构

控制器

在自动化中, control loop 指的是一个永不终止的用于监控系统状态的循环。

在Kubernetes 中,controller 用于监控你的cluster状态,在需要的时候保证变化的发生,每一个 controller 都用于使得集群

控制模式

一个控制器跟踪控制一种 Kubernetes 资源类型.这些 objects 有一个特定的属性用于表示想要得到的状态。而 controller的目标是使得资源尽可能达到该状态。

controller 可能自带状态并把信息发给API server

通过 API server控制

Job 控制器是Kubernetes的一类内置控制器。内置控制器通过和cluster API server 交互控制状态。

Job 是一类运行一个或多个Pod的资源,用于执行任务然后停止。

(一旦进入 scheduled, Pod 对象变成kubelet理想状态的一部分。)

Job Controller 发现一个新任务,它确保cluster中,节点中的kubelets运行了正确数量的pod。要注意,Job Controller并不执行pod而只是告诉API server创建或移出podcontrol plane 中的组件进而做出反应。

创建新作业后,所需的状态是该作业要完成。Job控制器使该Job的当前状态更接近于您想要的状态:创建Pod来完成您要对该Job进行的工作,从而使Job接近完成。

控制器还更新配置它们的对象。例如:完成作业的工作后,作业控制器将更新该作业对象以对其进行标记Finished

Kubernetes 主要由以下几个核心组件组成:

  • etcd 保存了整个集群的状态;
  • kube-apiserver 提供了资源操作的唯一入口,并提供认证、授权、访问控制、API 注册和发现等机制;
  • kube-controller-manager 负责维护集群的状态,比如故障检测、自动扩展、滚动更新等;
  • kube-scheduler 负责资源的调度,按照预定的调度策略将 Pod 调度到相应的机器上;
  • kubelet 负责维持容器的生命周期,同时也负责 Volume(CVI)和网络(CNI)的管理;
  • Container runtime 负责镜像管理以及 Pod 和容器的真正运行(CRI),默认的容器运行时为 Docker
  • kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡;

所需状态与当前状态

Kubernetes采用云原生系统视图,并能够处理不断变化的情况。

随着工作的进行,集群可能随时随地发生变化,控制循环会自动修复故障。这意味着,您的群集可能永远无法达到稳定状态。

只要您的集群的控制器正在运行并且能够进行有用的更改,总体状态是否稳定都没有关系。

设计

作为其设计宗旨,Kubernetes使用许多控制器,每个控制器管理集群状态的特定方面。最常见的是,特定的控制回路(控制器)使用一种资源作为其所需状态,并使用另一种资源设法使该所需状态发生。

使用简单的控制器而不是一组相互链接的单片式控制回路很有用。控制器可能会失败,因此Kubernetes旨在允许这种情况。

例如:Jobs的控制器跟踪Job对象(以发现新工作)和Pod对象(以运行Jobs,然后查看工作何时完成)。在这种情况下,其他作业将创建作业,而作业控制器将创建容器。

注意:

可以有多个控制器创建或更新相同类型的对象。在幕后,Kubernetes控制器确保仅关注与控制资源链接的资源。

例如,您可以具有“部署”和“作业”;这些都创造了豆荚。作业控制器不会删除您的Deployment创建的Pod,因为控制器有一些信息可以用来区分那些Pod (标签)。

Controller 运行方式

Kubernetes 有一系列内置控制器 kube-controller-manager.

Deployment控制器和Job控制器是Kubernetes本身的一部分(“内置”控制器)的控制器示例。Kubernetes允许您运行弹性控制平面,这样,如果任何内置控制器发生故障,控制平面的另一部分将接管工作。

您可以找到在控制平面之外运行的控制器来扩展Kubernetes。或者,如果需要,您可以自己编写一个新的控制器。您可以将自己的控制器作为一组Pod运行,也可以在Kubernetes外部运行。最合适的选择取决于特定控制器的功能。