🥇關於 Kubernetes 的日益普及

嘿哈布爾！

在夏末，我們想提醒您，我們將繼續致力於這個主題 Kubernetes 並決定在 XNUMX 月初從 Stackoverflow 發布一篇文章來展示該專案的狀況。

享受閱讀！

在撰寫本文時，Kubernetes 的歷史大約是 XNUMX 年。六歲，在過去的兩年裡，它的受歡迎程度不斷提高，一直名列前茅。最喜歡的平台。 Kubernetes 今年排名第三。回顧一下：Kubernetes 是一個旨在運行和編排容器化工作負載的平台。

容器最初是用於隔離 Linux 進程的特殊設計；自 2007 年以來，容器已包括在內小組，以及自 2002 年以來的命名空間。到 2008 年，容器的設計變得更好了 LXC，Google開發了自己的內部企業機制，稱為博格，其中“所有工作都在容器中完成”。從這裡我們快轉到 2013 年，當時 Docker 首次發布，容器最終成為流行的大眾解決方案。當時容器編排的主要工具是梅索斯，儘管他並沒有廣受歡迎。 Kubernetes於2015年首次發布，此後該工具成為容器編排領域的事實標準。

為了嘗試了解 Kubernetes 為何如此受歡迎，讓我們試著回答幾個問題。開發人員最後一次就如何將應用程式部署到生產環境達成一致是什麼時候？您知道有多少開發人員使用開箱即用的工具？如今有多少雲端管理員不了解應用程式的工作原理？我們將在本文中看看這些問題的答案。

YAML 形式的基礎設施

在從 Puppet 和 Chef 到 Kubernetes 的世界中，最大的變化之一是從「基礎設施即程式碼」到「基礎設施即資料」的轉變——特別是 YAML。 Kubernetes 中的所有資源，包括 Pod、設定、部署的實例、磁碟區等，都可以在 YAML 檔案中輕鬆描述。例如：

apiVersion: v1
kind: Pod
metadata:
  name: site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80

這種視圖使 DevOps 或 SRE 專業人員可以更輕鬆地充分錶達他們的工作負載，而無需使用 Python 或 Javascript 等語言編寫程式碼。

將基礎設施組織為資料的其他優點包括：

GitOps 或 Git 操作版本控制。這種方法可讓您將所有 Kubernetes YAML 檔案保存在 git 儲存庫中，以便您可以準確追蹤更改的時間、更改者以及更改的具體內容。這提高了整個組織運作的透明度，並透過消除歧義來提高營運效率，特別是在員工應尋找所需資源的地方。同時，透過簡單地合併拉取請求，自動更改 Kubernetes 資源變得更加容易。
可擴展性。當資源被定義為 YAML 時，叢集操作員可以非常輕鬆地更改 Kubernetes 資源中的一兩個數字，從而改變其擴充方式。 Kubernetes 提供了一種 pod 水平自動縮放機制，可用於方便地確定特定部署配置中處理低流量和高流量所需的最小和最大 pod 數量。例如，如果您部署的配置因流量突然激增而需要額外容量，則 maxReplicas 可以從 10 變更為 20：

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp-deployment
  minReplicas: 1
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

安全和管理。 YAML 非常適合評估 Kubernetes 中的部署方式。例如，一個主要的安全問題涉及您的工作負載是否以非管理員使用者身分執行。在這種情況下，我們可能需要諸如會議測試，YAML/JSON 驗證器，加上開放策略代理，一個策略驗證器，以確保上下文安全情境您的工作負載不允許容器以管理員權限執行。如果需要，使用者可以應用一個簡單的策略雷戈，像這樣：

package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Containers must not run as root"
}

與雲端提供者整合的選項。當今高科技最顯著的趨勢之一是在公有雲供應商上運行工作負載。使用組件雲端提供者 Kubernetes 允許任何叢集與其運行的雲端提供者整合。例如，如果用戶在 AWS 上的 Kubernetes 中運行應用程式並希望透過服務公開該應用程序，雲端供應商會協助自動建立該服務 LoadBalancer這將自動提供負載平衡器亞馬遜彈性負載平衡器將流量重定向到應用程式 Pod。

可擴展性

Kubernetes 的可擴展性非常好，開發人員喜歡它。有一組可用資源，例如 Pod、部署、 StatefulSets, 秘密, ConfigMaps， ETC。確實，使用者和開發人員可以在表單中添加其他資源自訂資源定義.

例如，如果我們要定義一個資源 CronTab，那麼你可以這樣做：

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.my.org
spec:
  group: my.org
  versions:
    - name: v1
      served: true
      storage: true
      Schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                  pattern: '^(d+|*)(/d+)?(s+(d+|*)(/d+)?){4}$'
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 10
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct

稍後我們可以建立一個 CronTab 資源，如下所示：

apiVersion: "my.org/v1"
kind: CronTab
metadata:
  name: my-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-cron-image
  replicas: 5

Kubernetes 中可擴充性的另一個選擇是開發人員可以編寫自己的語句。操作者是 Kubernetes 叢集中的一個特殊進程，它依照“控制電路」在操作員的幫助下，使用者可以透過與 Kubernetes API 交換資訊來自動化 CRD（自訂資源定義）的管理。

社群中有許多工具可以讓開發人員輕鬆創建自己的運算符。他們之中 - 算子框架和營運商SDK。該 SDK 為開發人員可以快速開始建立運算符提供了基礎。假設您可以從命令列開始，如下所示：

$ operator-sdk new my-operator --repo github.com/myuser/my-operator

這將為您的操作員建立所有樣板程式碼，包括 YAML 檔案和 Golang 程式碼：

.
|____cmd
| |____manager
| | |____main.go
|____go.mod
|____deploy
| |____role.yaml
| |____role_binding.yaml
| |____service_account.yaml
| |____operator.yaml
|____tools.go
|____go.sum
|____.gitignore
|____version
| |____version.go
|____build
| |____bin
| | |____user_setup
| | |____entrypoint
| |____Dockerfile
|____pkg
| |____apis
| | |____apis.go
| |____controller
| | |____controller.go

然後您可以新增所需的 API 和控制器，如下所示：

$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService

$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService

最後，組裝操作符並將其發送到容器的註冊表：

$ operator-sdk build your.container.registry/youruser/myapp-operator

如果開發人員想要更多控制，可以更改 Go 檔案中的樣板程式碼。例如，要修改控制器的細節，您可以變更文件 controller.go.

另一個項目 EVERYWHERE，允許您僅使用聲明性 YAML 檔案建立語句。例如，Apache Kafka 的運算子大約定義為所以。有了它，您只需使用幾個命令即可在 Kubernetes 上安裝 Kafka 叢集：

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

然後用另一個命令配置它：

$ kubectl kudo install kafka --instance=my-kafka-name 
            -p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181 
            -p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m 
            -p BROKER_COUNT=5 -p BROKER_MEM=4096m 
            -p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3 
            -p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20

創新

在過去的幾年裡，Kubernetes 的主要版本每隔幾個月就會發布一次，即每年發布三到四個主要版本。它們各自引入的新功能數量並沒有減少。而且，即使在這些困難時期，也沒有放緩的跡象——看看現在的情況 Github 上的 Kubernetes 專案活動.

新功能可讓您更靈活地跨不同工作負載進行叢集操作。此外，程式設計師在將應用程式直接部署到生產環境時享有更大的控制權。

社區

Kubernetes 受歡迎的另一個主要方面是其社區的實力。 2015 年，Kubernetes 達到 1.0 版本後，得到了以下代理商的贊助：雲原生計算基金會.

還有各種社區 SIG 隨著專案的發展，（特別興趣小組）專注於 Kubernetes 的不同領域。這些團體不斷添加新功能，使使用 Kubernetes 變得更加方便和方便。

雲端原生基金會也主辦 CloudNativeCon/KubeCon，在撰寫本文時，這是世界上最大的開源會議。它通常每年舉辦三次，匯集了數千名想要改進 Kubernetes 及其生態系統的專業人士，並學習每三個月出現的新功能。

此外，雲端原生基金會還技術監督委員會，與 SIG 一起審查新的和現有的項目資金專注於雲端生態系統。這些項目大多數都有助於提高 Kubernetes 的優勢。

最後，我相信，如果沒有整個社群的自覺努力，Kubernetes 不會如此成功，人們團結在一起，但同時也歡迎新人加入。

未來

開發人員未來必須應對的主要挑戰之一是能否專注於程式碼本身的細節，而不是其運作的基礎設施。它符合這些趨勢無伺服器架構範式，這是當今領先的之一。先進的框架已經存在，例如基尼特語 и OpenFaas，它使用 Kubernetes 從開發人員那裡抽像出基礎設施。

在本文中，我們只觸及了 Kubernetes 目前狀態的表面——事實上，這只是冰山一角。 Kubernetes 使用者可以使用許多其他資源、功能和配置。

來源： www.habr.com

關於 Kubernetes 的日益普及

YAML 形式的基礎設施

可擴展性

創新

社區

未來

添加評論 取消回复

添加評論取消回复