knative serving 0.6 版本變更

文章翻譯自官方release note，連結見最下方。

概要

新API模型

我們已經通過了knative serving “v1beta1” API模型

提議

，這些改變會使得kubernetes使用者更容易使用Serving資源，解鎖了在knative Service中使用Route，并且可以自己指定Revision名稱，開啟了GitOps場景。我們争取在接下來幾個釋出中完成。

在這次釋出中，我們移植新的API定義到v1alpha1 API，作為轉換到v1beta1（又稱lemonade）的第一步。以下不相容的變更會在0.7+版本實施：

• Service和Configuration不再支援内嵌Build。
• Service不支援 manual 模式。

你可以通過knative/docs的

例子

來了解新API接口，我們會繼續支援大多數v1alpha1的接口直到我們停用它。

徹底改變縮容到零

我們從根本上改變了縮容到零的機制，新的架構通過Serving資源模型較少的改動，獲得職責上更好的分離，并且解決了一些長期存在的問題（一些在這次版本釋出，一些将來釋出）。看下面内容了解更多。

自動證書 （alpha，可選）

我們添加了自動證書內建！預設的實作基于 

cert-manager

 來提供證書（例如通過Let’s Encrypt），但和Istio插件化類似，你也可以替換cert-manager為其他證書提供系統。目前證書針對每個路由提供，但泛域名将在未來版本支援。這個功能依賴Istio 1.1，并且需要顯式的開啟。

控制器解耦

我們已經開始将Knative中的“可插拔”控制器拆分為它們自己的控制器程序，以便希望替換Knative子系統的人能夠更容易地删除綁定的預設實作。例如，要安裝Knative Serving但不包含Istio:

kubectl apply -f serving.yaml \
  -l networking.knative.dev/ingress-provider!=istio           

注意，由于kubectl不能了解Istio對象的yaml（盡管他們已經被label選擇器過濾掉了），我們會看到一些錯誤。可以安全的忽略找不到 "networking.istio.io/v1alpha3" 的 "Gateway" 資源。

你也可以用以下指令忽略基于cert-manager實作的自動證書（Auto-TLS）控制器：

kubectl apply -f serving.yaml \
  -l networking.knative.dev/certificate-provider!=cert-manager           

擴縮容

把Knative PodAutoscaler（又稱KPA） /scale 子資源移出來，變成一個PodScalable 通用類型（“duck type”）。這樣可以利用informer緩存，并且擴充的字段可以讓ServerlessService（又稱SKS）利用PodSpec在未來版本優化。

（具體修改見

#3889

，題外話，之前每次調解都需要使用scale client連接配接API server讀取/scale子資源，用不上緩存）

我們現在確定在Revision縮容到零前，“activator”元件已經接管流量（又稱正向切換[positive hand-off], 

#2949

）。這個改動開啟了Revision能夠管理激活。

(實作這個是為了解決縮容到0之前，要等待30秒，這個值是個經驗值，主要是等待istio切換路由。但我們也不清楚30秒是否足夠，還是說可以縮短。目前這個實作是在activator和queue proxy都加一個響應探測的接口，當需要縮容到零時，由pa發起請求探測檢查确認是否路由到activator了。但目前的實作還不是完美的，由于istio有很多sidecar，更新路由需要時間，我們隻能确定某個sidecar配置更新了)

新的注解 

autoscaling.knative.dev/window

, 

autoscaling.knative.dev/panicWindowPercentage

, and 

autoscaling.knative.dev/panicThresholdPercentage

 允許使用者自定義 KPA 類型的擴縮容敏感性。(

#3103

)  

（譯者注：增加配置時間視窗、panic的一些參數）

添加activator的鍊路耗時（tracing）擷取更詳細的資料，并且可以持續的測量性能資料（

#2726

）。這個解決了

#1276

 并且允許我們去定位性能問題，例如冷啟動。

縮短預設transports的空閑逾時時間，解決了使用Istio 1.1 lean安裝，縮容到零的問題(

#3987

)。原因是當endpoints變更時，通過k8s的service沒有斷開連接配接。

解決一個阻止縮容到零的問題 (

#3688

)，解決方法，把enable-scale-to-zero配置加入KPA調解計算中。如果minScaler注解沒有設或者設為0，并且enable-scale-to-zero設為false，保留最少一個pod。

修複autoscaler重新開機時，做出輕率的決定（

#3771

）（在沒有名額時不擴縮容）。

核心API

我們已經準許了v1beta的API定義！如上所述，我們要開始在接下來的幾個裡程碑實作v1beta1.這次裡程碑把v1beta1 API接口作為v1alpha1的子集。

我們改變了執行校驗的方式，基于在支援的字段使用“fieldmask”。我們現在會給每個Kubernetes對象建立一個副本（僅限于我們需要的字段），并和原來的對象比較，這樣確定我們在Kubernetes API發展中仔細考慮使用哪些資源字段(

#3424 #3779

)。 在這基礎上，清理了内部API的校驗 (

#3789 #3911

)。

status.domain已經過時，使用status.url 來替換 (

#3970

) 。使用 

apis.URL

 類型作為URL status 字段，解決issue "無法擷取服務 URL" (

#1590

添加可以通過configmap設定預設的cpu、記憶體request和limit值。并且删除了之前預設的CPU limit，這樣可以回退到k8s的預設值，除了由operator特别指定的。(

#3550 #3912

)

去掉configurationMetadataGeneration label的使用 (

#4012

) ，并完成了我們轉向CRD 子資源的最後一個改動(

#643

網絡

徹底改變了我們縮容到零的方式！這個開啟了Revision管理自己啟動的語義。需要縮容到零時實作了正向切換，并且增加了autoscaling控制器的同步周期，保持和其他控制器一緻。

添加自動配置TLS證書。

停止釋出Istio yaml檔案。重新分發istio不是我們的本意，并且之前的版本暴露我們的改動-優化了Istio yamls。使用者應該請教Istio或者廠商指定的文檔來如何獲得一個支援knative的Istio版本。

我們已經開始在Service或者Route的子路由中采取扁平命名方案。老的URL目前還可以使用，但新的URL會出現在 

status.traffic[*].url

 字段裡。

支援安裝Istio 1.1 (

#3515 #3353

解決在開啟Istio mTLS時，readiness 探測的問題(

#4017

監控

Activator也把請求日志記錄下來(

#3781

測試和釋出 

• label serving.knative.dev/release: devel需要有釋出名字或者數字來替代devel，暴露TAG來填充
• 總是用istio的HEAD版本來做更新測試，解決在更新降級knative測試遇到的錯誤
• 添加額外一緻性測試（9個新增的測試），改進現有的一緻性測試和v1beta1的覆寫率。

參考内容

内容翻譯自knative/serving release node

https://github.com/knative/serving/releases/tag/v0.6.0