網易首頁 > 網易號 > 正文申請入駐

Kubernetes十一周年：如果從零重構，一個2.0版會怎么設計？

2025-06-20 18:27:20　來源: CSDN

北京舉報

分享至

Kubernetes 誕生至今已有 11 年，當前版本已推進至 v1.33。在這十余年里，它從 Google 內部的容器編排工具，成長為支撐全球云基礎設施的核心組件。然而，隨著生態不斷擴張與場景復雜化，K8s 也暴露出許多設計層面的局限與“歷史債務”。如果我們有機會從頭再來，打造一個 Kubernetes 2.0，它應該長什么樣？

本文作者 Mathew Duggan 是一位資深 DevOps 工程師，在長年實踐中與 Kubernetes 深度交鋒。他站在一線用戶視角，結合真實痛點，提出了對 K8s 2.0 的系統性設想。從 YAML 的替代方案到更合理的包管理機制，從 etcd 替換路徑到默認啟用 IPv6，他用一篇誠懇而犀利的技術長文，描繪出一個更強大、更易用、更現代的 Kubernetes。

原文鏈接：https://matduggan.com/what-would-a-kubernetes-2-0-look-like/

作者 | Mathew Duggan

出品 | CSDN（ID：CSDNnews）

大約在 2012-2013 年間，我在系統管理員圈子里頻繁聽到一個叫“Borg”的技術名詞。據說那是 Google 內部的一個 Linux 容器系統，用來運行他們所有的服務。

當時一連串的術語讓人聽起來有點摸不著頭腦，比如什么“Borglet”運行在帶有“cells”的集群中。但隨著時間的推移，漸漸地，一些只有 Google 內部員工才懂的基本概念開始向業界流傳開來，如 Borg 中有“服務（services）”和“作業（jobs）”之分：應用程序可以通過服務響應用戶請求，再通過作業處理那些運行時間更長的批處理任務。

然后時間來到 2014 年 6 月 7 日，我們看到了 Kubernetes 項目的首次提交。這個名字源自希臘語，意為“掌舵者”，但前三年幾乎沒人能正確念出來。（到底是 koo-ber-NET-ees，還是 koo-ber-NEET-ees？算了，跟大家一樣叫它 k8s 吧。）

緊接著，微軟、紅帽、IBM 和 Docker 也很快加入了 Kubernetes 社區，這讓它從一個“有趣的 Google 項目”轉變成了“也許真能成為一款正式產品”的水平。

2015 年 7 月 21 日，我們迎來了 Kubernetes v1.0 的發布，同時 CNCF 基金會也宣告成立。

從首次提交至今的十年里，Kubernetes 成為了我職業生活的重要組成部分。我在家里用它，在公司用它，甚至在一些個人項目中也用它——只要合適就用。它的學習曲線陡峭，但也是一個強大的效率倍增器。我們早就不再以服務器為單位來“管理基礎設施”了：現在一切都是聲明式的、可擴展的、可恢復的，甚至在幸運的情況下，能實現自我修復。

當然，這一路走來也并非一帆風順。有些共性的問題反復出現：應用中的很多失誤以及配置有問題，都源自 Kubernetes 在某些地方缺乏明確的設計立場。即便十年過去了，生態系統中仍有很大的動蕩，許多用戶仍然會碰到那些眾所周知的“坑”。

所以，基于我們目前掌握的知識，如果我們要重新設計一遍，怎樣才能讓這個強大的工具更易于被更多人、更廣泛的問題場景所接受？

AI 產品爆發，但你的痛點解決了嗎？8.15-16 北京威斯汀·全球產品經理大會 PM-Summit，3000+ AI 產品人社群已就位。
直面 AI 落地難題、拆解頭部案例、對接精準資源！

掃碼登記信息，添加小助手進群，搶占 AI 產品下一波紅利：

進群后，您將有機會得到：
· 最新、最值得關注的 AI 產品資訊及大咖洞見
· 獨家視頻及文章解讀 AGI 時代的產品方法論及實戰經驗
· 不定期贈送 AI 產品干貨資料和秘籍

K8s 做對了什么？

先說點正面的。為什么十年過去了，我們還在談論這個平臺？

容器的規模化能力

容器作為軟件開發工具，是極其合理的選擇。它避免了“每臺筆記本配置都不一樣”這類混亂，用一種統一的方式貫穿整個技術棧。雖然像 Docker Compose 這樣的工具也能部署容器，但使用起來總有些笨拙，你還是得手動處理很多步驟。比如我自己就曾寫過一個 Compose 部署腳本，用來把某個實例從負載均衡器中移除，拉取新的容器鏡像，確認啟動成功，再重新加回負載均衡器——很多人當時都這么干。

而 Kubernetes 則讓這一切實現了規模化。它讓你可以將本地開發的容器無縫擴展到成千上萬臺服務器。正因為有了這種靈活性，許多組織得以重新審視自身的架構策略，逐漸放棄單體應用，轉而采用更靈活（雖然往往也更復雜）的微服務架構。

低維護成本

如果把運維的發展歷程按照“命名風格”的演進時間線來做比喻，從“寵物式”到“牲畜式”，那么早期階段我稱之為“辛普森時代”。

那時的服務器是裸金屬機器，由團隊手動配置。它們往往有一些獨一無二的名字，在團隊內部成了俚語，每臺機器都像雪花一樣特殊且難以替代。服務器運行得越久，堆積的問題就越多，最后甚至連重啟都讓人膽戰心驚，更別提重建了。

我把那段時間叫做“辛普森時代”，是因為我當時待過的好幾家公司都喜歡用《辛普森一家》角色的名字給服務器命名。那時什么都不會自動修復，一切都得手動操作。

接著，我們進入了“01 時代”。Puppet 和 Ansible 等工具開始普及，服務器不再那么“金貴”，變得更易于替換。堡壘機（bastion host）和其他訪問控制機制也逐漸成為常態。服務器不再直接暴露在公網，而是藏在負載均衡器之后；命名也不再那么有趣，取而代之的是像 “app01” 或 “vpn02” 這種編號式名稱。系統設計允許某些服務器偶爾宕機不影響整體運作。不過，宕機并不會自愈，總得有人 SSH 進去排查原因，再更新工具腳本，把修復方案部署到整個機器池上。操作系統升級依然是個麻煩事。

而現在，我們進入了“UUID 時代”。服務器的存在僅僅是為了運行容器，它們完全是一次性的。沒人關心某個特定版本的操作系統還能支持多久，只需要重新打一個鏡像（比如 AMI），整機替換就好了。雖然 Kubernetes 不是唯一支持這一變革的技術，但它無疑加快了整個演進的進程。現在，如果我還要通過 SSH 登錄到某臺服務器里排錯，這種行為已經屬于“破窗”式的例外情況。大多數情況下的標準做法是：“銷毀那個節點，讓 k8s 自動重新調度，再拉起一個新的節點”。

那些曾經對我職業生涯至關重要的 Linux 技能，現在更多是“錦上添花”而非“必備技能”了。你可能會為此高興，也可能覺得遺憾——我自己也常常在這兩種情緒之間反復，但這就是現實。

作業調度

Kubernetes 的作業系統并不完美，但已經遠勝于我們曾經用的“雪花型 cron01 服務器”。過去很多年里，企業內部常常專門有一臺機器跑定時任務或從消息隊列中拉任務，這種方式非常脆弱。現在，我們可以穩定地將作業放入隊列中，由系統調度執行，失敗后自動重試，然后你就可以放心去做別的事了。

這不僅釋放了人力資源，避免了重復枯燥的人工操作，也極大提升了資源使用效率。雖然隊列里的每個任務依然要啟動一個 pod，但開發者可以根據 pod 的定義自由決定運行什么、怎么運行。對于像我這樣需要頻繁處理后臺任務、但又不希望再花精力盯著的人來說，這無疑是一次生活質量的提升。

服務發現與負載均衡

應用中硬編碼 IP 地址，一直是我職業生涯中的“老大難”。這種做法讓請求的目標服務器變得極難更換。如果運氣好，依賴的是 DNS 而非 IP，那你還可以在不修改代碼的前提下更換服務地址，但很多時候并沒有這么幸運。

Kubernetes 通過內置的 DNS 服務，簡化了服務間通信。你只需通過一個普通的服務名稱就能訪問其他服務，省去了大量麻煩。這不僅消除了很多類型的錯誤，也大大簡化了部署流程。借助 Service API，開發者可以獲得一個穩定且長期存在的 IP 和主機名作為入口，不需要操心底層的實現細節。甚至還可以通過 ExternalName 把集群外部的服務“偽裝”成集群內部的服務來訪問。

如果讓我設計 Kubernetes 2.0，我會加入什么？

用 HCL 取代 YAML

YAML 之所以受歡迎，是因為它不是 JSON，也不是 XML——就好像你夸一輛新車好，是因為它既不是馬也不是獨輪車。確實，YAML 在 Kubernetes 的演示中看起來更清爽，放在代碼倉庫里也更美觀，給人一種“這只是個簡單配置文件”的錯覺。

但實際上，YAML 根本就不適合我們用在 Kubernetes 上的場景，也不夠安全。縮進很容易出錯；文件一旦變長，管理起來就很痛苦（沒人想面對幾千行的 YAML）；調試體驗也很糟。而且 YAML 的規范中還藏著許多隱晦又復雜的行為。

我至今都記得第一次遇到所謂“挪威問題”（Norway Problem）時的震驚。如果你還沒遇到過，那真是幸運。所謂“挪威問題”指的是 YAML 中會把 'NO' 自動解釋成布爾值 false。想象一下你要向挪威的同事解釋，整個國家的代號在配置文件里被判斷為“假”的尷尬場景。類似的還有各種因為缺少引號而被錯誤解析成數字的情況，列表太長不便維護……這些問題數不勝數。網上有不少文章深入探討了 YAML 的各種“神操作”，比我能寫的好得多，比如這篇：https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell

為什么是 HCL？

HCL（HashiCorp Configuration Language）目前已經是 Terraform 的主要配置語言——換句話說，如果我們改用 HCL，至少只需要“討厭”一種配置語言，而不是兩種。HCL 是強類型的，支持顯式的類型聲明，已有成熟的校驗機制。它就是為我們現在強行用 YAML 實現的這些用途而設計的，閱讀上也并不難理解。它內置了許多函數，這些功能已經廣泛被使用，可以幫助我們減少對 YAML 流程中各種第三方工具的依賴。

我敢打賭，現在大約有 30% 的 Kubernetes 集群已經是通過 Terraform 結合 HCL 來管理的。就算不引入 Terraform，光是使用更優秀的配置語言本身，也能帶來許多好處。

當然，也不是沒有代價。HCL 相比 YAML 會稍微啰嗦一點；而且它采用的是 Mozilla 公共許可證 2.0（MPL-2.0），要整合進 Kubernetes 這種基于 Apache 2.0 的項目中，需要做充分的法律審查。不過，考慮到它能帶來的“使用體驗質變”，這些障礙是值得克服的。

為什么 HCL 更好？

我們先來看一個簡單的 YAML 文件示例：

# YAML doesn't enforce types
replicas: "3"  # String instead of integer
resources:
  limits:
    memory: 512  # Missing unit suffix
  requests:
    cpu: 0.5m    # Typo in CPU unit (should be 500m)

即使是最基本的例子中，也到處都有錯誤。HCL 和類型系統可以捕獲所有這些問題。

replicas = 3  # Explicitly an integer
resources {
  limits {
    memory = "512Mi"  # String for memory values
  }
  requests {
    cpu = 0.5  # Number for CPU values
  }
}

以這樣的 YAML 文件為例，你的 K8S 倉庫里可能有 6000 個這樣的文件。現在，無需任何外部工具，就可以查看 HCL 了。

# Need external tools or templating for dynamic values
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  # Can't easily generate or transform values
  DATABASE_URL: "postgres://user:password@db:5432/mydb"
  API_KEY: "static-key-value"
  TIMESTAMP: "2023-06-18T00:00:00Z"  # Hard-coded timestamp

resource "kubernetes_config_map" "app_config" {
  metadata {
    name = "app-config"
  }
  data = {
    DATABASE_URL = "postgres://${var.db_user}:${var.db_password}@${var.db_host}:${var.db_port}/${var.db_name}"
    API_KEY      = var.api_key != "" ? var.api_key : random_string.api_key.result
    TIMESTAMP    = timestamp()
  }
}
resource "random_string" "api_key" {
  length  = 32
  special = false
}

以下是這種轉變帶來的主要優勢：

類型安全：在部署前就能捕捉類型錯誤
變量與引用：減少重復配置，提升可維護性
函數與表達式：支持動態生成配置
條件邏輯：便于根據不同環境生成特定配置
循環與迭代：簡化重復性配置的書寫
更友好的注釋格式：增強文檔說明和可讀性
錯誤處理機制：更容易定位和修復問題
模塊化支持：可復用配置組件，提升組織結構
驗證能力：防止無效配置被提交
數據轉換支持：適用于復雜的數據處理邏輯

支持替換 etcd

我知道，這話已經被人寫了一萬遍都不止了。etcd 表現不錯，但它是目前「唯一的選項」這件事還是有些離譜。對于小規模集群或資源有限的部署來說，etcd 所占用的資源非常可觀，而這些場景可能永遠不會達到 etcd 所帶來的性能回報所要求的節點規模。更奇怪的是，現在的 etcd 幾乎只剩 Kubernetes 這一個主要用戶了。

我的建議是：把 kine 項目的成果“官方化”（https://github.com/k3s-io/kine）。從長遠來看，允許 Kubernetes 插入多個存儲后端是有益的。做一層抽象，讓我們未來更容易替換后端系統，并且根據部署的硬件環境進行更靈活的調優。

我想象中的方案，大概會類似于這個項目：https://github.com/canonical/k8s-dqlite —— 它是一個基于 SQLite 的分布式內存數據庫，采用 Raft 協議實現共識，幾乎無需升級遷移步驟。這將為集群運維人員提供更靈活的持久化選項。如果你部署的是傳統數據中心，etcd 的資源開銷不是問題，那當然沒必要換。但對于輕量級 Kubernetes 部署，這樣的替代方案能顯著提升使用體驗，也（有希望）能降低社區對 etcd 的依賴。

超越 Helm：內建的包管理器

Helm 是一個典型的“臨時解決方案用久了就成了剛需”的例子。我非常感謝 Helm 的維護者們，能把一個本是黑客松上誕生的小工具，發展成 Kubernetes 安裝軟件的事實標準。這是個令人敬佩的成就，也填補了 k8s 本身缺乏包管理機制的空白。

但話說回來，Helm 的使用體驗簡直是一場噩夢。Go 模板難以調試，模板里常常嵌套著復雜邏輯，最終導致各種莫名其妙的錯誤。而這些錯誤信息通常難以理解，幾乎無法追蹤來源。更根本的問題在于，Helm 并不是一個合格的軟件包管理系統，它連最基本的兩個功能都做不好：傳遞依賴管理和沖突解析。

什么意思呢？

接下來我想給你展示一個條件邏輯的例子，你可以告訴我，它到底想做什么？（這里原文將開始舉例分析 Helm 模板中難以理解的邏輯）

# A real-world example of complex conditional logic in Helm
{{- if or (and .Values.rbac.create .Values.serviceAccount.create) (and .Values.rbac.create (not .Values.serviceAccount.create) .Values.serviceAccount.name) }}
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: {{ template "myapp.fullname" . }}
  labels:
    {{- include "myapp.labels" . | nindent 4 }}
{{- end }}

或者，如果我向圖表提供多個值文件，哪一個會勝出：

helm install myapp ./mychart -f values-dev.yaml -f values-override.yaml --set service.type=NodePort

那如果我想用一個 Helm Chart 來管理我的應用程序及其所有依賴項怎么辦？這是合理的：我的應用本身依賴于其他組件，所以我希望把它們整合在一起。

于是我就在 Chart.yaml 中定義了子 Chart 或“傘形”Chart（umbrella chart）。

dependencies:
- name: nginx
  version: "1.2.3"
  repository: " "
- name: memcached
  version: "1.2.3"
  repository: " "

但假設我有多個應用程序，那么完全有可能我有 2 個服務都依賴于 nginx 或類似的東西：

Helm 在處理這種情況時并不理想，因為所有模板的命名是全局的，而且加載順序是按字母排序的。換句話說，你需要注意以下幾點：

不要對同一個 Chart 聲明多次依賴 —— 但對于大量微服務來說，這其實很難做到。
如果確實聲明了多個相同的 Chart，版本號必須完全一致。

而且，這類問題遠不止這些。

Helm 對跨 Namespace 的安裝支持很糟糕。
Chart 的驗證流程非常繁瑣，結果幾乎沒人用

我們隨便打開 ArtifactHub 的首頁看看就明白了：

我會抓住 elasticsearch 因為它看起來很重要。

這對官方的 Elastic Helm Chart 來說看起來確實很糟糕。那 ingress-nginx 總該沒問題吧？它可是整個行業都依賴的關鍵組件。

不行，還是不行。還有，Chart 的維護者都標明是 “Kubernetes” 了，結果竟然還沒被標記為“已驗證發布者”。天哪，這還能怎么更“官方”？

Chart 搜索時沒有任何元數據支持。你只能按名稱和描述進行搜索，無法根據功能、能力或其他元數據來篩選。

Helm 并不強制遵守語義化版本規范（Semantic Versioning）

# Chart.yaml with non-semantic version
apiVersion: v2
name: myapp
version: "v1.2-alpha"

如果你卸載再重新安裝一個帶有 CRD 的 Chart，它有可能會把通過這些 CRD 創建的資源給刪掉。這問題我踩過好幾次，真的非常不安全。

我可以再寫 5000 字，也說不完 Helm 的問題。說實話，Helm 根本無法勝任“地球上所有關鍵基礎設施的軟件包管理器”這個任務。

k8s 包系統是什么樣的？

那么，一個理想的 Kubernetes 包管理系統應該是什么樣子？

我們暫且稱它為 KubePkg —— 畢竟 Kubernetes 生態最需要的，就是再多一個帶 “K” 的縮寫名字。設計思路是：盡可能借鑒 Linux 生態中已有的成熟機制，同時充分利用 Kubernetes 的 CRD（自定義資源定義）能力。我的設想大致如下：

這些軟件包類似于 Linux 軟件包：

并配有一個定義文件，能夠覆蓋你在安裝軟件時遇到的各種真實場景。

apiVersion: kubepkg.io/v1
kind: Package
metadata:
  name: postgresql
  version: 14.5.2
spec:
  maintainer:
    name: "PostgreSQL Team"
    email: "maintainers@postgresql.example.com"
  description: "PostgreSQL database server"
  website: "https://postgresql.org"
  license: "PostgreSQL"
  # Dependencies with semantic versioning
  dependencies:
    - name: storage-provisioner
      versionConstraint: ">=1.0.0"
    - name: metrics-collector
      versionConstraint: "^2.0.0"
      optional: true
  # Security context and requirements
  security:
    requiredCapabilities: ["CHOWN", "SETGID", "SETUID"]
    securityContextConstraints:
      runAsUser: 999
      fsGroup: 999
    networkPolicies:
      - ports:
        - port: 5432
          protocol: TCP
  # Resources to be created (embedded or referenced)
  resources:
    - apiVersion: v1
      kind: Service
      metadata:
        name: postgresql
      spec:
        ports:
        - port: 5432
    - apiVersion: apps/v1
      kind: StatefulSet
      metadata:
        name: postgresql
      spec:
        # StatefulSet definition
  # Configuration schema using JSON Schema
  configurationSchema:
    type: object
    properties:
      replicas:
        type: integer
        minimum: 1
        default: 1
      persistence:
        type: object
        properties:
          size:
            type: string
            pattern: "^[0-9]+[GMK]i$"
            default: "10Gi"
  # Lifecycle hooks with proper sequencing
  hooks:
    preInstall:
      - name: database-prerequisites
        job:
          spec:
            template:
              spec:
                containers:
                - name: init
                  image: postgres:14.5
    postInstall:
      - name: database-init
        job:
          spec:
            # Job definition
    preUpgrade:
      - name: backup
        job:
          spec:
            # Backup job definition
    postUpgrade:
      - name: verify
        job:
          spec:
            # Verification job definition
    preRemove:
      - name: final-backup
        job:
          spec:
            # Final backup job definition
  # State management for stateful applications
  stateManagement:
    backupStrategy:
      type: "snapshot"  # or "dump"
      schedule: "0 2 * * *"  # Daily at 2 AM
      retention:
        count: 7
    recoveryStrategy:
      type: "pointInTime"
      verificationJob:
        spec:
          # Job to verify recovery success
    dataLocations:
      - path: "/var/lib/postgresql/data"
        volumeMount: "data"
    upgradeStrategies:
      - fromVersion: "*"
        toVersion: "*"
        strategy: "backup-restore"
      - fromVersion: "14.*.*"
        toVersion: "14.*.*"
        strategy: "in-place"

有一個真正的簽名過程是必需的，它允許你更好地控制該過程。

apiVersion: kubepkg.io/v1
kind: Repository
metadata:
  name: official-repo
spec:
  url: "https://repo.kubepkg.io/official"
  type: "OCI"  # or "HTTP"
  # Verification settings
  verification:
    publicKeys:
      - name: "KubePkg Official"
        keyData: |
          -----BEGIN PUBLIC KEY-----
          MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvF4+...
          -----END PUBLIC KEY-----
    trustPolicy:
      type: "AllowList"  # or "KeyRing"
      allowedSigners:
        - "KubePkg Official"
        - "Trusted Partner"
    verificationLevel: "Strict"  # or "Warn", "None"

如果有一些東西可以讓我自動更新軟件包而不需要我做任何事情，那該有多好啊。

apiVersion: kubepkg.io/v1
kind: Installation
metadata:
  name: postgresql-main
  namespace: database
spec:
  packageRef:
    name: postgresql
    version: "14.5.2"
  # Configuration values (validated against schema)
  configuration:
    replicas: 3
    persistence:
      size: "100Gi"
    resources:
      limits:
        memory: "4Gi"
        cpu: "2"
  # Update policy
  updatePolicy:
    automatic: false
    allowedVersions: "14.x.x"
    schedule: "0 2 * * 0"  # Weekly on Sunday at 2am
    approvalRequired: true
  # State management reference
  stateRef:
    name: postgresql-main-state
  # Service account to use
  serviceAccountName: postgresql-installer

Kubernetes 需要一個滿足以下條件的包管理系統：

真正的 Kubernetes Native：一切都是 Kubernetes 的資源對象，具備完整的狀態（status）與事件（events）機制
一流的狀態管理：對有狀態應用提供內建支持
增強的安全性：強健的簽名驗證機制、安全掃描流程
聲明式配置：無需模板，僅使用具備 schema 的結構化配置
生命周期管理：覆蓋整個生命周期的鉤子機制與升級策略
依賴關系解析：類 Linux 的依賴管理機制，支持語義化版本
審計日志：完整記錄每次變更，包括誰改了、改了什么、什么時候改的——而不是 Helm 現在那種模糊不清的方式
策略強制：支持組織級的合規性策略與準則
簡化的用戶體驗：借鑒 Linux 的包管理命令行風格，使用直觀。這么多年來被驗證有效的包管理方式，我們卻在 Kubernetes 上走了另一條復雜的路，實在是沒必要。

默認啟用 IPv6

試著想象一下，全世界范圍內，有多少時間與精力被浪費在以下三個問題上：

我希望這個集群中的 Pod 能訪問另一個集群里的 Pod
NAT 穿透過程中出了問題，我得解決它
我的集群 IP 地址用完了，因為我沒算好會用多少。舉個例子：某公司使用的是一個 /20 子網（大約 4096 個地址），部署了 40 個節點，每個節點運行 30 個 Pod，然后突然發現——IP 不夠用了！這還不是特別大的集群！

我并不是說整個互聯網現在就該切換到 IPv6。目前 Kubernetes 已經可以支持 IPv6-only 或雙棧（dual-stack）模式。但我的意思是，現在是時候把默認選項改成 IPv6了。因為這么做可以一下子解決大量長期存在的網絡問題：

集群內部的網絡拓撲更加扁平、簡潔
是否使用多個集群，對企業而言變成一個可選項，特別是當你希望直接使用公網 IP 時
更容易理解應用內部的流量路徑

原生支持 IPSec 加密

這和推動全球 IPv6 普及無關，而是現實地承認：我們已經不再生活在那個必須接受 IPv4 各種限制的時代。今天，你可能隨時需要 1 萬個 IP 地址，而且不會提前幾個月知道。

對于擁有公網 IPv6 地址的組織來說，這種轉變的好處顯而易見。但即使是對云服務商和用戶來說，價值也足夠大，大到連“企業大老板們”都有可能支持。比如 AWS 就再也不需要在 VPC 內到處搜刮有限的私有 IPv4 地址了——這難道不值得嗎？

結語

針對上述這些想法，最常見的反駁是：“Kubernetes 是一個開放平臺，社區可以自己去實現這些功能。”雖然這話沒錯，但它忽略了一個關鍵問題：“默認選項”才是技術中最具力量的驅動器。

核心項目所定義的“推薦路徑”（happy path），會決定 90% 的用戶怎么使用這個系統。如果系統默認啟用簽名包，并且提供一個穩健、原生的管理方式，那么整個生態自然就會圍繞這個方向發展。

我知道，這是一份雄心勃勃的清單。但既然要設想 Kubernetes 2.0，那就不妨大膽一點。畢竟我們就是那個曾經以為“叫 Kubernetes 這個鬼名字也能火起來”的行業——結果還真就火了。

我們在移動開發、Web 開發等領域已經看到這種事一次次發生：平臺評估現狀后，果斷邁出一大步。這些建議可能不是當前維護者或廠商會立刻采納的任務，但我真心覺得，它們值得有人回過頭去認真想一想、重新審視一下這個平臺：現在我們已經占據了全球數據中心運維的很大一部分，這些想法是否值得去做一做？

未來已來，AI 產品爆發在即！

CSDN高級副總裁，全球產品經理大會（PM-Summit）發起人李建忠對話“硅谷精神之父”、《連線》雜志創始主編凱文·凱利（KK），展開一場關于AI產品未來發展的思辨！

本周五6 月 20 日晚 19:30 掃碼預約！

特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。

Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.