Kubernetes包含若干抽象用来表示系统状态，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用Kubernetes API（kube-apiserver提供）对象来表示。

Kubernetes规定了一套规范的资源对象，例如你的复合应用都放在Pod中，如果你需要在Kubernetes集群中提供服务，则可以对此Pod组创建Service，如果要持久化数据，则可以创建对应的Volume，想要伸缩Service下的Pod数量，可以创建对应的Deployment等等。

Kubernetes对象

基本对象

Pod

Pod是Kubernetes应用程序最基础的执行单元，是Kubernetes应用程序中你创建或部署的Kubernetes对象模型中最小和最简单的单元。Pod代表在集群上运行的进程。Pod封装了应用程序的一个或多个容器、存储资源、唯一的网络IP，以及管理容器应该如何运行的选项。Pod表示Kubernetes中部署的单个应用程序实例单元，可能包含单个容器或少量紧密耦合的容器并共享资源。

Pod总结：

  • Pod是Kubernetes运行应用程序的最小单元
  • 有唯一的网络和IP
  • Pod中可以存在多个容器
  • 多个容器共享Pod资源：如IP、存储、计算资源

由此可见，Pod有类似容器的功能（隔离，低资源消耗），又能支持多容器（相当于多应用）整合。例如：你的服务需要一个日志收集的agent，同时可以将服务和日志agent的镜像运行到同一个Pod中，这样你不用再为每次伸缩服务而需要配置日志agent而增加工作量，Kubernetes会为你自动完成这些。

若对Pod的实现原理有兴趣，请参考官方文档

Service

将运行在一组pod上的应用程序公开为网络服务的抽象方法，使用Kubernetes，你无需修改​​应用程序即可使用服务发现机制。 Kubernetes为Pods提供了自己的IP地址和一组Pod的单个DNS名称，并且可以在它们之间进行负载均衡。即它是Pod组（你的同一种Pod，多个实例）为集群提供服务的对象。Service方便了不同服务间的调用，还为你的服务自动实现负载均衡。

Service总结：

  • 为Pod组提供统一的内部DNS域名
  • 自动服务发现
  • 为Pod组实现负载均衡

Volume

容器中的磁盘文件是默认是没有持久化的，它和容器有相同的生命周期，会随着容器的删除而被清理。 但有时候，我们需要持久化容器中的数据目录或文件，或者需要在多个容器之间共享文件。Kubernetes的Volume对象解决了这两个问题。Volume和Docker容器中的卷有相同的作用，但是比它支持的类型和实现的方式更为广泛，详见Types of Volumes

Volume总结：

  • 可持久化Pod中的数据
  • 支持多种存储类型
  • 支持Pod中多容器共享

Namespace

Kubernetes支持由同一物理集群支持的多个虚拟集群。这些虚拟集群称为Namespace(命名空间)。Namespace旨在用于多个用户、多团队独立部署自己的虚拟应用集群，通过资源配额（resource quota）在多个用户之间划分群集资源。在Kubernetes的未来版本中，默认情况下，同一Namespace中的对象将具有相同的访问控制策略。例如，一个公司多个开发项目，各对应一个开发团队；则在公司的Kubernetes集群中可以针对每个项目来规划对应的Namespace；若有多环境要求，也可以再加上环境来规划区分。

Namespace总结：

  • 资源名称在Namespace中必须是唯一的。
  • Namespace不能彼此嵌套，并且每个Kubernetes资源只能位于一个Namespace中。
  • 可以通过资源配额控制用户使用的集群资源，例如CPU和内存。
  • 后期可针对Namespace做访问控制策略，例如网络策略。

各类controllers控制器

ReplicaSet

ReplicaSet又称副本集，它的作用是维护一组稳定的副本Pod。因此，它通常用于保证指定数量的相同Pod的可用性。ReplicaSet确保在任何给定时间运行指定数量的pod副本。 但是，Deployment是一个更高级别的概念，它管理ReplicaSet并为Pod提供声明性更新以及许多其他有用的功能。因此，我们建议使用Deployments而不是直接使用ReplicaSet，除非您需要自定义更新编排或根本不需要更新。

ReplicaSet总结：

  • ReplicaSet即相同Pod的数量。
  • Deployment管理ReplicaSet，它更高级，所以推荐使用Deployment。

Deployment

Deployment控制器为Pod和ReplicaSet提供声明性更新。你在部署配置中描述了所需的状态，并且Deployment控制器以受控的速率将实际状态更改为所需状态。 您可以定义部署以创建新的ReplicaSet，或者删除现有的部署并使用它所有资源创建新的部署。

Deployment总结：

  • Deployment管理ReplicaSet，所以不用去操作被Deployment管理的ReplicaSet。
  • Deployment可以按你的需求更新到你期望的状态，如更新方式，副本数。
  • Deployment部署的资源可以在重建时重新使用。
  • Deployment适合无状态的应用服务部署。

注：关于有状态和无状态服务，请参考链接

StatefulSets

StatefulSet是用于管理有状态应用程序的工作负载API对象。管理一组Pod的部署和扩展，并提供有关这些Pod的排序和唯一性的保证。

与Deployment类似，StatefulSet管理基于相同容器规范的Pod。不同的是，StatefulSet为其每个Pod维护一个粘性标识。这些pod是根据相同的规范创建的，但不可互换：每个pod都有一个持久的标识符，它在每次重新调度时都会保留。

StatefulSet以与任何其他Controller相同的模式运行。 你如果在StatefulSet对象中定义所需的状态，StatefulSet控制器会进行任何必要的更新以达到期望的状态。

StatefulSets总结：

  • StatefulSets与Deployment功能类似，都是管理相同规范的Pod。
  • StatefulSets部署的每个Pod，都具有唯一性，这样能保证Pod被自动调度时，具有相同且唯一的属性，例如hostname，pvc（持久存储卷）等。
  • StatefulSets适合有状态的应用服务部署。例如缓存，队列，数据库等。

DaemonSet

DaemonSet确保所有（或某些）节点运行Pod的副本。当节点添加到群集中，将自动添加DaemonSet下的Pod。而随着节点从群集中删除，这些Pod将被自动清理回收。删除DaemonSet将清除它创建的所有Pod。

DaemonSet总结：

  • DaemonSet和Deployment功能类似，都是管理相同规范的Pod。
  • DaemonSet会确保在每个节点运行它指定的Pod，除非有各类选择器要求。
  • DaemonSet部署的Pod会在节点被删除时自动删除。即它的副本数是和可部署的节点相同。

所以，DaemonSet特别适合部署类似监控agent性质的Pod

Job

Job创建一个或多个Pod并确保指定数量的Pod成功终止。当pod成功完成后，Job会跟踪成功的完成情况。达到指定数量的成功完成时，任务（即Job）完成。删除Job将清理它创建的Pod。

Job总结：

  • Job和Deployment功能类似，都是管理相同规范的Pod。
  • Job保证Pod成功终止，否则会一直尝试执行。
  • Job成功完成后会自动清理它创建的Pod。

所以，Job适用创建各类自定义任务，例如备份，同步，各类自动化脚本等。它会尽可能帮你完成任务。

最后

Kubernetes这些对象看似陌生，其实和我们平时用到的很多东西都息息相关，它让这些技术更为规范和可靠。文章内容虽然都在讲理论，显得很枯燥，但是我们最好能掌握，这样后面实操的时候就更能容易理解和记忆。