您好,登錄后才能下訂單哦!
今天小編給大家分享一下Kuberentes1.9的相關知識點有哪些的相關知識點,內容詳細,邏輯清晰,相信大部分人都還太了解這方面的知識,所以分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后有所收獲,下面我們一起來了解一下吧。
新的“特性”實際上并不是新的,而是基于為了足夠穩定生產所使用現有功能的改進,如工作負載的API(DaemonSet、部署ReplicaSet,StatefulSet API),它提供了許多現實環境的基礎工作負載,或已經進入到相關的測試階段,這意味著它們是默認啟用的,比如支持Windows服務器的工作負載。
然而只是進入了代碼庫,例如,Kubernetes 1.9包含了容器存儲接口(CSI)和IPv6支持的Alpha實現。
在決定升級到Kuberentes 1.9之前,必須備份Etcd數據,這是非常重要的一件事,因為許多用于部署和升級Kubernetes默認的工具是Etcd3.1,由于Etcd不支持降級,所以如果決定降級Kubernetes部署,那么就無法回到以前的版本,因此雖然可以在不執行備份的情況下升級,但也有一些風險存在。 下面就來了解一下Kubernetes 1.9每個區域的變化細節。
認證和授權訪問Kubernetes的過程有了一系列的改進:
首先可以使用集群角色聚合將權限添加到內置的RBAC管理/編輯視圖角色中,這些角色適用于整個集群,可以更容易管理誰可以或不能執行某些操作。
此外,授權本身也得到了改進:列如如果一個規則拒絕進入Fires,那么沒有理由對鏈中的其余規則進行評估,這樣其他的規則就會被短路。
所有這些都取決于可擴展性,在這個周期中,社區通過添加一種新型的控制Webhook來提高可擴展性。 當試圖在Kuberentes中執行操作時,入檢查訪問和檢查名稱空間時,接收控制器是發生的不同組件,Webhook使得用戶可以通過HTTP POST請求與Kuberentes進行通信;可以發送請求,當某些事件發生時,Kuberentes會進行回調。
在這個版本中,團隊致力于“變異”的Webhook,這使得更靈活的進入控制插件得以實現,因為他們讓Kuberentes在必要的時候做出改變,允許更大的擴展性。
使用戶能夠創建自己的“對象”,可以被Kubernetes操縱,同時也已被增強,允許更容易的進行創建和更加可靠。這包括Kubernetes repo中一個新的示例控制器自定義資源定義,以及新的元數據字段選擇器、幫助生成代碼腳本,以及對已定義資源的驗證,用來提高總體解決方案的可靠性。另外,以前的版本只允許引用自定義資源的組,現在可以獲得單個實例。
隨著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。
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的支持,意味著用戶現在可以從私有容器注冊表中提取圖像。
如果是系統管理員或運維人員,那么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,所以用戶不用糾結于這個手動操作。
Kubernetes 1.9更改了如何配置kube - scheduler,并向配置文件中添加一個新的- config標志。該文件是Kubernetes期望在未來版本中找到配置值的地方;現在大多數其他的kube調度器標志現在已經被棄用。 此版本還提供了更有效地調度需要擴展資源(如gpu)的工作負載的能力; 調度SIG還完成了一些其他的個別更改,例如在低優先級的pod之前調度更高優先級的pod,以及一個pod能夠監聽多個IP地址的能力。
存儲在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) 可以在容器中運行而不是在主機上運行的工具
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使用Kubernetes,用戶會發現v1.9中的配置要簡單得多。自動檢測OpenStack服務和版本現在是“只要可行”的規則——在本例中意味著塊存儲API版本和安全組——用戶現在可以將OpenStack負載平衡配置為服務v2提供者。支持OpenStack Octavia v2和中子LBaaS v2。
AWS的小組(SIG)一直致力于改善Kubernetes與EBS卷的集成。用戶將不再使用被調度到“附加”狀態的卷的工作負載。相反,節點將被“污染”,以便管理員能夠處理問題。團隊建議觀看這些污染。此外,當停止節點時,卷將自動分離。
此外,Kubernetes現在支持AWS的新NVMe實例類型,以及使用AWS網絡負載均衡器,而不是彈性負載均衡器。
如果用戶在Windows上使用Kubernetes,特別是在Azure上,會發現安裝卷的失誤率更小,因為您現在可以創建Windows掛載路徑,并消除驅動器號的需要,這是無限的掛載點。
還可以使用service . beta.kubernetes顯式地為公共IP地址設置Azure DNS標簽。在使用Azure NSG規則時,仍然能夠使用Azure NSG規則,以確保只允許外部訪問負載均衡器的IP地址。當更新時,負載均衡器還被增強以考慮更多NSG規則的屬性,包括協議、sourceUNK ange和DestinationAddressPrefs。(以前這些字段的更改不會觸發更新,因為負載均衡器認識不到已經發生了更改。)
以上就是“Kuberentes1.9的相關知識點有哪些”這篇文章的所有內容,感謝各位的閱讀!相信大家閱讀完這篇文章都有很大的收獲,小編每天都會為大家更新不同的知識,如果還想學習更多的知識,請關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。