Kubernetes(K8s)是Google在2014年发布的一个开源项目。
据说Google的数据中心里运行着20多亿个容器,而且Google十年多前就开始使用容器技术。最初,Google开发了一个叫Borg的系统(现在命名为Omega)来调度如此庞大数量的容器和工作负载。在积累了这么多年的经验后,Google决定重写这个容器管理系统,并将其贡献到开源社区,让全世界都能受益。这个项目就是Kubernetes。简单地讲,Kubernetes是Google Omega的开源版本。
从2014年第一个版本发布以来,Kubernetes迅速获得开源社区的追捧,包括Red Hat、VMware、Canonical在内的很多有影响力的公司加入到开发和推广的阵营。目前Kubernetes已经成为发展最快、市场占有率最高的容器编排引擎产品。

k8s的基本概念

在部署前,必须先学习Kubernetes的几个重要概念,它们是组成Kubernetes集群的基石。

1 Cluster(集群)

Cluster是计算、存储和网络资源的集合,Kubernetes利用这些资源运行各种基于容器的应用。

2 Master(控制主节点)

Master是Cluster的大脑,它的主要职责是调度,即决定将应用放在哪里运行。Master运行Linux操作系统,可以
是物理机或者虚拟机。为了实现高可用,可以运行多个Master。调度应用程序、维护应用程序的所需状态、扩展应
用程序和滚动更新都是master的主要工作。

3 Node(节点)

Node的职责是运行容器应用。Node由Master管理,Node负责监控并汇报容器的状态,同时根据Master的要求管理容器的生命周期。
Node是 Kubernetes 集群中的工作机器,可以是物理机或虚拟机。每个工作节点都有一个 kubelet,它是管理节点并与 Kubernetes Master 节点进行通信的代理。节点上还应具有处理容器操作的容器运行时,例如 Docker。一个 Kubernetes 工作集群至少有三个节点。 Master 管理集群,而 Node(节点)用于托管正在运行的应用程序。
当你在 Kubernetes 上部署应用程序时,你可以告诉 master 启动应用程序容器。Master 调度容器在集群的节点上运行。 节点使用 Master 公开的 Kubernetes API 与 Master 通信。用户也可以直接使用 Kubernetes 的 API 与集群交互。

4 Pod(资源对象)

Pod是Kubernetes的最小工作单元。每个Pod包含一个或多个容器。Pod中的容器会作为一个整体被Master调度到
一个Node上运行。
Kubernetes引入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中? 答案是:这些容器联系必须非常紧密,而且需要直接共享资源。
举个例子,如图 所示,这个Pod包含两个容器:
一个是File Puller(文件拉取器),一个是Web Server。
File Puller会定期从外部的Content Manager中拉取最新的文件,将其存放在共享的volume中。Web Server从
volume读取文件,响应Consumer的请求。
这两个容器是紧密协作的,它们一起为Consumer提供最新的数据;同时它们也通过volume共享数据,所以放到
一个Pod是合适的。

5 Controller(控制器)

Kubernetes通常不会直接创建Pod,而是通过Controller来管理Pod的。Controller中定义了Pod的部署特性,比如有几个副本、在什么样的Node上运行等。为了满足不同的业务场景,Kubernetes提供了多种Controller,包括Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job等,我们逐一讨论。 (1)Deployment是最常用的Controller,比如在线教程中就是通过创建Deployment来部署应用的。Deployment可以管理Pod的多个副本,并确保Pod按照期望的状态运行。 (2)ReplicaSet实现了Pod的多副本管理。使用Deployment时会自动创建ReplicaSet,也就是说Deployment是通过ReplicaSet来管理Pod的多个副本的,我们通常不需要直接使用ReplicaSet。 (3)DaemonSet用于每个Node最多只运行一个Pod副本的场景。正如其名称所揭示的,DaemonSet通常用于运行daemon。 (4)StatefuleSet能够保证Pod的每个副本在整个生命周期中名称是不变
的,而其他Controller不提供这个功能。当某个Pod发生故障需要删除并重新启动时,Pod的名称会发生变化,同时StatefuleSet会保证副本按照固定的顺序启动、更新或者删除。
(5)Job用于运行结束就删除的应用,而其他Controller中的Pod通常是长期持续运行。

6 Service(服务)

Deployment可以部署多个副本,每个Pod都有自己的IP,外界如何访问这些副本呢? 通过Pod的IP吗? 要知道Pod很可能会被频繁地销毁和重启,它们的IP会发生变化,用IP来访问不太现实。
答案是Service。 Kubernetes Service定义了外界访问一组特定Pod的方式。Service有自己的IP和端口,Service为Pod提供了负载均衡。Kubernetes运行容器(Pod)与访问容器(Pod)这两项任务分别由Controller和Service执行。

7 Namespace(命名空间)

Namespace 是对一组资源和对象的抽象集合,比如可以用来将系统内部的对象划分为不同的项目组或用户组。
如果有多个用户或项目组使用同一个Kubernetes Cluster,如何将他们创建的Controller、Pod等资源分开呢? 答案就是Namespace。
Namespace可以将一个物理的Cluster逻辑上划分成多个虚拟Cluster,每个Cluster就是一个Namespace。不同
Namespace里的资源是完全隔离的。
Kubernetes默认创建了两个Namespace
default:创建资源时如果不指定,将被放到这个Namespace中。
kube-system:Kubernetes自己创建的系统资源将放到这个Namespace中。

kubernetes API server 作为集群的核心,负责集群各功能之间的通信, 集群内的各个功能模块通过API Server将信息存入etcd,当需要获取和操作这些数据的时候

通过API Server 提供的 REST 接口(get put post watch) 来实现