kubernetes(一般简称为K8S),是一个用于管理在容器中运行的应用的容器编排工具。前端
Kubernetes不只有你所须要的用来支持复杂容器应用的全部东西,它仍是市面上最方便开发和运维的框架。后端
Kubernetes的工做原理是经过将容器分组来把一个应用程序拆分红多个逻辑单元,以方便管理和发现。它对由小且独立的服务组成的微服务应用特别有用。api
尽管Kubernetes运行在Linux上,他实际上是平台无关的,能够在裸机、虚拟机、云实例或OpenStack上运行。网络
Cluster
Cluster 是计算、存储和网络资源的集合,Kubernetes 利用这些资源运行各类基于容器的应用。负载均衡
Master
Master 是 Cluster 的大脑,它的主要职责是调度,即决定将应用放在哪里运行。Master 运行 Linux 操做系统,能够是物理机或者虚拟机。为了实现高可用,能够运行多个 Master。框架
Node
Node 的职责是运行容器应用。Node 由 Master 管理,Node 负责监控并汇报容器的状态,并根据 Master 的要求管理容器的生命周期。Node 运行在 Linux 操做系统,能够是物理机或者是虚拟机。运维
在前面交互式教程中咱们建立的 Cluster 只有一个主机 host01,
它既是 Master 也是 Node。微服务
Pod
Pod 是 Kubernetes 的最小工做单元。每一个 Pod 包含一个或多个容器。Pod 中的容器会做为一个总体被 Master 调度到一个 Node 上运行。工具
Kubernetes 引入 Pod 主要基于下面两个目的:性能
可管理性。
有些容器天生就是须要紧密联系,一块儿工做。Pod 提供了比容器更高层次的抽象,将它们封装到一个部署单元中。Kubernetes 以 Pod 为最小单位进行调度、扩展、共享资源、管理生命周期。
通讯和资源共享。
Pod 中的全部容器使用同一个网络 namespace,即相同的 IP 地址和 Port 空间。它们能够直接用 localhost 通讯。一样的,这些容器能够共享存储,当 Kubernetes 挂载 volume 到 Pod,本质上是将 volume 挂载到 Pod 中的每个容器。
Pods 有两种使用方式:
运行单一容器。
one-container-per-Pod 是 Kubernetes 最多见的模型,这种状况下,只是将单个容器简单封装成 Pod。即使是只有一个容器,Kubernetes 管理的也是 Pod 而不是直接管理容器。
运行多个容器。
但问题在于:哪些容器应该放到一个 Pod 中?
答案是:这些容器联系必须 很是紧密,并且须要 直接共享资源。
Controller
Kubernetes 一般不会直接建立 Pod,而是经过 Controller 来管理 Pod 的。Controller 中定义了 Pod 的部署特性,好比有几个副本,在什么样的 Node 上运行等。为了知足不一样的业务场景,Kubernetes 提供了多种 Controller,包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等,咱们逐一讨论。
Deployment 是最经常使用的 Controller,好比前面在线教程中就是经过建立 Deployment 来部署应用的。Deployment 能够管理 Pod 的多个副本,并确保 Pod 按照指望的状态运行。
ReplicaSet 实现了 Pod 的多副本管理。使用 Deployment 时会自动建立 ReplicaSet,也就是说 Deployment 是经过 ReplicaSet 来管理 Pod 的多个副本,咱们一般不须要直接使用 ReplicaSet。
DaemonSet 用于每一个 Node 最多只运行一个 Pod 副本的场景。正如其名称所揭示的,DaemonSet 一般用于运行 daemon。
StatefuleSet 可以保证 Pod 的每一个副本在整个生命周期中名称是不变的。而其余 Controller 不提供这个功能,当某个 Pod 发生故障须要删除并从新启动时,Pod 的名称会发生变化。同时 StatefuleSet 会保证副本按照固定的顺序启动、更新或者删除。
Job 用于运行结束就删除的应用。而其余 Controller 中的 Pod 一般是长期持续运行。
Service
Deployment 能够部署多个副本,每一个 Pod 都有本身的 IP,外界如何访问这些副本呢?
经过 Pod 的 IP 吗?
要知道 Pod 极可能会被频繁地销毁和重启,它们的 IP 会发生变化,用 IP 来访问不太现实。
答案是 Service。
Kubernetes Service 定义了外界访问一组特定 Pod 的方式。Service 有本身的 IP 和端口,Service 为 Pod 提供了负载均衡。
Kubernetes 运行容器(Pod)与访问容器(Pod)这两项任务分别由 Controller 和 Service 执行。
Namespace
若是有多个用户或项目组使用同一个 Kubernetes Cluster,如何将他们建立的 Controller、Pod 等资源分开呢?
答案就是 Namespace。
Namespace 能够将一个物理的 Cluster 逻辑上划分红多个虚拟 Cluster,每一个 Cluster 就是一个 Namespace。不一样 Namespace 里的资源是彻底隔离的。
Kubernetes 默认建立了两个 Namespace。
default -- 建立资源时若是不指定,将被放到这个 Namespace 中。
kube-system -- Kubernetes 本身建立的系统资源将放到这个 Namespace 中。
API Server(kube-apiserver)
API Server 提供 HTTP/HTTPS RESTful API,即 Kubernetes API。API Server 是 Kubernetes Cluster 的前端接口,各类客户端工具(CLI 或 UI)以及 Kubernetes 其余组件能够经过它管理 Cluster 的各类资源。
Scheduler(kube-scheduler)
Scheduler 负责决定将 Pod 放在哪一个 Node 上运行。Scheduler 在调度时会充分考虑 Cluster 的拓扑结构,当前各个节点的负载,以及应用对高可用、性能、数据亲和性的需求。
Controller Manager(kube-controller-manager)
Controller Manager 负责管理 Cluster 各类资源,保证资源处于预期的状态。Controller Manager 由多种 controller 组成,包括 replication controller、endpoints controller、namespace controller、serviceaccounts controller 等。
不一样的 controller 管理不一样的资源。例如 replication controller 管理 Deployment、StatefulSet、DaemonSet 的生命周期,namespace controller 管理 Namespace 资源。
etcd
etcd 负责保存 Kubernetes Cluster 的配置信息和各类资源的状态信息。当数据发生变化时,etcd 会快速地通知 Kubernetes 相关组件。
Pod 网络
Pod 要可以相互通讯,Kubernetes Cluster 必须部署 Pod 网络,flannel 是其中一个可选方案。
kubelet
kubelet 是 Node 的 agent,当 Scheduler 肯定在某个 Node 上运行 Pod 后,会将 Pod 的具体配置信息(image、volume 等)发送给该节点的 kubelet,kubelet 根据这些信息建立和运行容器,并向 Master 报告运行状态。
kube-proxy
service 在逻辑上表明了后端的多个 Pod,外界经过 service 访问 Pod。service 接收到的请求是如何转发到 Pod 的呢?这就是 kube-proxy 要完成的工做。
每一个 Node 都会运行 kube-proxy 服务,它负责将访问 service 的 TCP/UPD 数据流转发到后端的容器。若是有多个副本,kube-proxy 会实现负载均衡。