Kubernetes - 什么是kube系统吊舱，可以安全删除它们吗？

Question

我目前有一个群集运行在我用3个节点创建的GCloud上。 这是我所得到的，当我运行kubectl describe nodes

Name:   node1 
Capacity: 
cpu:  1 
memory: 3800808Ki 
pods:  40 
Non-terminated Pods:  (3 in total) 
Namespace   Name         CPU Requests CPU Limits Memory Requests Memory Limits 
─────────   ────         ──────────── ────────── ─────────────── ───────────── 
default   my-pod1         100m (10%) 0 (0%)  0 (0%)  0 (0%) 
default   my-pod2        100m (10%) 0 (0%)  0 (0%)  0 (0%) 
kube-system   fluentd-cloud-logging-gke-little-people-e39a45a8-node-75fn  100m (10%) 100m (10%) 200Mi (5%) 200Mi (5%) 
Allocated resources: 
(Total limits may be over 100%, i.e., overcommitted. More info: http://releases.k8s.io/HEAD/docs/user-guide/compute-resources.md) 
CPU Requests CPU Limits Memory Requests Memory Limits 
──────────── ────────── ─────────────── ───────────── 
300m (30%) 100m (10%) 200Mi (5%) 200Mi (5%) 

Name:   node2 
Capacity: 
cpu:  1 
memory: 3800808Ki 
pods:  40 
Non-terminated Pods:  (4 in total) 
Namespace   Name         CPU Requests CPU Limits Memory Requests Memory Limits 
─────────   ────         ──────────── ────────── ─────────────── ───────────── 
default   my-pod3        100m (10%) 0 (0%)  0 (0%)  0 (0%) 
kube-system   fluentd-cloud-logging-gke-little-people-e39a45a8-node-wcle  100m (10%) 100m (10%) 200Mi (5%) 200Mi (5%) 
kube-system   heapster-v11-yi2nw       100m (10%) 100m (10%) 236Mi (6%) 236Mi (6%) 
kube-system   kube-ui-v4-5nh36       100m (10%) 100m (10%) 50Mi (1%) 50Mi (1%) 
Allocated resources: 
(Total limits may be over 100%, i.e., overcommitted. More info: http://releases.k8s.io/HEAD/docs/user-guide/compute-resources.md) 
CPU Requests CPU Limits Memory Requests Memory Limits 
──────────── ────────── ─────────────── ───────────── 
400m (40%) 300m (30%) 486Mi (13%) 486Mi (13%) 

Name:   node3 
Capacity: 
cpu:  1 
memory: 3800808Ki 
pods:  40 
Non-terminated Pods:  (3 in total) 
Namespace   Name         CPU Requests CPU Limits Memory Requests Memory Limits 
─────────   ────         ──────────── ────────── ─────────────── ───────────── 
kube-system   fluentd-cloud-logging-gke-little-people-e39a45a8-node-xhdy  100m (10%) 100m (10%) 200Mi (5%) 200Mi (5%) 
kube-system   kube-dns-v9-bo86j       310m (31%) 310m (31%) 170Mi (4%) 170Mi (4%) 
kube-system   l7-lb-controller-v0.5.2-ae0t2      110m (11%) 110m (11%) 70Mi (1%) 120Mi (3%) 
Allocated resources: 
(Total limits may be over 100%, i.e., overcommitted. More info: http://releases.k8s.io/HEAD/docs/user-guide/compute-resources.md) 
CPU Requests CPU Limits Memory Requests Memory Limits 
──────────── ────────── ─────────────── ───────────── 
520m (52%) 520m (52%) 440Mi (11%) 490Mi (13%) 

现在，你可以看到，我有3个吊舱，2节点1和1个节点2上。我想要做的是移动node1上的所有窗格并删除其他两个节点。但是，似乎有一些Pod属于kube-system命名空间，我不知道删除它们可能会产生什么效果。

我可以告诉大家，名为fluentd-cloud-logging...或heapster..豆荚用于记录和计算机资源的用法，但我真的不知道，如果我能kube-dns-v9-bo86j和l7-lb-controller-v0.5.2-ae0t2移动荚到另一个节点没有影响。

任何人都可以帮助一些见解，我应该如何继续？

非常感谢。

Answer 1

如果您想缩小集群的大小，只需删除三个节点中的两个，然后让系统重新安排在删除节点时丢失的任何豆荚。如果剩余节点上没有足够的空间，您可能会看到吊舱永久挂起。将kube-system挂接挂起并不理想，因为它们中的每一个都为您的集群执行“系统功能”（例如DNS，监视等），如果没有它们运行您的集群将无法正常运行。

如果您不需要使用gcloud container clusters update命令的功能，则也可以禁用某些系统窗格。

Answer 2

杀死它们以便它们重新安排在另一个节点上是非常好的。它们都可以重新安排，除了流畅的豆荚，它们绑定到每个节点。