Kubernetes の拡張と補足 (概要とビデオ レポート)

8月XNUMX日のカンファレンスにて 聖ハイロード++ 2019「DevOps と運用」セクションの一部として、「Kubernetes の拡張と補完」レポートが提供され、その作成には Flant 社の従業員 XNUMX 名が参加しました。 その中で、Kubernetes の機能を拡張して補完したいと考えていたものの、既成の簡単なソリューションが見つからなかった多くの状況について話しています。 私たちはオープンソース プロジェクトの形で必要なソリューションを持っており、この講演もそれらに捧げられています。

伝統に従って、私たちは喜んでご紹介します レポートのビデオ (50 分、記事よりもはるかに有益) とテキスト形式の主要な要約。 行く！

K8s のコアと追加機能

Kubernetes は、業界と長年確立されてきた管理のアプローチを変えています。

• 彼に感謝します 抽象化では、構成のセットアップやコマンド (Chef、Ansible など) の実行などの概念を使用して運用するのではなく、コンテナーやサービスなどのグループ化を使用します。
• ニュアンスを考えずに申請書を作成できます。 特定のサイト、ベアメタル、プロバイダーのいずれかのクラウドなどで起動されます。
• K8s を使用すると、かつてないほどアクセスしやすくなります ベストプラクティス インフラストラクチャの組織化について: スケーリング技術、自己修復、耐障害性など。

ただし、もちろん、すべてがそれほどスムーズに進んだわけではありません。Kubernetes には、独自の新たな課題ももたらしました。

Kubernetes ノー 全てのユーザーの悩みを解決するコンバインです。 コア Kubernetes は、Kubernetes に存在する最小限必要な機能のセットのみを担当します。 それぞれ 集まる：

Kubernetes コアは、コンテナーのグループ化、トラフィックの管理などのための基本的なプリミティブ セットを定義します。 それらについて詳しくは、 2年前のレポート.

一方で、K8s は利用可能な機能を拡張する素晴らしい機会を提供し、他の機能を閉じるのに役立ちます。 特定の — ユーザーのニーズ。 Kubernetes への追加はクラスター管理者の責任であり、[特定の問題を解決するために] クラスターを「適切な状態」にするために必要なものすべてをインストールして構成する必要があります。 これらはどのような追加ですか? いくつかの例を見てみましょう。

アドオンの例

Kubernetes をインストールすると、ノード内およびノー​​ド間のポッドの相互作用に非常に必要なネットワークが単独では機能しないことに驚くかもしれません。 Kubernetes カーネルは必要な接続を保証するのではなく、ネットワークを決定します。 интерфейс (CNI) サードパーティのアドオンの場合。 ネットワーク構成を担当するこれらのアドオンのいずれかをインストールする必要があります。

近い例は、データ ストレージ ソリューション (ローカル ディスク、ネットワーク ブロック デバイス、Ceph...) です。 当初、彼らはコアにいたが、出現とともに CSI 状況は、すでに説明したのと同様の状況に変化します。つまり、インターフェースは Kubernetes にあり、その実装はサードパーティのモジュールにあります。

他の例としては次のようなものがあります。

• 進入-コントローラー (彼らのレビューを参照してください) 私たちの最近の記事).
• 証明書マネージャー:

  

• 演算子 これはアドオンのクラス全体 (前述の cert-manager を含む) であり、プリミティブとコントローラーを定義します。 これらの作業ロジックは私たちの想像力によってのみ制限され、既製のインフラストラクチャ コンポーネント (DBMS など) をプリミティブに変換することができます。これにより、(一連のコンテナーとその設定を使用するよりも) はるかに簡単に作業できます。 膨大な数のオペレーターが作成されています。たとえその多くがまだ実稼働の準備ができていないとしても、それは時間の問題です。

  

• メトリクス - Kubernetes がインターフェイス (メトリクス API) を実装 (Prometheus アダプター、Datadog クラスター エージェントなどのサードパーティ アドオンなど) からどのように分離したかを示す別の図。
• のために 監視と統計、実際に必要なだけでなく、 プロメテウスとグラファナだけでなく、kube-state-metrics、node-exporter なども含まれます。

そして、これは追加機能の完全なリストではありません...たとえば、現在私たちが設置しているFlant社では 29 個のアドオン (これらはすべて、合計 249 個の Kubernetes オブジェクトを作成します)。 簡単に言えば、追加を行わなければクラスターの寿命を確認することはできません。

オートメーション

Operator は、私たちが毎日遭遇する日常的な操作を自動化するように設計されています。 演算子を作成することが優れた解決策となる実際の例を次に示します。

1. アプリケーションのイメージを含むプライベート (ログインが必要な) レジストリがあります。 各ポッドには、レジストリでの認証を可能にする特別なシークレットが割り当てられていると想定されます。 私たちのタスクは、ポッドがイメージをダウンロードできるように、このシークレットが名前空間で確実に見つかるようにすることです。 多数のアプリケーション (それぞれにシークレットが必要) が存在する可能性があり、シークレット自体を定期的に更新すると便利なので、シークレットを手動でレイアウトするオプションが不要になります。 ここでオペレーターが助けになります。名前空間が表示されるのを待ち、このイベントに基づいてシークレットを名前空間に追加するコントローラーを作成します。
2. デフォルトでは、ポッドからインターネットへのアクセスは禁止されています。 しかし、場合によってはそれが必要になる場合もあります。たとえば、名前空間に特定のラベルが存在するなど、特定のスキルを必要とせずに、アクセス許可メカニズムが簡単に機能することが論理的です。 ここでオペレーターはどのようにサポートしてくれるでしょうか? ラベルが名前空間に表示されるのを待機し、インターネット アクセスに適切なポリシーを追加するコントローラーが作成されます。
3. 同様の状況: 特定の機能を追加する必要があるとします。 汚れ、同様のラベル（何らかの接頭辞が付いている）がある場合。 オペレーターのアクションは明らかです...

どのクラスターでも、日常的なタスクを解決する必要があり、 正しく これは演算子を使用して実行できます。

説明されたすべての話を要約すると、次のような結論に達しました。 Kubernetes での快適な作業に必要な:A) アドオンをインストールする、b） オペレーターを開発する (日常の管理タスクを解決するため)。

Kubernetes のステートメントを作成するにはどうすればよいですか?

一般に、スキームは単純です。

...しかし、その後、次のことが判明しました。

• Kubernetes API はかなり簡単ではなく、習得するのに多くの時間がかかります。
• プログラミングも万人向けではありません (Go 言語が優先言語として選ばれたのは、Go 言語には特別なフレームワークがあるためです。 オペレーターSDK);
• 状況はフレームワーク自体でも同様です。

ボトムライン： コントローラーを書く （オペレータ）はしなければなりません 多大なリソースを費やす 教材を勉強するために。 これは、「大規模な」オペレータ、たとえば MySQL DBMS の場合には正当化されます。 しかし、上で説明した例 (シークレットの展開、インターネットへのポッドへのアクセスなど) を覚えていれば、これも正しく実行したいと考えていますが、費やされる労力が現在必要な結果を上回ることが理解できるでしょう。

一般に、ジレンマが生じます。大量のリソースを費やしてステートメントを作成するための適切なツールを見つけるか、それとも昔ながらの方法 (ただし迅速に) を行うかです。 それを解決するために、これらの両極端の間の妥協点を見つけるために、私たちは独自のプロジェクトを作成しました。 シェルオペレーター (彼の 最近の発表 ハブ上).

シェルオペレーター

彼はどのように働いていますか? クラスターには、シェル演算子を備えた Go バイナリを含むポッドがあります。 彼の隣には次のセットがあります。 フック (詳細については、以下を参照してください)。 シェルオペレーター自体は特定のものをサブスクライブします 進展 Kubernetes API では、これが発生すると、対応するフックが起動されます。

シェルオペレーターはどのイベントでどのフックを呼び出すべきかをどのようにして知るのでしょうか? この情報はフック自体によってシェルオペレーターに送信され、フックはそれを非常に簡単に実行します。

フックは、単一の引数を受け入れる Bash スクリプトまたはその他の実行可能ファイルです。 --config JSON で応答します。 後者は、どのオブジェクトが対象となるか、および (これらのオブジェクトの) どのイベントに応答する必要があるかを決定します。

私たちの例の XNUMX つである、アプリケーション イメージを使用してプライベート レジストリにアクセスするためのシークレットの分解のシェル オペレーターでの実装を説明します。 それは XNUMX つの段階で構成されます。

練習: 1. フックを書く

まずフック内で処理します --configこれは、名前空間、特にその作成の瞬間に興味があることを示しています。

[[ $1 == "--config" ]] ; then
  cat << EOF
{
  "onKubernetesEvent": [
    {
      "kind": "namespace",
      "event": ["add"]
    }
  ]
}
EOF
…

ロジックはどのようになるでしょうか? こちらも非常にシンプルです:

…
else
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  kubectl create -n ${createdNamespace} -f - << EOF
Kind: Secret
...
EOF
fi

最初のステップは、どの名前空間が作成されたかを調べることであり、XNUMX 番目のステップは、次のコマンドを使用して名前空間を作成することです。 kubectl この名前空間の秘密。

練習: 2. 画像を組み立てる

残っているのは、作成したフックをシェルオペレーターに渡すことだけです。これを行うにはどうすればよいでしょうか? シェル オペレーター自体は Docker イメージとして提供されるため、私たちのタスクは、このイメージ内の特別なディレクトリにフックを追加することです。

FROM flant/shell-operator:v1.0.0-beta.1
ADD my-handler.sh /hooks

残っているのは、それを組み立ててプッシュすることだけです。

$ docker build -t registry.example.com/my-operator:v1 .
$ docker push registry.example.com/my-operator:v1

最後の仕上げは、イメージをクラスターにデプロイすることです。 これを行うには、次のように書きましょう 展開:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1 # 1
      serviceAccountName: my-operator              # 2

注意すべき点は次の XNUMX つです。

1. 新しく作成されたイメージの表示。
2. これは、Kubernetes でイベントをサブスクライブし、名前空間にシークレットを割り当てる権限が (少なくとも) 必要なシステム コンポーネントであるため、フック用の ServiceAccount (およびルールのセット) を作成します。

結果 - 問題は解決しました 親戚に Kubernetes の場合、シークレットを分解するためのオペレーターを作成する方法で。

その他のシェル オペレーター機能

フックが動作する選択したタイプのオブジェクトを制限するには、 それらはフィルタリングできます、特定のラベルに従って選択（または使用） matchExpressions):

"onKubernetesEvent": [
  {
    "selector": {
      "matchLabels": {
        "foo": "bar",
       },
       "matchExpressions": [
         {
           "key": "allow",
           "operation": "In",
           "values": ["wan", "warehouse"],
         },
       ],
     }
     …
  }
]

提供された 重複排除メカニズムこれにより、jq フィルターを使用して、大きな JSON オブジェクトを小さな JSON オブジェクトに変換できます。変更を監視したいパラメーターのみが残ります。

フックが呼び出されると、シェルオペレーターはフックを渡します。 オブジェクトデータ、あらゆるニーズに対応できます。

フックをトリガーするイベントは Kubernetes イベントに限定されません。シェル オペレーターは次のサポートを提供します。 時間によるフックの呼び出し (従来のスケジューラの crontab に似ています)、および特別なイベント 始めるとき。 これらすべてのイベントを組み合わせて、同じフックに割り当てることができます。

そして、シェル オペレーターにはさらに XNUMX つの機能があります。

1. できます 非同期的に。 Kubernetes イベント (オブジェクトの作成など) が受信されたため、他のイベント (同じオブジェクトの削除など) がクラスター内で発生した可能性があり、フックはこれを考慮する必要があります。 フックがエラーで実行された場合、デフォルトでは次のようになります。 想起 正常に完了するまで (この動作は変更可能です)。
2. 輸出する メトリクス Prometheus の場合、シェル オペレーターが動作しているかどうかを把握でき、各フックのエラー数と現在のキュー サイズを確認できます。

レポートのこの部分を要約すると、次のようになります。

アドオンのインストール

Kubernetes で快適に作業するためには、アドオンをインストールする必要性についても言及されました。 当社が現在どのように取り組んでいるかを例に挙げて説明します。

私たちはいくつかのクラスターを使用して Kubernetes の使用を開始しましたが、それに追加されたのは Ingress だけでした。 クラスターごとに異なる方法でインストールする必要があり、ベアメタル、AWS などのさまざまな環境に合わせていくつかの YAML 構成を作成しました。

クラスターが増えると、構成も増えます。 さらに、これらの構成自体を改善した結果、かなり異質なものになりました。

すべてを整理するために、スクリプト (install-ingress.sh) は、デプロイ先のクラスターのタイプを引数として受け取り、必要な YAML 構成を生成し、それを Kubernetes にロールアウトします。

つまり、私たちのさらなる道筋とそれに関連する推論は次のとおりです。

• YAML 構成を操作するには、テンプレート エンジンが必要です (最初の段階では、これは単純な sed です)。
• クラスターの数が増加するにつれて、自動更新の必要性が生じました (最も初期の解決策は、スクリプトを Git に置き、cron を使用して更新して実行することでした)。
• Prometheus にも同様のスクリプトが必要でした (install-prometheus.sh) ただし、より多くの入力データとそのストレージ (良い意味で一元化されクラスター内) が必要であり、一部のデータ (パスワード) は自動的に生成される可能性があるという事実で注目に値します。

  

• 増え続けるクラスターに何か問題が展開されるリスクは常に増大しているため、インストーラーが (つまり、Ingress と Prometheus 用の XNUMX つのスクリプト) ステージングが必要でした (Git 内のいくつかのブランチ、対応する安定クラスターまたはテストクラスターでそれらを更新するためのいくつかの cron)。
• с kubectl apply 宣言的ではなく、オブジェクトの作成のみが可能で、そのステータスの決定やオブジェクトの削除はできないため、操作が難しくなりました。
• 当時まったく実装していなかったいくつかの機能が欠けていました。
  • クラスターの更新結果を完全に制御します。
  • クラスターから取得できるデータに基づいていくつかのパラメーター (インストール スクリプトの入力) を自動的に決定 (検出)、
  • 継続的な発見の形での論理的展開。

私たちは、この蓄積された経験をすべて他のプロジェクトの枠組み内で実装しました。 アドオンオペレーター.

アドオンオペレーター

これは、すでに述べたシェル演算子に基づいています。 システム全体は次のようになります。

以下がシェル演算子のフックに追加されます。

• 価値観のストレージ,
• ヘルムチャート,
• コンポーネント 値ストアを監視します そして、変更があった場合には、Helm にチャートを再ロールするよう依頼します。

したがって、Kubernetes のイベントに反応してフックを起動し、このフックからストレージに変更を加えることができ、その後、チャートが再ダウンロードされます。 結果として得られる図では、フックのセットとチャートを XNUMX つのコンポーネントに分離します。これを モジュール:

多くのモジュールが存在する可能性があり、それらにグローバル フック、グローバル値ストア、およびこのグローバル ストアを監視するコンポーネントを追加します。

これで、Kubernetes で何かが発生したときに、グローバル フックを使用してそれに反応し、グローバル ストア内の何かを変更できます。 この変更は認識され、クラスター内のすべてのモジュールがロールアウトされます。

このスキームは、上記で説明したアドオンをインストールするための要件をすべて満たしています。

• Helm はテンプレート化と宣言性を担当します。
• 自動更新の問題は、グローバル フックを使用して解決されました。グローバル フックは、スケジュールに従ってレジストリにアクセスし、そこに新しいシステム イメージがあれば、それをロールアウトします (つまり、「それ自体」)。
• クラスターへの設定の保存は、次を使用して実装されます。 構成マップこれには、ストレージのプライマリ データが含まれています (起動時にストレージにロードされます)。
• パスワードの生成、検出、継続的検出に関する問題は、フックを使用して解決されました。
• ステージングは​​、Docker がすぐにサポートするタグのおかげで実現されます。
• 結果は、状態を把握できるメトリクスを使用して監視されます。

このシステム全体は、Go では addon-operator と呼ばれる単一のバイナリの形式で実装されます。 これにより、図がより単純に見えます。

この図の主なコンポーネントはモジュールのセットです (以下の灰色で強調表示されています)。 これで、必要なアドオンのモジュールを少しの労力で作成できるようになり、それが各クラスターにインストールされ、更新され、クラスター内で必要なイベントに応答することを確認できます。

「フラット」の使い方 アドオンオペレーター 70 以上の Kubernetes クラスター上で。 現在のステータス - アルファ版。 現在、ベータ版をリリースするためのドキュメントを準備していますが、今のところはリポジトリにあります 利用可能な例, これに基づいて独自のアドオンを作成できます。

addon-operator のモジュールはどこで入手できますか? ライブラリの出版は私たちにとって次の段階であり、夏に行う予定です。

ビデオとスライド

パフォーマンスのビデオ (約 50 分):

報告書のプレゼンテーション:

PS

私たちのブログの他のレポート:

• «データベースとKubernetes"; (Dmitry Stolyarov、8 年 2018 月 XNUMX 日 HighLoad++);
• «モニタリングとKubernetes"; (ドミトリー・ストリャロフ、28 年 2018 月 XNUMX 日、RootConf にて);
• «Kubernetes と GitLab を使用した CI/CD のベスト プラクティス"; (Dmitry Stolyarov、7 年 2017 月 XNUMX 日 HighLoad++);
• «小規模プロジェクトにおける Kubernetes の経験"; (ドミトリー・ストリャロフ、6 年 2017 月 XNUMX 日、RootConf にて).

次の出版物にも興味があるかもしれません。

• «シェル オペレーターの紹介: Kubernetes のオペレーターの作成がさらに簡単になりました'。

出所： habr.com