DUICUO

現在の場所： ホーム > 記事 > Kubernetes YAML ファイルの静的解析ツールである KubeLinter をお勧めします。

Kubernetes YAML ファイルの静的解析ツールである KubeLinter をお勧めします。

Kubernetesの世界では、YAMLファイルを使用して様々なKubernetesオブジェクトをデプロイおよび作成しますが、課題は、YAMLファイルの記述時にベストプラクティスに従っているかどうかにあります。正しい標準構成セットを使用していますか？アプリケーションやHelmダイアグラムをデプロイする前に、YAMLを検査できますか？これらの質問に対する答えはすべて「はい、できます」です。2020年10月28日、StackRoxはYAMLファイル内の構成ミスを特定するために設計されたKubeLinterという新しいオープンソースツールを発表しました。

KubeLinterは、Kubernetes YAMLファイルとHelmダイアグラムを検査し、それらで表現されるアプリケーションがベストプラクティスに準拠していることを確認するための静的解析ツールです。YAMLファイルをツールに渡すと、ツールは組み込みチェックを実行し、エラーがあれば詳細を報告し、その解決策も提示します。このツールの最大の利点は、設定と拡張性に優れていることです。組み込みチェックは有効化/無効化できるほか、独自のカスタムチェックを定義して使用することも可能です。

使用法

私は Mac に KubeLinter をインストールしますが、Linux でも、ご使用のオペレーティング システム用のディストリビューションをダウンロードするだけで同じ手順を使用できます。

以下に示すように、KubeLinter CLI は https://github.com/stackrox/kube-linter/releases/ からダウンロードできます。

  1.  $カール -LO https://github.com/stackrox/kube-linter/releases/download/0.1.1/kube-linter-darwin.zip  
  2.  $ kube-linter-darwin.zip を解凍します 
  3.  $ mv kube-linter /usr/local/bin  
  4.  #動作しているか確認する 
  5.  $ kube-linter バージョン 
  6.  0.1.1

単一のYAMLファイルを簡単に検査するには、YAMLファイル名を指定するだけです。例えば、deploy.yamlというファイルを検査し、現在のディレクトリに保存されているセキュリティと設定のベストプラクティスをチェックするとします。

  1.  apiバージョン: apps/v1  
  2. 種類: デプロイメント 
  3. メタデータ:  
  4. 名前: ポーター 
  5. 名前空間: portainer  
  6. ラベル:  
  7.     io.porttainer.kubernetes.application.stack: ポートライナー 
  8.  app.kubernetes.io/name: ポーテイン 
  9.  app.kubernetes.io/instance: ポータナー 
  10.  app.kubernetes.io/バージョン: "2.0.0"  
  11. 仕様:  
  12. レプリカ: 1  
  13. 戦略：  
  14. タイプ:「再作成」  
  15. セレクタ：  
  16. 一致ラベル:  
  17.  app.kubernetes.io/name: ポーテイン 
  18.  app.kubernetes.io/instance: ポータナー 
  19. テンプレート：  
  20. メタデータ:  
  21. ラベル: 
  22.   app.kubernetes.io/name: ポーテイン 
  23.  app.kubernetes.io/instance: ポータナー 
  24. 仕様:  
  25. サービスアカウント名: portainer-sa-clusteradmin  
  26. ボリューム:  
  27.  - 名前:「データ」  
  28.            永続ボリュームクレーム:  
  29. クレーム名: portainer  
  30. コンテナ:  
  31.  - 名前: ポーター 
  32.           画像: "ポーター/ポーター-CE:最新"  
  33.           imagePullPolicy: IfNotPresent  
  34. 引数: [ '--tunnel-port','30776' ]  
  35. ボリュームマウント:  
  36.  - 名前: データ 
  37. マウントパス: /data  
  38. ポート:  
  39.  - 名前: http  
  40. コンテナポート: 9000  
  41. プロトコル: TCP  
  42.  - 名前: tcp-edge  
  43. コンテナポート: 8000  
  44. プロトコル: TCP  
  45. ライブネスプローブ:  
  46.  httpGet:  
  47. パス： /  
  48. ポート: 9000  
  49. 準備プローブ:  
  50.  httpGet:  
  51. パス： /  
  52. ポート: 9000  
  53. リソース：  
  54.  {}

kube-linter lint deploy.yaml をテストしてみましょう。次のような出力が得られるはずです。

  1.  deploy.yaml: (オブジェクト: portainer/portainer apps/v1、 Kind = Deployment ) コンテナ「portainer」には読み取り専用のルート ファイル システムがありません (チェック: no-read-only-root-fs、解決方法: コンテナの securityContext で readOnlyRootFilesystem を true に設定します。)
  2.  deploy.yaml: (オブジェクト: portainer/portainer apps/v1、 Kind = Deployment ) serviceAccount "portainer-sa-clusteradmin" が見つかりません (チェック: 存在しないサービス アカウント、修復: サービス アカウントを作成するか、既存のサービス アカウントを参照するようにしてください。)
  3.  deploy.yaml: (オブジェクト: portainer/portainer apps/v1、 Kind = Deployment ) コンテナ「portainer」が runAsNonRoot に設定されていません (チェック: run-as-non-root、修正: ポッドまたはコンテナの securityContext で、runAsUser をゼロ以外の数値に設定し、runAsNonRoot を true に設定します。詳細については、https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ を参照してください。)
  4.  deploy.yaml: (オブジェクト: portainer/portainer apps/v1、 Kind = Deployment ) コンテナ「portainer」の CPU 要求は 0 です (チェック: unset-cpu-requirements、修復: コンテナの要件に応じて、CPU 要求と制限を設定します。詳細については、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits を参照してください。)
  5.  deploy.yaml: (オブジェクト: portainer/portainer apps/v1、 Kind = Deployment ) コンテナ「portainer」の CPU 制限は 0 です (チェック: unset-cpu-requirements、修正: コンテナの要件に応じて、CPU 要求と制限を設定します。詳細については、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits を参照してください。)
  6.  deploy.yaml: (オブジェクト: portainer/portainer apps/v1、 Kind = Deployment ) コンテナ「portainer」にはメモリ要求 0 があります (チェック: unset-memory-requirements、修復: コンテナの要件に応じて、コンテナのメモリ要求と制限を設定します。詳細については、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits を参照してください。)
  7.  deploy.yaml: (オブジェクト: portainer/portainer apps/v1、 Kind = Deployment ) コンテナ「portainer」のメモリ制限は 0 です (チェック: unset-memory-requirements、修復: コンテナの要件に応じて、コンテナのメモリ要求と制限を設定します。詳細については、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits を参照してください。)
  8. エラー: 7 件の lint エラーが見つかりました

検出タイプ

ご覧のとおり、YAML ファイルにエラーが見つかり、各エラーには明確な修正手順があります。

組み込みチェックを確認したい場合は、https://github.com/stackrox/kube-linter/blob/main/docs/genic/checks.md にすべてリストされています。または、KubeLinter を使用してマニフェストを表示することもできます。

  1.  $ kube-linter チェックリスト 
  2. 名前: dangling-service  
  3. 説明: 一致するデプロイメントがないサービスに関するアラート 
  4. 修復: サービスのセレクターが、いずれかのデプロイメントのラベルと正しく一致していることを確認します。  
  5. テンプレート: dangling-service  
  6. パラメータ: map[]  
  7. デフォルトで有効: true  
  8.  ------------------------------  
  9. 名前: デフォルトサービスアカウント 
  10. 説明: デフォルトのサービス アカウントを使用するポッドに関するアラート 
  11. 修正方法: ポッド専用のサービスアカウントを作成してください。詳細については、https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/ をご覧ください。
  12. テンプレート: サービスアカウント 
  13. パラメータ: map[serviceAccount:^(|default)$]  
  14. デフォルトで有効: false  
  15.  |  
  16.  |  
  17.  |  
  18. その他多数

検出を無視

次のコメントを使用して、YAML ファイルの特定のチェックを無視したり、必要に応じてチェックのグループを無視したりできます。

  1.  ignore-check.kube-linter.io/ <チェック名>  

例えば：

  1.  ignore-check.kube-linter.io/unset-cpu-requirements

上記のデプロイメント ファイルの例のように、無視チェック ルールを追加できます。

  1. メタデータ:  
  2. 名前: ポーター 
  3. 名前空間: portainer  
  4. ラベル: 
  5.      io.porttainer.kubernetes.application.stack: ポートライナー 
  6.  app.kubernetes.io/name: ポーテイン 
  7.  app.kubernetes.io/instance: ポータナー 
  8.  app.kubernetes.io/バージョン: "2.0.0"  
  9. 注釈:  
  10.  ignore-check.kube-linter.io/unset-cpu-requirements : 「CPU 要件は必要ありません」

これで、`kube-linter lint deploy.yaml` を再度実行すると、CPU 要件に関連するエラー メッセージが表示されなくなります。

構成を使用して実行

KubeLinterは、検出対象とする情報すべてを指定できる設定で実行することもできます。リポジトリから取得した設定例を以下に示します。

  1.  # customChecks はカスタムチェックを定義します。  
  2. カスタムチェック:  
  3.  - 名前: "必須ラベルアプリ"  
  4. テンプレート: "必須ラベル"  
  5. パラメータ:  
  6. キー: "アプリ"  
  7. チェック: 
  8.   # doNotAutoAddDefaults が true の場合、デフォルトのチェックは自動的に追加されません。  
  9. 自動追加デフォルトを無効にします: false  
  10.  # addAllBuiltIn が設定されている場合、すべての組み込みチェックが追加されます。これにより、ユーザーは 
  11.  # Exclude を使用して関連のないチェックを明示的にオプトアウトします。  
  12.  # 両方が設定されている場合は、doNotAutoAddDefaults よりも優先されます。  
  13.  addAllBuiltIn: false  
  14.  # include はチェックを明示的に名前で追加します。組み込みのチェックはどれでも参照できます。  
  15.  # 上記で定義された customChecks は自動的に含まれることに注意してください。  
  16. 含む：  
  17.  - 「必須ラベル所有者」  
  18.  # exclude は、名前で明示的にチェックを除外します。exclude は最高の優先順位を持ちます。チェックが 
  19.  # exclude に含まれていれば、include に含まれていても考慮されません。  
  20. 除外:  
  21.  - 「特権」

`kubelinter --config config lint deploy.yaml` (`config` は上記の設定ファイルと同じ) を実行すると、タグのチェックが追加されていることがわかります。

deploy.yaml: (オブジェクト: portainer/portainer apps/v1、種類 = デプロイメント) 「owner=<any>」に一致するラベルが見つかりません (チェック: required-label-owner、解決方法: オブジェクトの所有者に関する情報を含む電子メール注釈をオブジェクトに追加します。)

KubeLinter は、CI パイプラインに統合することで、非常に便利なツールとなります。リポジトリにプッシュされたオーケストレーション ファイルを検査・検証し、ベストプラクティスやセキュリティ上の考慮事項を検証し、問題が検出されるとアラートを生成できます。

これにより、クラスタにデプロイされたアプリケーションのヘルスチェックと準備状況のチェックが可能になります。このプロジェクトは現在アルファ段階ですが、実際の本番環境へのデプロイ前に、CI統合ツールとしてすべてのデプロイメントを検証することを目指しています。

ラベル

関連するおすすめ記事

ランダムにおすすめされた記事

人気のタグ