🥇Kubernetes の人気の高まりについて

おい、ハブル！

夏の終わりに、私たちはこのテーマに引き続き取り組んでいることをお知らせしたいと思います。 Kubernetes そして、このプロジェクトの現状を示す記事を Stackoverflow から XNUMX 月初めに公開することにしました。

読書をお楽しみください！

この記事の執筆時点では、Kubernetes の年齢は約 XNUMX 年です。 XNUMX歳、過去 XNUMX 年間でその人気は非常に高まり、常に次のランキングにランクインしています。一番好きなプラットフォーム。今年は Kubernetes が XNUMX 位にランクされました。要約すると、Kubernetes は、コンテナ化されたワークロードを実行および調整するために設計されたプラットフォームです。

コンテナーは、Linux でプロセスを分離するための特別な設計として始まりました。コンテナは2007年から含まれています cgroup、2002 年以降は名前空間。コンテナは 2008 年に利用可能になるまでにさらに優れた設計になりました LXCそしてGoogleは、と呼ばれる独自の社内メカニズムを開発しました。ボルグ、「すべての作業はコンテナ内で行われます」。ここから、Docker の最初のリリースが行われ、コンテナーがついに一般的な大規模ソリューションになった 2013 年に早送りします。当時、コンテナオーケストレーションの主なツールはメゾス、しかし、彼は大人気ではありませんでした。 Kubernetes は 2015 年に初めてリリースされ、その後、このツールはコンテナオーケストレーションの分野における事実上の標準になりました。

Kubernetes がなぜこれほど人気があるのかを理解するために、いくつかの質問に答えてみましょう。最後に開発者がアプリケーションを運用環境にデプロイする方法について合意できたのはいつですか? すぐに提供されるツールをそのまま使用している開発者を何人知っていますか? 現在、アプリケーションがどのように機能するかを理解していないクラウド管理者が何人いるでしょうか? この記事では、これらの質問に対する答えを見ていきます。

YAML としてのインフラストラクチャ

Puppet と Chef から Kubernetes に移行した世界における最大の変化の XNUMX つは、「コードとしてのインフラストラクチャ」から「データとしてのインフラストラクチャ」、特に YAML への移行でした。ポッド、構成、デプロイされたインスタンス、ボリュームなどを含む Kubernetes のすべてのリソースは、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 リソース内の 10 つまたは 20 つの数値を変更することが非常に簡単になり、それによってリソースのスケーリング方法が変更されます。 Kubernetes は、ポッドの水平自動スケーリングのメカニズムを提供します。これを使用すると、低レベルと高レベルのトラフィックを処理するために、特定のデプロイメント構成で必要なポッドの最小数と最大数を簡単に決定できます。たとえば、トラフィックの突然の急増により追加の容量が必要な構成をデプロイした場合、maxReplicas を XNUMX から XNUMX に変更できます。

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 バリデータ、プラスポリシーエージェントを開く、コンテキストを確認するためのポリシー検証ツールセキュリティコンテキストワークロードにより、コンテナーを管理者権限で実行することができません。これが必要な場合、ユーザーは簡単なポリシーを適用できます。 REGOこのように：

package main

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

クラウドプロバイダーとの統合オプション。今日のハイテクにおける最も注目すべきトレンドの XNUMX つは、パブリッククラウドプロバイダーでワークロードを実行することです。コンポーネントの使用クラウドプロバイダー Kubernetes を使用すると、任意のクラスターをそれが実行されるクラウドプロバイダーと統合できます。たとえば、ユーザーが AWS 上の Kubernetes でアプリケーションを実行し、そのアプリケーションをサービスを通じて公開したい場合、クラウドプロバイダーがサービスの自動作成を支援します。 LoadBalancerロードバランサーを自動的に提供します Amazon Elastic Load Balancerトラフィックをアプリケーションポッドにリダイレクトします。

拡張性

Kubernetes は拡張性が非常に高いため、開発者はそれを気に入っています。ポッド、デプロイメント、 StatefulSets、秘密、 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

後で、次のような CronTab リソースを作成できます。

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

Kubernetes の拡張性に関するもう XNUMX つのオプションは、開発者が独自のステートメントを作成できることです。オペレータは、「」に従って動作する 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.

別のプロジェクト KUDOを使用すると、宣言的な 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 のメジャーリリースは数か月ごとにリリースされており、つまり、XNUMX 年に XNUMX ～ XNUMX つのメジャーリリースがリリースされています。それぞれに導入される新機能の数は減りません。さらに、この困難な時期でも減速の兆しはありません。現在の状況を見てください。 Github での Kubernetes プロジェクトのアクティビティ.

新機能により、さまざまなワークロードにわたって操作をより柔軟にクラスタリングできるようになります。さらに、プログラマは、アプリケーションを実稼働環境に直接デプロイする際に、より優れた制御を享受できます。

コミュニティ

Kubernetes の人気のもう 2015 つの大きな側面は、コミュニティの強さです。 1.0 年にバージョン XNUMX に到達すると、Kubernetes は次のスポンサーになりました。クラウドネイティブコンピューティング基盤.

さまざまなコミュニティもあります SIG (Special Interest Group) は、プロジェクトの進化に合わせて Kubernetes のさまざまな領域に取り組むことに焦点を当てました。これらのグループは常に新しい機能を追加し、Kubernetes の操作をより便利にしています。

Cloud Native Foundation は、この記事の執筆時点では世界最大のオープンソースカンファレンスである CloudNativeCon/KubeCon も主催しています。通常は年に XNUMX 回開催され、Kubernetes とそのエコシステムを改善し、XNUMX か月ごとに登場する新機能を学びたいと考えている何千人もの専門家が集まります。

さらに、クラウドネイティブ財団は、技術監理委員会、SIG と協力して新規および既存のレビューを行います。プロジェクトクラウドエコシステムに焦点を当てたファンド。これらのプロジェクトのほとんどは、Kubernetes の強みを向上させるのに役立ちます。

最後に、人々が団結しながら同時に新規参入者を歓迎するコミュニティ全体の意識的な努力がなければ、Kubernetes はこれほど成功しなかったと私は信じています。

未来

開発者が将来対処しなければならない主な課題の XNUMX つは、コードが実行されるインフラストラクチャではなく、コード自体の詳細に焦点を当てられるかどうかです。こういったトレンドにも対応していますサーバーレスアーキテクチャパラダイム、今日の主要なもののXNUMXつです。高度なフレームワークはすでに存在します。ネイティブ и OpenFaas、Kubernetes を使用して開発者からインフラストラクチャを抽象化します。

この記事では、Kubernetes の現状の表面をなぞっただけです。実際、それは氷山の一角にすぎません。 Kubernetes ユーザーは、他にも多くのリソース、機能、構成を自由に利用できます。

出所： habr.com

Kubernetes の人気の高まりについて

YAML としてのインフラストラクチャ

拡張性

イノベーション

コミュニティ

未来

コメントを追加します 返信をキャンセル

コメントを追加します返信をキャンセル