根據(jù)Kubernetes官方計劃，明日Kubernetes 1.18版本即將發(fā)布!

一些將對社區(qū)產(chǎn)生影響的新特性日漸完善，如 KSA（Kubernetes Service Account） tokens的OIDC發(fā)現(xiàn)和對Windows節(jié)點的支持。此外，一些在Alpha狀態(tài)下運行了很久的特性，也重新成為新的焦點，如ingress或API Server網(wǎng)絡(luò)代理。1.18版本共有13個特性逐漸穩(wěn)定，這是所有新變化的1/3! 究竟都有哪些強大且新奇的功能更新，一起拭目以待！

翻譯：小雀

技術(shù)校對：Jay/曉曦

Kubernetes 1.18 精選

在這個版本中，這些功能看起來最令人興奮：

#1393 OIDC discovery for service account token issuer

使用Kubernetes API令牌作為通用身份驗證機制，可以改變企業(yè)組建基礎(chǔ)設(shè)施的方式。它允許我們進一步集成服務(wù)，如集群之間的通信，通過簡化外部不必要的身份驗證服務(wù)來簡化設(shè)置。

# 1513 CertificateSigningRequest API

Certificate API是用于核心組件的另一特性，已開始用于第三方服務(wù)。這一增強是Kubernetes適應(yīng)社區(qū)需求的例子，它使得提供證書更便捷，更安全。

#1441 kubectl調(diào)試

在調(diào)試運行pods時，新命令將帶來巨大的差異。創(chuàng)建調(diào)試容器或使用不同配置重新部署pod，這些常見任務(wù)從此刻起將變得更快。

#1301在Windows上實現(xiàn)RuntimeClass

能夠指定哪些pod必須在Windows機器上運行，這將允許在同一集群上混合Windows和Linux工作負載，從而打開了新的維度。

#1001在Windows上支持CRI ContainerD

這是提高Windows節(jié)點上Kubernetes兼容性的一大步，不過我們在將來的版本中才能看到它的全貌。通過這樣的小升級，Kubernetes展示出他們對Windows支持的認真態(tài)度。

Kubernetes 1.18核心

#1393為服務(wù)帳戶令牌發(fā)布方提供OIDC發(fā)現(xiàn)

階段:Alpha

功能組:身份驗證

Kubernetes服務(wù)帳戶(KSA)可以使用令牌(JSON Web令牌或JWT)對KubernetesAPI進行身份驗證，例如使用kubectl --token <the_token_string>.但是，Kubernetes API是目前唯一能夠驗證這些令牌的服務(wù)。

由于Kubernetes API服務(wù)器不能(也不應(yīng)該)從公共網(wǎng)絡(luò)訪問，一些工作負載必須使用獨立的系統(tǒng)進行身份驗證。比如，跨集群身份驗證。

此增強的目的是提高KSA令牌的實用性，允許集群之外的服務(wù)用作通用身份驗證方法，而無需重載API服務(wù)器。為實現(xiàn)這點，API服務(wù)器提供了一個OpenID Connect (OIDC)發(fā)現(xiàn)文檔，其中包含令牌公鑰和其他數(shù)據(jù)。驗證者可以使用這些密鑰來驗證KSA令牌。

使用ServiceAccountIssuerDiscovery功能開關(guān)啟用OIDC發(fā)現(xiàn)，并且進行一些配置使其工作。

#853 HPA可配置伸縮速率

階段：Alpha

功能組：自動伸縮

Horizontal Pod Autoscaler（HPA）可以自動縮放資源中的Pod數(shù)量，調(diào)整工作負載需求。目前，只能為整個群集定義全局資源伸縮。而無法為你希望選擇的核心服務(wù)提供資源調(diào)節(jié)。

現(xiàn)在，將行為添加到HPA配置中：

在上述示例中，當(dāng)需要增加時，pod每15秒可以翻倍。當(dāng)需要減少時，每分鐘可以移除4個pod。

# 1513 CertificateSigningRequest API

階段:Beta版的重大變化

功能組:身份驗證

每個Kubernetes集群都有根證書頒發(fā)權(quán)限組件，用于保護核心組件之間的通信，這些組件由Certificates API處理。最終它開始用于為非核心用例提供證書。

這一改進的目的是適應(yīng)新的形勢，改進簽署進程及其安全。

注冊中心不僅需要確保實際請求者提交了證書簽名請求(CSR);還要確保請求者具有提交請求的適當(dāng)權(quán)限。

調(diào)度

#1451運行多個調(diào)度配置文件

階段:Alpha

功能組:調(diào)度

不是Kubernetes集群的所有工作負載都是相同的，有的希望將web服務(wù)器分布在盡量多的節(jié)點上，也可能希望同一節(jié)點捆綁更多的延遲敏感資源。這就是為什么可以在同一集群內(nèi)配置多個調(diào)度器，并指示每個pod使用哪個調(diào)度器的原因。

但是，這可能會導(dǎo)致競爭，因為每個調(diào)度器在特定時刻可能有不同的集群視圖。

此增強允許使用不同的配置或配置文件運行一個調(diào)度器，每個調(diào)度器都有自己的schedulerName。Pods將使用schedulerName來定義要使用什么配置文件，它將由同一個調(diào)度器來完成這項工作，從而避免競爭。

#895 Pod跨故障域均勻擴展

階段:升級到Beta版

功能組:調(diào)度

使用topologySpreadConstraints，可以定義規(guī)則，在多區(qū)域集群中均勻分布pods，保證高可用性，并提高資源利用率。

#1258添加可配置的默認偶數(shù)Pod擴展規(guī)則

階段:Alpha

功能組:調(diào)度

為了充分利用even pod的擴展，每一個pod都需要自己的擴展規(guī)則。此增強功能允許定義全局defaultConstraints，這些約束將在群集級別應(yīng)用于，所有未定義自己的topologySpreadConstraints的pods。

#166基于污點的驅(qū)逐

階段：穩(wěn)定版

功能組：調(diào)度

在Kubernetes 1.13中，基于污點的驅(qū)逐從alpha階段轉(zhuǎn)移到beta階段。啟用此功能時（TaintBase Devitions=true in--feature gates），NodeController（或kubelet）會自動添加污點，并禁用以前基于就緒NodeCondition從節(jié)點逐出pod的邏輯。

節(jié)點

#1539擴展Hugepage特性

階段：穩(wěn)定版的重要變化

功能組：節(jié)點

HugePages是一種機制，它可以預(yù)留具有預(yù)定義大小的大內(nèi)存塊，由于硬件優(yōu)化，訪問速度更快。這對于處理內(nèi)存中的大數(shù)據(jù)集或?qū)?nèi)存訪問延遲敏感的應(yīng)用（如數(shù)據(jù)庫或虛擬機）尤其有用。

在Kubernetes 1.18中，該特性增加了兩個增強功能。

首先，pod現(xiàn)在可以請求不同大小的HugePages。

其次，已經(jīng)對HugePages進行了容器隔離，解決pod可能會使用比請求更多的內(nèi)存，從而導(dǎo)致資源匱乏的問題。

#688 Pod開銷:計算綁定到Pod沙箱的資源，但不是特定容器

階段:升級到Beta版

功能組:節(jié)點

除了請求的資源外，pod還需要額外資源來維護其運行時環(huán)境。

啟用Pod Overhead特性后，Kubernetes在調(diào)度pod時將考慮這一開銷。Pod overhead將在開始時被計算并固定下來，它與Pod的運行時類相關(guān)聯(lián)。

#693節(jié)點拓撲管理器

階段:升級到Beta版

功能組:節(jié)點

機器學(xué)習(xí)、科學(xué)計算和金融服務(wù)都是計算密集型系統(tǒng)，需要超低延遲。這些類型的工作負載需要將進程隔離到一個CPU內(nèi)核，而不是在內(nèi)核之間跳轉(zhuǎn)或與其他進程共享。

節(jié)點拓撲管理器是一個kubelet組件，它集中協(xié)調(diào)硬件資源分配。當(dāng)前的方法將此任務(wù)分配給幾個組件(CPU管理器、設(shè)備管理器、CNI)，有時會導(dǎo)致分配不是最優(yōu)化。

#950為啟動緩慢的pod增加啟動存活探測延遲

階段:升級到Beta版

功能組:節(jié)點

探測器允許Kubernetes監(jiān)視應(yīng)用程序的狀態(tài)。如果pod啟動時間過長，探測器會認為pod已經(jīng)死亡，導(dǎo)致一次重啟。該特性允許定義startupProbe，推遲所有其他探測，來保證pod完成啟動。例如，“在給定的HTTP端點可用之前，不要測試活性”。

網(wǎng)絡(luò)

#752EndpointSlice API

階段：Beta版的重大變化

功能組：網(wǎng)絡(luò)

新的Endpoint Slice API將端點拆分為多個endpoint slice資源。這解決了當(dāng)前API中與大型endpoints對象相關(guān)的許多問題。新的API還支持未來的其他特性，如每個pod支持多個ip。

#508 增加IPv6支持

階段:升級到Beta版

功能組:網(wǎng)絡(luò)

早在Kubernetes 1.9就引入了對IPv6集群的支持。這一特性已在社區(qū)進行過廣泛測試，現(xiàn)在升級到Beta版。

#1024NodeLocal DNSCache升級到GA版

階段：GA

功能組：網(wǎng)絡(luò)

NodeLocalDNSCache通過在集群節(jié)點上以Daemonset運行DNS緩存代理來提高集群DNS性能，該節(jié)點作為守護進程，從而避免了iptables DNAT規(guī)則和連接跟蹤。該本地緩存代理查詢kube-dns服務(wù)，以查找集群主機名的緩存缺失（默認情況下后綴為cluster.local）。

#1453Graduate Ingress to V1

階段：升級到Beta版

功能組：網(wǎng)絡(luò)

Ingress資源將外部HTTP和HTTPS路由暴露為服務(wù)，集群中的其他服務(wù)可以訪問這些路由。

API對象包含在Kubernetes 1.1中，是事實上的穩(wěn)定特性。這次修改消除了Ingress實現(xiàn)之間的不一致，使它開始進入GA階段。

例如，現(xiàn)在可以定義一個pathtype，以顯式地聲明路徑是否應(yīng)被視為前綴或完全匹配。如果Ingress中的多個路徑匹配一個請求，那么最長的匹配路徑優(yōu)先。

此外，http://kubernetes.io/ingres.class注釋已被棄用。現(xiàn)在使用新的ingresClassname字段和IngresClass資源。

#1507將AppProtocol添加到Services和Endpoints

階段：GA

功能組：網(wǎng)絡(luò)

EndpointSlice API在Kubernetes 1.17中添加了新的AppProtocol字段，允許為每個端口指定應(yīng)用協(xié)議。此增強將該字段引入ServicePort和EndpointPort資源，替換體驗不好的非標(biāo)準(zhǔn)注解。

Kubernetes1.18 API

#1040 API服務(wù)器請求的優(yōu)先級和公平性

階段: Alpha

功能組:api-machinery

高負載期間，Kubernetes API服務(wù)器負責(zé)管理和維護任務(wù)?，F(xiàn)有的——max-requests-inflight和max-mutating-requests-inflight命令行標(biāo)志可以限制傳入的請求，但粒度太粗，在高流量期間會過濾掉重要的請求。

APIPriorityAndFairness功能開關(guān)在apiserver中啟用了新的max-in-flight請求處理程序。使用FlowSchema對象定義不同類型的請求，RequestPriority對象分配資源。

例如，垃圾收集器就是一個低優(yōu)先級的服務(wù):

因此可以分配很少的資源給它：

自維護請求具有更高的優(yōu)先級：

可以在增強建議中找到更多示例。

#1601 client-go簽名重構(gòu)，實現(xiàn)標(biāo)準(zhǔn)化選項和上下文處理

階段:穩(wěn)定版的重大變化

功能組:api-machinery

在client go上進行了一些代碼重構(gòu)，許多核心二進制文件使用這個庫連接Kubernetes API，以保持方法簽名的一致性。

包括向某些方法添加上下文對象，該對象跨API邊界和進程之間carries request-scoped values。訪問對象簡化了一些特性的實現(xiàn)，比如在超時和取消后釋放調(diào)用線程，或者添加對分布式跟蹤的支持。

#576APIServer DryRun

階段：升級到穩(wěn)定版

功能組：api-machinery

Dry run模式允許模擬真實的API請求，并查看該請求是否成功（允許控制鏈、驗證、合并沖突，…）和/或在不修改狀態(tài)的情況下會發(fā)生什么。請求的響應(yīng)主體應(yīng)盡可能接近非dry-run運行響應(yīng)。該核心特性將支持其他用戶級特性，如kubectl diff子命令。

#1281 API服務(wù)器網(wǎng)絡(luò)代理KEP遷移到Beta

階段：升級到Beta版

功能組:api-machinery

云提供商更喜歡將集群APIServer隔離在單獨的控制網(wǎng)絡(luò)中，而非集群網(wǎng)絡(luò)中。實現(xiàn)此目的的方法之一是，在保持與其他集群組件連接的同時，使用Kubernetes APIServer網(wǎng)絡(luò)代理。

擁有這一額外層可以啟用其他功能，如元數(shù)據(jù)審計、日志記錄和對外API Server連接的驗證。

增強包括修復(fù)問題和為實現(xiàn)一般可用性準(zhǔn)備代理，比如從Kubernetes API服務(wù)器刪除SSH隧道代碼，以及改進控制網(wǎng)絡(luò)與集群網(wǎng)絡(luò)的隔離。

Kubernetes 1.18中的Windows支持

#1001Windows CRI ContainerD支持

階段：Alpha

功能組：windows

ContainerD是一個與OCI兼容的運行時，它與Kubernetes一起工作。與Docker相反，ContainerD在WindowsServer 2019中包含對主機容器服務(wù)（HCS v2）的支持，這為如何管理容器提供了更多的控制，并可以改進Kubernetes API的一些兼容性。

此增強功能將Windows中的ContainerD1.3支持作為容器運行時接口（CRI）引入。

#1301 在Windows中實現(xiàn)RuntimeClass

階段：Alpha

功能組：windows

使用RuntimeClass可以定義集群中存在的不同類型的節(jié)點，runtimeClassName指定在哪些節(jié)點中部署pod。這一特性是在Kubernetes 1.12中引入的，在kubernetes1.14上有較大變化。

此增強將功能擴展到Windows節(jié)點，這對于異構(gòu)集群中，希望只在Windows節(jié)點上部署Windows pods非常有幫助。這是定義RuntimeClass的方法，從而將pods限制為WindowsServer1903（10.0.18362）版本。

然后在pods中使用runtimeClassName，如下所示：

#689針對Windows工作負載的GMSA支持

階段：升級到穩(wěn)定版

功能組：windows

允許運營人員在部署時選擇GMSA，使用它運行容器連接到現(xiàn)有應(yīng)用程序，如數(shù)據(jù)庫或API服務(wù)器，而無需更改組織內(nèi)部的身份驗證和授權(quán)方式。

#1043 Windows的RunAsUserName

階段：升級到穩(wěn)定版

功能組：windows

現(xiàn)在Kubernetes支持組托管服務(wù)帳戶，使用runAsUserNameWindows的特定屬性來定義運行容器的entrypoint.。

#995 Kubeadm for Windows

階段:升級到Beta版

功能組:cluster-lifecycle

Kubernetes 1.14中引入了對Windows節(jié)點的支持，但是沒有一種簡單的方法可以將Windows節(jié)點連接到集群。

從Kubernetes 1.16開始，kubeadm join可用于具有部分功能的Windows用戶。它將缺少一些特性，如kubeadm init或kubeadm join——控制平面。

存儲

#695跳過卷所有權(quán)更改（Skip Volume Ownership Change）

階段：Alpha

功能組：存儲

在將卷綁定到容器之前，所有文件權(quán)限都將更改為提供的fsGroup值。這在大規(guī)模的卷上將是一個緩慢的過程，還會破壞一些權(quán)限敏感的應(yīng)用程序，如數(shù)據(jù)庫。

新添加的FSGroupChangePolicy字段用來控制此行為。如果設(shè)置為“always”，將保持當(dāng)前行為。當(dāng)設(shè)置為OnRootMismatch時，它只會在頂級目錄與預(yù)期的fsGroup值不匹配時更改卷權(quán)限。

#1412 不可變Secrets and ConfigMaps

階段：Alpha

功能組：存儲

一個新的不可變字段被添加到Secrets和ConfigMaps中。當(dāng)設(shè)置為true時，對資源鍵所做的任何更改都將被拒絕，從而保護集群不受意外的壞更新的影響。

第二個好處來自不可變資源。由于沒有變化，Kubelet不需要定期檢查更新，從而提高可伸縮性和性能。

在啟用ImmutableEmphemeralVolumes功能門之后，可執(zhí)行以下操作：

然而，一旦資源被標(biāo)記為不可變，就無法恢復(fù)更改。只能刪除和重建Secret，并且需要重建使用已刪除Secret的pod。

#1495 通用數(shù)據(jù)填充插件

階段：Alpha

功能組：存儲

此增強為允許用戶創(chuàng)建預(yù)填充卷奠定了基礎(chǔ)。例如，使用OS映像為虛擬機預(yù)填充磁盤，或啟用數(shù)據(jù)備份和恢復(fù)。

為此，將解除持久卷的DataSource字段的當(dāng)前驗證，允許將任意對象設(shè)置為值。關(guān)于如何填充卷的實現(xiàn)細節(jié)被委托給專門構(gòu)建的控制器。

#770跳過不可附加CSI卷的附加

階段：穩(wěn)定

功能組：存儲

這種內(nèi)部優(yōu)化將簡化容器存儲接口（CSI）驅(qū)動程序的VolumeAttachment對象的創(chuàng)建，這些驅(qū)動程序不需要附加/分離操作，如NFS或類似臨時機密的卷。

對于驅(qū)動程序，Kubernetes Attach/Detach控制器創(chuàng)建VolumeAttachment對象，并等待它們被報告為“attached”。更改CSI卷插件就可以跳過這步。

#351 Raw block device using persistent volume source

階段：升級到穩(wěn)定版

功能組：存儲

BlockVolume在Kubernetes 1.18中達到一般可用性。只需將volumeMode的值設(shè)為block，就可以訪問原始塊設(shè)備。使用原始塊設(shè)備而不使用文件系統(tǒng)抽象的能力，使Kubernetes能夠為高I/O性能和低延遲的高性能應(yīng)用程序提供更好的支持。

#565 CSI塊存儲支持

階段：升級到穩(wěn)定版

功能組：存儲

使用原始塊設(shè)備而不依賴文件系統(tǒng)抽象的能力，使Kubernetes能夠為高I/O性能和低延遲的應(yīng)用程序（如數(shù)據(jù)庫）提供更好的支持。

#603 Pass Pod information in CSI calls

階段：升級到穩(wěn)定版

功能組：存儲

CSI樹外存儲驅(qū)動程序可以接收，NodePublish請求中請求卷的Pod信息，如Pod名稱和命名空間。

CSI驅(qū)動程序可以使用這些信息來授權(quán)或?qū)徲嬀淼氖褂?#xff0c;或者生成適合pod的卷內(nèi)容。

#989擴展允許的PVC數(shù)據(jù)源

階段：升級到穩(wěn)定版

功能組：存儲

使用此功能，可以“克隆”現(xiàn)有的持久卷?？寺?dǎo)致從現(xiàn)有卷配置新的重復(fù)卷。

總結(jié)

以上是生活随笔為你收集整理的修改节点大小_重磅前瞻！K8S 1.18即将发布：OIDC发现、Windows节点支持，还有哪些新特性值得期待？...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。