共計 4442 個字符，預計需要花費 12 分鐘才能閱讀完成。

今天丸趣 TV 小編給大家分享一下 Kuberentes1.9 的相關知識點有哪些的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

Kubernetes 1.9

新的“特性”實際上并不是新的，而是基于為了足夠穩定生產所使用現有功能的改進，如工作負載的 API（DaemonSet、部署 ReplicaSet，StatefulSet API），它提供了許多現實環境的基礎工作負載，或已經進入到相關的測試階段，這意味著它們是默認啟用的，比如支持 Windows 服務器的工作負載。

然而只是進入了代碼庫，例如，Kubernetes 1.9 包含了容器存儲接口（CSI）和 IPv6 支持的 Alpha 實現。

1 在升級之前需要做什么

在決定升級到 Kuberentes 1.9 之前，必須備份 Etcd 數據，這是非常重要的一件事，因為許多用于部署和升級 Kubernetes 默認的工具是 Etcd3.1，由于 Etcd 不支持降級，所以如果決定降級 Kubernetes 部署，那么就無法回到以前的版本，因此雖然可以在不執行備份的情況下升級，但也有一些風險存在。下面就來了解一下 Kubernetes 1.9 每個區域的變化細節。

2 身份驗證和 API Machinery

認證和授權訪問 Kubernetes 的過程有了一系列的改進：

首先可以使用集群角色聚合將權限添加到內置的 RBAC 管理 / 編輯視圖角色中，這些角色適用于整個集群，可以更容易管理誰可以或不能執行某些操作。

此外，授權本身也得到了改進：列如如果一個規則拒絕進入 Fires，那么沒有理由對鏈中的其余規則進行評估，這樣其他的規則就會被短路。

所有這些都取決于可擴展性，在這個周期中，社區通過添加一種新型的控制 Webhook 來提高可擴展性。當試圖在 Kuberentes 中執行操作時，入檢查訪問和檢查名稱空間時，接收控制器是發生的不同組件，Webhook 使得用戶可以通過 HTTP POST 請求與 Kuberentes 進行通信；可以發送請求，當某些事件發生時，Kuberentes 會進行回調。

在這個版本中，團隊致力于“變異”的 Webhook，這使得更靈活的進入控制插件得以實現，因為他們讓 Kuberentes 在必要的時候做出改變，允許更大的擴展性。

3 定制資源

使用戶能夠創建自己的“對象”，可以被 Kubernetes 操縱，同時也已被增強，允許更容易的進行創建和更加可靠。這包括 Kubernetes repo 中一個新的示例控制器自定義資源定義，以及新的元數據字段選擇器、幫助生成代碼腳本，以及對已定義資源的驗證，用來提高總體解決方案的可靠性。另外，以前的版本只允許引用自定義資源的組，現在可以獲得單個實例。

4 連網

隨著 IPv4 地址的耗盡，在 Kubernetes 1.9 中看到對 IPv6 支持的開始是個好消息。這種支持仍然在 Alpha 中，并且有很大的局限性，比如缺少雙棧支持和沒有 HostPorts，然而這是一個開始。此外，隨著 CoreDNS 1.0 的發布，用戶可以選擇使用它作為 kube – dns 的替代選擇。要安裝它，需要 CLUSTER_DNS_CORE_DNS 為“true”。但是要注意的是這種支持是實驗性的，這意味著它可以隨時更改或被刪除。

其他的網絡改進包括 - cleanup- ipvs 標志，它決定了 kube – proxy 是否會在啟動時刷新所有現有的 Ipvs 規則(就像它在默認的版本中一樣)，以及一個新的 PodAntiAffinity kube- dns 注釋來增強恢復力。用戶還可以通過向主機的 / etc/ resolvei 添加“選項”來定制 pod 的 DNS 客戶端的行為。conf 或 - resolv- conf，這將使它們傳播到 pod resolve.conf。

5 集群生命周期

Federation SIG 已經被重命名為集群生命周期，并一直致力于將 kubeadm 部署工具提高到產品質量。該項目雖然有效，但應用實踐相對較短，包括一些新增的 alpha 特性，比如對 CoreDNS 的支持、IPv6 和動態 Kubelet 配置。要在配置中安裝 CoreDNS 而不是 kube – dns，將 CLUSTER_DNS_CORE_DNS 設置為“true”。

Kubeadm 還獲得了一些額外的新特性，例如 - print-join- command，這使得在初始集群部署后獲得必要的信息以添加新節點，支持 Kubelet 動態配置，以及將 Windows 節點添加到集群的能力。

該小組還負責集群 API，用于“聲明性的 kubernet -style API 來集群創建、配置和管理”。它提供可選的，可添加的功能，在核心庫伯內特斯的頂部。

如果用戶正在構建多集群的安裝，會很高興知道 kubefed，它允許用戶創建一個控制平面來添加、刪除和管理聯邦集群，已經獲得了幾個新標志，這些標志可以讓用戶對它的安裝方式和操作方式有更多的控制。- nodeselector 標志讓用戶決定控制器的安裝位置，以及添加對 - imagepullsecrets 和 - imageplpolicy 的支持，意味著用戶現在可以從私有容器注冊表中提取圖像。

6 節點的功能

如果是系統管理員或運維人員，那么 Kubernetes 1.9 可以使編寫配置變得更容易一些，Kubelet 的特性門現在表示為 KubeletConfiguration 中的映射，而不是一串鍵值對。此外，現在可以設置多個 manifest url header，或者使用 - manifest-url- header 標志或 KubeletConfiguration 中的 manifest . header 字段。

而且 deviceplugin 會一直延伸到更優雅地處理插件設備全生命周期, 包括顯式 cm.GetDevicePluginResourceCapacity()函數, 它可以更準確地確定哪些資源是不活躍的, 從而使可用資源的更精確的視圖。它還確保了設備被正確地移除，即使 kubelet 重新啟動，并從 kubelet 傳送到設備插件。最后，它確保即使在設備插件刪除和 kubelet 重新啟動之后，預定的 pods 仍然可以繼續運行。

但值得注意的是，根據發布說明，“Kubelet 不再從節點狀態移除未注冊的擴展資源能力；當要自己刪除插件時，集群管理員必須手動刪除通過設備插件暴露的擴展資源，Kubernetes 1.9 包括許多對日志和監視的增強，包括 pod 級的 CPU、內存和本地臨時存儲。此外，狀態摘要網絡值，以前只考慮 eth0，現在考慮所有的網絡接口。

新版本還減輕了一些用戶問題，增加了對默認管理和編輯角色的讀 / 寫權限，并增加了對 podUNK tionbudget 的讀權限。策略到視圖角色。

最后, 團隊取得了 CRI 日志解析在 pkg/kubelet/apis/cri/logs，所以用戶不用糾結于這個手動操作。

7 調度

Kubernetes 1.9 更改了如何配置 kube – scheduler，并向配置文件中添加一個新的 - config 標志。該文件是 Kubernetes 期望在未來版本中找到配置值的地方；現在大多數其他的 kube 調度器標志現在已經被棄用。此版本還提供了更有效地調度需要擴展資源 (如 gpu) 的工作負載的能力；調度 SIG 還完成了一些其他的個別更改，例如在低優先級的 pod 之前調度更高優先級的 pod，以及一個 pod 能夠監聽多個 IP 地址的能力。

8 存儲

存儲在 Kubernetes 1.9 中的重大更新是添加了容器存儲接口 (CSI) 的 alpha 實現。CSI 是 Kubernetes、Docker、Mesosphere 和 Cloud Foundry 社區之間的一個聯合項目，它的目的是提供一個單一的 API，存儲供應商可以在任何支持 CSI 的編排中實現其產品在“out of the box”中工作。根據 Kubernetes 存儲 SIG 的說法，“CSI 將會像部署一個 pod 一樣輕松地安裝新的容量插件，并且允許第三方存儲提供商開發他們的插件，而無需將代碼添加到核心庫伯內特斯代碼庫中。用戶可以通過實例化一個卷作為 CSIVolumeSource 來使用這個新功能。

存儲 SIG 還增加了幾個新功能，包括:

GCE PD、Ceph RBD、AWS EBS 和 OpenStack Cinder 卷的容量大小 體積作為原始塊設備(光纖通道僅為 Kubernetes 1.9) 可以在容器中運行而不是在主機上運行的工具

9 云供應商

Kubernetes 1.9 的一個重要變化是，如果用戶手動部署 Kubernetes，必須為 - cloud- provider 標志設置一個值；默認情況不再是“自動檢測”。允許的選擇是：AWS、Azure、Cloudstack、Fake、Gce、Mesos、Openstack、Ovirt、Photon、Rackspace、Vsphere、以及 Unset；自動檢測將在 Kubernetes 1.10 中被移除。(如果用 Minikube 或 Kubeadm 之類的工具來安裝 Kubernetes，不必擔心這個問題。) 此外，該版本中的一些更改是針對個別云供應商的。

OpenStack

如果使用 OpenStack 使用 Kubernetes，用戶會發現 v1.9 中的配置要簡單得多。自動檢測 OpenStack 服務和版本現在是“只要可行”的規則——在本例中意味著塊存儲 API 版本和安全組——用戶現在可以將 OpenStack 負載平衡配置為服務 v2 提供者。支持 OpenStack Octavia v2 和中子 LBaaS v2。

AWS

AWS 的小組 (SIG) 一直致力于改善 Kubernetes 與 EBS 卷的集成。用戶將不再使用被調度到“附加”狀態的卷的工作負載。相反，節點將被“污染”，以便管理員能夠處理問題。團隊建議觀看這些污染。此外，當停止節點時，卷將自動分離。

此外，Kubernetes 現在支持 AWS 的新 NVMe 實例類型，以及使用 AWS 網絡負載均衡器，而不是彈性負載均衡器。

Azure

如果用戶在 Windows 上使用 Kubernetes，特別是在 Azure 上，會發現安裝卷的失誤率更小，因為您現在可以創建 Windows 掛載路徑，并消除驅動器號的需要，這是無限的掛載點。

還可以使用 service . beta.kubernetes 顯式地為公共 IP 地址設置 Azure DNS 標簽。在使用 Azure NSG 規則時，仍然能夠使用 Azure NSG 規則，以確保只允許外部訪問負載均衡器的 IP 地址。當更新時，負載均衡器還被增強以考慮更多 NSG 規則的屬性，包括協議、sourceUNK ange 和 DestinationAddressPrefs。(以前這些字段的更改不會觸發更新，因為負載均衡器認識不到已經發生了更改。) 

以上就是“Kuberentes1.9 的相關知識點有哪些”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，丸趣 TV 小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注丸趣 TV 行業資訊頻道。