為什麼Kubernetes如此受歡迎？ -stackoverflow

以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

• GitOps或Git Operations版本控制。使用這種方法，您可以將所有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中部署什麼以及如何部署的好方法。例如，有關安全性的主要問題之一是您的工作負載是否以非root使用者身份執行。我們可以使用conftest（一種YAML / JSON驗證器）等工具以及Open Policy Agent（一種策略驗證器）來檢查您的工作負荷是否不允許容器作為根執行。為此，使用者可以使用一個簡單的開放策略代理 rego 這樣的政策：
  

  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服務，該服務將自動配置Amazon Elastic Load Balancer以將流量轉發到應用程式容器。

可擴充套件性
Kubernetes具有很好的可擴充套件性，開發人員對此非常滿意。有一組現有資源，例如Pod，Deployment 、、StatefulSetsSecrets ConfigMaps等。但是，使用者和開發人員可以以“ 自定義資源定義”的形式新增更多資源。例如，如果我們想定義一個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

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

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

|____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

$ 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

$ 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每三四個月釋出一次主要版本，這意味著每年都有三到四個主要版本。引入的新功能的數量並未減慢，最新版本的 30多種新增和更改證明了這一點。此外，Kubernetes專案Github活動表明，即使在這些困難時期，捐款也不會顯示出放緩的跡象。
這些新功能使叢集運營商在執行各種不同的工作負載時具有更大的靈活性。軟體工程師還喜歡擁有更多控制元件，以將其應用程式直接部署到生產環境中。

社群
Kubernetes受歡迎的另一個重要方面是其強大的社群。首先，Kubernetes在2015年達到1.0版本時就捐贈給了與供應商無關的家庭：Cloud Native Computing Foundation。
隨著專案的推進，還有各種各樣的社群SIG（特殊興趣小組）針對Kubernetes中的不同區域。他們不斷新增新功能，並使其更加使用者友好。
Cloud Native Foundation還組織了CloudNativeCon / KubeCon，截至撰寫本文時，CloudNativeCon / KubeCon是世界上最大的開源活動。該活動通常每年舉行三屆，吸引了數千名希望改善Kubernetes及其生態系統以及利用每三個月釋出的新功能的技術人員和專業人士。
此外，Cloud Native Foundation擁有一個技術監督委員會，與SIG一起，負責研究基金會在雲原生生態系統中的新專案和現有專案。大多數專案都有助於增強Kubernetes的價值主張。
最後，我相信，如果沒有社群的有意識的努力來互相包容並歡迎任何新來者，Kubernetes就不會取得成功。

未來
開發人員未來面臨的主要挑戰之一是如何將更多的精力放在程式碼的細節上，而不是程式碼執行所在的基礎結構上。為此，無伺服器正在成為應對這一挑戰的領先架構範例之一。已經有非常高階的框架，例如Knative和OpenFaas，它們使用Kubernetes從開發人員那裡提取基礎架構。
我們在本文中對Kubernetes進行了簡要介紹，但這只是冰山一角。使用者可以利用更多資源，功能和配置。我們將繼續看到增強或發展Kubernetes的新開源專案和技術，正如我們所提到的，貢獻和社群無處不在。

HackerNews討論:
Kubernetes變得越來越流行是因為：
1）解決了許多不同的通用基礎結構級別的問題。2）越來越多的人正在使用容器。K8s可幫助您管理容器。3）與供應商無關。將k8s應用程式重新定位到其他叢集很容易5）人們看到它越來越流行。6）它是開源的。7）幫助著名公司執行大型系統。8）人們認為履歷表看起來不錯，他們想在一家知名公司工作。9）一旦掌握了K8，就可以輕鬆解決大小問題。（請注意，我不是在談論安裝和管理叢集。我是在談論成為叢集使用者。）10）這引起爭議，這意味著人們一直在談論它。這給了K8的心靈共享。
我並不是說K8沒有問題或不利之處。
1）自行安裝和管理很痛苦。2）有很多東西要學習-特別是如果您不認為自己會使用其中的大部分功能。3）儘管文件已改進很多，但在某些地方仍然薄弱無方向。
我認為K8s越來越受歡迎，因為它的優點遠遠超過了缺點。

Kubernetes中的網路非常複雜。如果您是Google規模的公司，那麼這種複雜和抽象很有意義。大多數都不具備Google規模，因此不需要這種級別的可擴充套件性。在進行診斷時，網路抽象的代價是複雜性。

如果您將Kubernetes視為新的Linux，這會更有意義：業界公認的共同基礎，並且您可以在其之上構建其他抽象。

作為系統管理員，我喜歡k8s，因為它以標準化的方式解決了系統管理員的問題。諸如安全滾動部署，合併日誌記錄，活動性和就緒性探測等之類的事情。是的，還因為它是可重複的。它承擔了我工作中所有無聊的任務，讓我專注於更有意義的工作，例如儀表板和監控。

在使用K8S之前，要執行服務，您需要：-設定VM：及其依賴關係，工具鏈。如果您使用諸如具有映象處理等本機元件的軟體包之類的事件，則需要在VM上設定一些編譯器-部署過程-負載均衡器-Systemd單元以自動重啟它。設定記憶體限制等，所有這些都是在K8S中完成的。只要釋出Dockerfile，就完成了。

這在開發人員和運營人員之間建立了通用的術語。運營細節從開發人員中隱藏，而開發細節（工作負載的詳細資訊）從運營工程師中隱藏。

Kubernetes之所以變得流行是因為它是對現有事物（如防火牆，虛擬ip，程式設定等）的不二之選。

昨天，當我看到一家由YC支援的招聘公司正在使用Kubernetes時，我認為這簡直太瘋狂了。絕對瘋了。它已成為每家公司即使在不需要時也必須擁有的最新，最熱門，最技術性的東西。

你們認為k8s正在做jvm以前在企業中所做的工作嗎？即，如果一切都在jvm上，則構建分散式系統不需要容器。JVM更類似於Docker。K8s位於上方。

Kubernetes實際上並不是它所描述的任何東西。但是，它是雲的作業系統。它是一組通用抽象層，可以位於任何IaaS提供程式之上並與之配合使用，並允許您透過標準化且易於使用的API使用基礎結構即程式碼的概念來構建和部署應用程式。

Kubernetes是部署容器的一種方法。諸如Ansible / Salt / Puppet / Chef / etc之類的配置系統是部署容器的另一種方法。Kubernetes還可以動態擴充套件您的工作負載。但是Auto Scaling組（AWS術語）和GCP / Azure等效項也是如此。現實情況是99％的使用者實際上並不需要Kubernetes。在大多數情況下，它帶來了大量的複雜性，開銷和不穩定性。