关于kubernetes:Kubernetes核心资源对象概述

Kubernetes 有很多技术概念和 API 对象，每一个都能够扩大讲很多，依照前文的学习思路，还是先理解大略。

官网对于 Pod 的解释是：

Pod是能够在 Kubernetes 中创立和治理的、最小的可部署的计算单元。

Pod 的设计理念是反对多个容器在一个 Pod 中共享网络地址和文件系统，能够通过过程间通信和文件共享这种简略高效的形式组合实现服务。

举个简略的例子：比方咱们设计了一个商品相干的微服务，包含了商品治理和商品同步（从其余数据源抽取商品）两局部性能，在设计上来说，咱们很可能把这两局部拆成 2 个独立小利用并且由 2 个小组别离来实现（只是假如）。这种状况下，大能够不同的团队各自开发构建本人的容器镜像，在部署的时候组合成一个微服务对外提供服务，构建一个 Pod。

Pod 间关系如下图：

同一个 Pod 之间的 Container 能够通过 localhost 相互拜访，并且能够挂载 Pod 内所有的数据卷；然而不同的 Pod 之间的 Container 不能用 localhost 拜访，也不能挂载其余 Pod 的数据卷。

Kubernetes 集群中的存储卷跟 Docker 的存储卷有些相似，只不过 Docker 的存储卷作用范畴为一个容器，而 Kubernetes 的存储卷的生命周期和作用范畴是一个 Pod。每个 Pod 中申明的存储卷由 Pod 中的所有容器共享。Kubernetes 反对十分多的存储卷类型，特地的，反对多种私有云平台的存储，包含 AWS，Google 和 Azure 云；反对多种分布式存储包含 GlusterFS 和 Ceph；也反对较容易应用的主机本地目录 emptyDir, hostPath 和 NFS。

前文说了 Master 节点中包涵组件 Controller Manager，其中具体的一些控制器就蕴含了 Deployment、ReplicaSet、Replication Controller 三者，它们相当于一个状态机，用来管制 pod 的具体状态和行为。

ReplicaSet、Replication Controller

先说 Replication Controller，简称 RC。RC 保障在同一时间可能运行指定数量的 Pod 正本，保障 Pod 总是可用。如果理论 Pod 数量比指定的多就完结掉多余的，如果理论数量比指定的少就启动短少的。当 Pod 失败、被删除或被终结时 RC 会主动创立新的 Pod 来保障正本数量。所以即便只有一个 Pod 也应该应用 RC 来进行治理。

ReplicaSet，简称 RS，随着 Kubernetes 的倒退，官网曾经举荐咱们应用RS 和Deployment来代替 RC 了，RS对象个别不独自应用，而是作为 Deployment 的现实状态参数应用。目前 RS 和 RC 惟一的一个区别就是 RC 只反对基于等式的 selector（env=dev 或 environment!=qa），但RS 还反对基于汇合的selector（version in (v1.0, v2.0)），这对简单的运维治理就十分不便了。
Deployment

Deployment同样也是 Kubernetes 零碎的一个外围概念，主要职责和 RC 一样的都是保障 Pod 的数量和衰弱，二者大部分性能都是完全一致的，咱们能够看成是一个升级版的 RC 控制器。除了 RC 所蕴含的性能外，Deployment还具备以下个性：
- 事件和状态查看：能够查看 Deployment 的降级具体进度和状态
- 回滚：当降级 Pod 的时候如果呈现问题，能够应用回滚操作回滚到之前的任一版本
- 版本记录：每一次对 Deployment 的操作，都可能保留下来，这也是保障能够回滚到任一版本的根底
- 暂停和启动：对于每一次降级都可能随时暂停和启动
Deployment 和 ReplicaSet 关系

可能看到这，有人会问既然都差不多，有了 ReplicaSet 为什么还要搞个 Deployment 对象。两者大略构造如下图：

咱们拿滚动降级一个服务的场景来阐明，滚动降级一个服务，理论是创立一个新的 RS，而后逐步将新RS 中正本数减少到现实状态，将旧 RS 中的正本数减小到 0 的复合操作；这样一个复合操作用一个 RS 是不太好形容的，所以用一个更通用的 Deployment 来形容。

我集体的了解，举个不失当的例子，相似畛域模型中的贫血模型和充血模型差不多，RS 对象更多像贫血模型，只保留了属性。而 Deployment 对象蕴含了属性和行为，适用性更广。官网也是强烈建议咱们应用 Deployment 和RS来治理 Pod。

官网文档中 Service 的定义：

将运行在一组 Pods 上的应用程序公开为网络服务的形象办法。

应用 Kubernetes，您无需批改应用程序即可应用不相熟的服务发现机制。Kubernetes 为 Pods 提供本人的 IP 地址，并为一组 Pod 提供雷同的 DNS 名，并且能够在它们之间进行负载平衡。

能够发现，Service对象提供了 2 种能力：让 Pod 可能被服务发现和被负载平衡。为什么这么说呢，因为 Service 对象自身并不干这两件事件。Service是一种形象的对象，它定义了一组 Pod 的逻辑汇合和一个用于拜访它们的策略，其实这个概念和微服务十分相似。

为什么须要 Service 对象？

RC、RS 和 Deployment 只是保障了撑持服务的微服务 Pod 的数量，然而没有解决如何拜访这些服务的问题。Pod 是有生命周期的。它们能够被创立，而且销毁之后不会再启动。如果您应用 Deployment 来运行您的应用程序，则它能够动态创建和销毁 Pod。每个 Pod 都有本人的 IP 地址，然而在 Deployment 中，在同一时刻运行的 Pod 汇合可能与稍后运行该应用程序的 Pod 汇合不同，因而不能以确定的 IP 和端口号提供服务。

Service 对象定义了一组 Pod 的逻辑汇合和一个用于拜访它们的策略，在 Kubernetes 集群中，客户端须要拜访的服务就是 Service 对象。每个 Service 会对应一个集群外部无效的虚构 IP，集群外部通过虚构 IP 拜访一个服务。

咱们在日常的工作中常常都会遇到一些须要进行批量数据处理和剖析的需要，当然也会有按工夫来进行调度的工作，在咱们的 Kubernetes 集群中为咱们提供了 Job 和CronJob两种资源对象来应答咱们的这种需要。Job负责解决工作，即仅执行一次的工作，它保障批处理工作的一个或多个 Pod 胜利完结。而 CronJob 则就是在 Job 上加上了工夫调度。

Namespace 为 Kubernetes 集群提供虚构的隔离作用，Kubernetes 集群初始有两个命名空间，别离是默认命名空间 default 和零碎命名空间 kube-system，除此以外，管理员能够能够创立新的命名空间满足需要。

前文提到的概念都是为了服务 Pod 的，而 namespace 则是为了服务整个 Kubernetes 集群的。是为了把一个 Kubernetes 集群划分为若干个资源不可共享的虚构集群而诞生的。

其余还有一些外围资源对象，不过貌似对下一步集群部署实际没什么太大影响，后续再补充吧。

关于kubernetes:Kubernetes核心资源对象概述

Pod

Volume

Deployment、ReplicaSet、Replication Controller

Service

Job/Cronjob

Namespace

其余