k8s pod内部容器_Kubernetes基石-pod容器

ReplicationController是一种Kubernetes资源，可确保它的pod始终保持运行状态。

如果pod因任何原因消失(例如节点从集群中消失或由于该pod己从节点中逐出)，则ReplicationController会注意到缺少了pod并创建替代pod。

非托管的pod节点异常退出后将没有东西负责重建它，而由ReplicationController管理的pod异常退出后，ReplicationController将会创建一个新的pod来替换异常退出的pod。

一般而言，ReplicationController旨在创建和管理一个pod的多个副本(replicas)。这就是ReplicationController名字的由来。

当节点故障时，只有ReplicationController 管理的pod 会被重新创建。

ReplicationController会持续监控正在运行的pod列表，并保证相应“类型”的pod的数目与期望相符。如正在运行的pod太少，它会根据pod模板创建新的副本。如正在运行的pod太多，它将删除多余的副本。

你可能会对有多余的副本感到奇怪。这可能有几个原因：

·有人会手动创建相同类型的pod。

·有人更改现有的pod的“类型”。

·有人减少了所需的pod的数量，等等。

一个ReplicationController有三个主要部分：

label selector(标签选择器)，用于确定ReplicationController作用域中有哪些

pod·replica count(副本个数)，指定应运行的pod数量

pod template(pod模板)，用于创建新的pod副本

ReplicationController的副本个数、标签选择器，甚至是pod模板都可以随时修改，但只有副本数目的变更会影响现有的pod。

更改ReplicationController的标签选择器和pod模板对现有pod没有影响。更改标签选择器会使现有的pod 脱离ReplicationController的监视范围，因此ReplicationController将会停止关注它们。

在创建pod后，ReplicationController并不关心其pod的实际“内容”(容器镜像、环境变量及其他)。因此，修改ReplicationController的pod模板仅影响由此ReplicationController创建的新pod。

使用ReplicationController的好处像Kubernetes中的许多事物一样，ReplicationController尽管是一个令人难以置信的简单概念，却提供或启用了以下强大功能：

·确保一个pod(或多个pod副本)持续运行，解决方法是在监控的pod丢失时启动一个新pod。

·集群节点发生故障时，它将为故障节点上运行的所有pod(即受ReplicationController 控制的节点上的那些pod)创建替代副本。

·它能轻松实现pod的水平伸缩，手动和自动都可以

注意：pod实例永远不会重新安置到另一个节点。ReplicationController的解决方案是根据pod模板创建一个全新的pod实例而不是去移动当前实例，它与正在替换的实例无关。

ReplicationController的创建

就像pod和其他Kubernetes资源，可以通过上传JSON或YAML描述文件到Kubernetes API 服务器来创建ReplicationController。

apiVersion: v1 #指定当前描述文件遵循v1版本的KubernetesAPI

kind: ReplicationController #我们在描述一个ReplicationController

metadata:

name: coreqi-manual #指定ReplicationController的名称

spec:

replicas:3#pod实例的目标数目

selector: #pod选择器决定了ReplicationController的操作对象

app: coreqi #当前ReplicationController将确保符合标签选择器app=coreqi的pod实例始终是三个，当没有足够的pod时，将使用下面的pod模板创建新的pod

template: #创建新pod所使用的pod模板

metadata:

labels:

app: coreqi #模板中的pod标签显然必须和ReplicationController的标签选择器相匹配，否则控制器将无休止的创建新的pod实例。因为创建新的pod不会使实际的副本数量接近期望的副本数量。为了防止出现这种情况，Kubernetes API服务会校验ReplicationController的定义不会接收错误的配置。

#不指定ReplicationController的标签选择器也是一种选择，因为ReplicationController会自动从模板中提取标签，而且描述文件也将更简短

spec:

containers:-name: coreqi

image: fanqisoft/coreqi

ports:- containerPort: 8080

创建了ReplicationController的描述文件后我们就可以通过相应的指令去创建它了。

kubectl create -f coreqi-rc.yaml

由ReplicationController创建的pod并不是绑定到ReplicationController。ReplicationController只会管理与当前ReplicationController标签选择器相匹配的pod。通过更改pod的标签，可以将它从ReplicationController的作用域中添加或删除。它甚至可以从一个ReplicationController移动到另一个。

提示：尽管一个pod没有绑定到一个ReplicationController，但该pod在metadata.ownerReferences字段中引用它，可以轻松使用它来找到一个pod属于哪个ReplicationController。

如果你更改了一个pod的标签，使它不再与ReplicationController的标签选择器相匹配，那么该pod就变得和其他手动创建的pod一样了。它不再被任何东西管理。如果运行该节点的pod异常终止，它显然不会被重新调度。但请记住，当你更改pod的标签时，ReplicationController发现一个pod丢失了，将会启动一个新的pod替换它。

例如，一个ReplicationController管理具有app=coreqi标签的pod，当我们对一个pod删除这个标签或修改其值时，ReplicationController会将该pod移出管理范围。添加新的标签并没有用，因为ReplicationController 并不关心该pod是否有任何附加标签，它只关心该pod是否具有当前ReplicationController标签选择器中引用的所有标签。

更改ReplicationController的pod模板只影响之后创建的pod，并且不会影响现有的pod。要修改旧的pod，需要删除它们，并让ReplicationController根据新模板将其替换为新的pod。