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

殺死它們以便它們重新安排在另一個節點上是非常好的。它們都可以重新安排，除了流暢的豆莢，它們綁定到每個節點。