ReplicationController 控制器
ReplicationController 是一种 Kubernetes 资源，可确保它的 pod 始终保持运行状态。如果 pod 因任何原因消失（例如节点从集群中消失或由于该 pod 己从节点中逐出），则 ReplicationController 会注意到缺少了 pod 并创建替代 pod。
ReplicationController 的工作是确保 pod 的数量始终与其标签选择器匹配。如果不匹配，则 ReplicationController 将根据所需 ， 采取适当的操作来协调 pod 的数量。
-w713
ReplicationController 的组成部分
一个 ReplicationController 有三个主要部分：
- label selector:标签选择器，用于确定 ReplicationController 作用域中有哪些 pod
- replica count: 副本个数，指定应运行的 pod 数量
- pod template：pod模板，用于创建新的 pod 副本
ReplicationController 的副本个数、标签选择器，甚至是 pod 模板都可以随时修改，但只有副本数目的变更会影响现有的 pod。
更改标签选择器和 pod 模板对现有 pod 没有影响。更改标签选择器会使现有的 pod 脱离ReplicationController 的范围，因此控制器会停止关注它们。在创建 pod 后， ReplicationController 也不关心其 pod 的实际“内容”（容器镜像、环境变量及其他）。 因此，该模板仅影响由此 ReplicationController 创建的新 pod。
使用ReplicationController 的好处
像 Kubernetes 中的许多事物一样， ReplicationController 尽管是一个令人难以置信的简单概念，却提供或启用了以下强大功能：
- 确保一个或多个pod持续运行，方法是在现有 pod 丢失时启动一个新的 pod。
- 集群节点发生故障时，它将为故障节点上运行的所有 pod（受ReplicationController 控制的节点上的pod） 创建替代副本。
- 它能轻松实现 pod 的水平伸缩。
pod 实例永远不会重新安置到另一个节点。 相反，ReplicationController 会创建一个全新的 pod 实例，它与正在替换的实例无关。
创建一个 ReplactionController
apiVersion: v1
kind: ReplicationController
metadata:
name: rc-test
spec:
## pod实例的目标数量
replicas: 3
## 标签选择器，决定rc控制器的操作对象
selector:
app: nginx
## 创建新 pod 所用的pod模板
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: test-rc-nginx
image: nginx
ports:
- containerPort: 80
protocol: TCP
kc create -f test-nginx-replication-controller.yaml --validate=false
Kubernetes 会创建一个名为 rc-test 的新 ReplicationController， 它确保符合标签选择器 app=nginx 的 pod 实例始终是三个。 当没有足够的 pod 时，根据提供的 pod 模板创建新的 pod 。
模板中的 pod 标签显然必须和 ReplicationController 的标签选择器匹配， 否则控制器将无休止地创建新的容器。因为启动新 pod 不会使实际的副本数量接近期望的副本数量。为了防止出现这种情况，API 服务会校验 ReplicationController 的定义，不会接收错误配置。
不指定选择器也是一种选择。在这种情况下，它会自动根据 pod 模板中的标签自动配置。
定义 ReplicationController 时不要指定 pod 选择器，让 kubernetes 从 pod 模板中提取它。这样 YAML 更简短。
使用 ReplicationController
由于没有任何 pod 有 app=nginx 标签，ReplicationController 会根据 pod 模板启动三个新的 pod。
## kc get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
rc-test-5g8cz 1/1 Running 0 23m app=nginx
rc-test-dcsdb 1/1 Running 0 23m app=nginx
rc-test-fmh2q 1/1 Running 0 23m app=nginx
删除其中一个 pod 看会发生什么
## kc delete pods rc-test-mzcqc
## kc get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
rc-test-6b69p 1/1 Running 0 2m31s app=nginx
rc-test-89hqk 0/1 ContainerCreating 0 1s app=nginx
rc-test-mzcqc 0/1 Terminating 0 3m11s app=nginx
rc-test-sfc8r 1/1 Running 0 2m50s app=nginx
重新列出pod会显示四个，删除的 pod 在终止中，新创建的 pod 在创建中
获取有关 ReplicationController 的信息
## 列出所有 rc 控制器
kc get rc
## 查看某个 rc 详细信息
kc describe rc rc-test
控制器通过创建一个新的替代 pod 来响应 pod 的删除操作。从技术上讲，它并没有对删除本身做出反应，而是针对由此产生的状态：pod 数量不足。
虽然 ReplicationController 会立即收到删除 pod 的通知 ( API 服务器允许客户端 监听资源和资源列表的更改 ），但这不是它创建替代 pod 的原因。该通知会触发控制器检查实际的 pod 数量并采取适当的措施。
将 pod 移入或移出 ReplicationController 的作用域
由 ReplicationController 创建的 pod 并不是绑定到 ReplicationController。在任何时刻，ReplicationController 管理与标签选择器匹配的 pod。通过更改 pod 的标签，可以将它从 ReplicationController 的作用域中添加或删除。它甚至可以从一个ReplicationController移动到另一个。
尽管一个 pod 没有绑定到一个 ReplicationController，但该 pod 在metadata.ownerReferences 字段中引用它，可以轻松使用它来找到一个 pod 属于哪个 ReplicationController
如果你更改了一个 pod 的标签，使它不再与 ReplicationController 的标签选择器相匹配，那么该 pod 就变得和其他手动创建的 pod 一样了。它不再被任何东西管理。如果运行该节点的 pod 异常终止，它显然不会被重新调度。 但请记住，当你更改 pod 的标签时，ReplicationController 发现一个 pod 丢失了，并启动一个新的 pod 替换它。
## 给其中的一个pod 添加标签
kc label pods rc-test-89hqk auth=yuxuan
kc get pods --show-labels
rc-test-6b69p 1/1 Running 0 29m app=nginx
rc-test-89hqk 1/1 Running 0 27m app=nginx,auth=yuxuan
rc-test-sfc8r 1/1 Running 0 29m app=nginx
给其中一个 pod 添加了 auth=yuxuan 标签，再次列出所有 pod 会显示和以前一样的三个 pod。因为从 ReplicationController 角度而言，没发生任何更改。
## 修改其中一个pod的 app 标签值
kc label pod rc-test-89hqk app=nginx2 --overwrite
kc get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
rc-test-6b69p 1/1 Running 0 35m app=nginx
rc-test-89hqk 1/1 Running 0 33m app=nginx2,auth=yuxuan
rc-test-mpf76 0/1 ContainerCreating 0 2s app=nginx
rc-test-sfc8r 1/1 Running 0 36m app=nginx
列出 pod，会发现有四个pod，其中一个 app=nginx2 已经不由 ReplicationController管理了，其他三个是。
更改 ReplicationControlle 的标签选择器
如果修改了 ReplicationController 的标签选择器，它会让所有的 pod 脱离 ReplicationController 的管理，导致它 创建三个新的 pod。
修改 ReplicationControlle 的 pod 模板
ReplicationController 的 pod 模板可以随时修改。更改 pod 模板就像用一个 pod 替换另－个。它只会影响你之后创建的pod，并且不会影响你已经创建的 pod。要修改旧的 pod，你需要删除它们，并让 ReplicationController 根据新模板将其替换为新的 pod。
## 将在你的默认文本编辑器中打开 ReplicationController 的 YAML 配置
kc edit rc rc-test
配置 kubectl edit 使用不同的文本编辑器
可以通过设直 KUBE_EDITOR 环境变量来告诉 kubectl 使用你期望的文本编辑器。例如：
export KUBE_EDITOR="/usr/bin/nano"
调整 rc 的 scale 来水平伸缩 pod
伸缩 pod 的数量规模就和在ReplicationController 资源中更改 Replicas 宇段的值一样简单。更改之后， ReplicationController 将会看到存在太多 的 pod 并删除其中的一部分（缩容时），或者看到它们数目太少并创建 pod（扩容时）。
## 使用 kubectl scale 命令
kc scale rc rc-test --replicas=8
## 也可以使用 kc edit 来修改
kc edit rc rc-test
删除一个 ReplicationController
当你通过 kubectl delete 删除ReplicationController 时，pod 也会被删除。但是由于由 ReplicationController 创建的 pod 不是 ReplicationController 的组成部分，只是由其进行管理，因此可以只删除 ReplicationController 并保持 pod 运行。
kc delete rc rc-test --cascade=false
ReplicaSet 控制器
最初，ReplicationController 是用于复制和在异常时重新调度节点的唯一 Kubernetes 组件，后来又引入了一个名为 ReplicaSet 的类似资源。它是新一代的 ReplicationController，并且将其完全替换掉， ReplicationController 最终将被弃用。
ReplicaSet 和 ReplicationController 区别
ReplicaSet 的行为与 ReplicationController 完全相同，但 pod 选择器的表达能力更强。虽然 ReplicationController 的标签选择器只允许包含某个标签的匹配 pod，但 ReplicaSet的选择器还允许匹配缺少某个标签的 pod ，或包含特定标签名的 pod，不管其值如何。
同样，无论 ReplicationController 的值如何，ReplicationController 都无法仅基于标签名的存在来匹配 pod，而 ReplicaSet 则可以。例如，ReplicaSet 可匹配所有包含 名为 env 的标签的 pod，无论 ReplicaSet 的实际值是什么（可以理解为 env＝* ）。
定义 ReplicaSet
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: rs-test
spec:
## pod实例的目标数量
replicas: 3
selector:
## 使用简单的matchLabels选择器
matchLabels:
app: nginx
## 创建新 pod 所用的pod模板
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: test-rs-nginx
image: nginx
ports:
- containerPort: 80
protocol: TCP
首先要注意的是 ReplicaSet 不是 v1 API 的一部分，因此你需要确保在创建资源时指定正确的 apiVersion。你正在创建一个类型为ReplicaSet 的资源，它的内容与之前创建的 ReplicationController 的内容大致相同。
唯一的区别在选择器中。不必在 selector 属性中直接列出 pod 需要的标签，而是在 selector.matchLabels 下指定它们。这是在 ReplicaSet 中定义标签选择器的更简单的方式。
## 列出所有rs
kc get rs
## 查看指定rs的详情
kc describe rs rs-test
使用 ReplicaSet 的更富表达力的标签选择器
ReplicaSet 相对于 ReplicationController 的主要改进是它更具表达力的标签选择器。上面用了较简单的 matchLabels 选择器。现在，将用更强大的matchExpressions 属性来重写选择器。
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: rs-test-matchexpressions
spec:
## pod实例的目标数量
replicas: 3
selector:
matchExpressions:
- key: app
operator: In
values:
- nginx
## 创建新 pod 所用的pod模板
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: test-rs-nginx
image: nginx
ports:
- containerPort: 80
protocol: TCP
可以给选择器添加额外的表达式。如上面所写， 每个表达式都必须包含一个 key、一个 operator（运算符〉，并且可能还有一个 values 的列表（取决于运算符）。你会看到四个有效的运算符：
- In：Label 的值必须与其中一个指定的 values 匹配。
- NotIn：Label 的值与任何指定的 values 不匹配。
- Exists：pod 必须包含一个指定名称的标签,值不重要。使用此运算符时，不应指定 values 字段。
- DoesNotExist：pod 不得包含有指定名称的标签。values 属性不得指定。
如果指定了多个表达式，则所有这些表达式都必须为 true 才能使选择器与 pod 匹配。如果同时指定 matchLabels 和 matchExpressions，则所有标签都必须匹配， 并且所有表达式必须计算为 true 以使该 pod 与选择器匹配。
DaemonSet 在每个节点上运行一个pod
Replicationcontroller 和 ReplicaSet 都用于在 Kubernetes 集群上运行部署特定数量的 pod。但是，当你希望 pod 在集群中的每个节点上运行时，例如，希望在每个节点上运行日志收集器和资源监控器。
要在所有集群节点上运行一个 pod，需要创建一个 DaemonSet 对象。DaemonSet 确保创建足够的 pod，并在自己的节点上部署每个 pod。
尽管 ReplicaSet 或 ReplicationController 确保集群中存在期望数量的 pod 副本，但 DaemonSet 并没有期望的副本数的概念。它不需要，因为它的工作是确保一个 pod 匹配它的选择器并在每个节点上运行。
如果节点下线，DaemonSet 不会在其他地方重新创建 pod。但是，当将一个新节点添加到集群中时，DaemonSet 会立刻部署一个新的 pod 实例。如果删除了一个 pod，那么它也会重新 创建一个新的 pod。与 ReplicaSet 一样， DaemonSet 从配置的 pod 模板创建 pod。
默认情况下 DaemonSet 是将 pod 部署到集群中的所有节点上，如果想要指定 pod 只在部分节点上运行。可以通过 pod 模板中的 nodeSelector 属性指定。
节点可以被设置为不可调度的，防止 pod 被部署到节点上。 DaemonSet 甚至会将 pod 部署到这些节点上，因为无法调度的属性只会被调度器使用，而 DaemonSet 管理 的 pod 则 完全绕过调度器。这是预期的，因为 DaemonSet 的目的是运行系统服务，即使是在不可调度的节点上，系统服务通常也需要运行。
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: ds-test
spec:
## pod实例的目标数量
replicas: 3
selector:
## 使用简单的matchLabels选择器
matchLabels:
app: nginx
## 创建新 pod 所用的pod模板
template:
metadata:
labels:
app: nginx
spec:
## 节点选择器，只会在满足条件的 node 上部署 pod
nodeSelector:
cpu: gpu
containers:
- name: test-ds-nginx
image: nginx
ports:
- containerPort: 80
protocol: TCP
## 创建 ds
kc create -f test-nginx-daemon-set-controller.yaml --validate=false
## 列出 ds
kc get ds
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
ds-test 1 1 1 1 1 cpu=gpu 2m50s
## 如果把节点上的标签修改了 pod 会立即停止
kc label node 192.168.1.230 cpu=no --overwrite
## 再次列出 ds
kc get ds
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
ds-test 0 0 0 0 0 cpu=gpu 5m34s
网友评论