Kubernetesを保護する方法

[[408253]]

Kubernetes が開発され、そのテクノロジーが成熟するにつれて、ますます多くの企業がアプリケーションを Kubernetes にデプロイすることを選択するようになっています。しかし、アプリケーションを Kubernetes にデプロイするだけで十分でしょうか?明らかにそうではありません。アプリケーションのコンテナ化は、長い道のりの最初の一歩にすぎません。アプリケーションをいかに安全かつ安定して実行させるかが、その後の作業のすべてです。

ここでは主に以下の側面から整理しますが、ほとんどの企業にとってこれで十分です。

ノード

ノードは物理ホストまたはクラウドホストであり、Kubernetes のキャリアとなります。ほとんどの場合、異常がない限り、Node に何が起こってもあまり気にしません。しかし、運用および保守担当者として、私たちが最も望まないのは例外であり、Node についても同じことが言えます。

ノードは、主に次のような複雑な操作をあまり実行する必要はありません。

> カーネルのアップグレード

ほとんどの企業にとって、CentOS システムは依然として第一の選択肢です。デフォルトでは、7 シリーズ システムのデフォルト バージョンは 3.10 です。このバージョンのカーネルには、Kubernetes コミュニティで既知のバグが多数あるため、ノードのカーネルをアップグレードする必要があります。または、企業は基盤となるオペレーティング システムとして Ubuntu を選択できます。

カーネルをアップグレードする手順は次のとおりです (簡単なアップグレード方法)。

 https://elrepo.org/linux/kernel/el7/x86_64/RPMS/kernel-lt-5.4.86-1.el7.elrepo.x86_64.rpm を取得します。
 rpm -ivh カーネル-lt-5.4.86-1.el7.elrepo.x86_64.rpm
 /boot/grub2/grub.cfg を cat します | grep メニューエントリ
grub2-設定-デフォルト  「CentOS Linux (5.4.86-1.el7.elrepo.x86_64) 7 (コア)」  
 grub2-editenv リスト
grub2-mkconfig -o /boot/grub2/grub.cfg
リブート

>ソフトウェアアップデート

ほとんどの人にとって、互換性の問題を恐れてソフトウェアのアップデートは行われないケースがほとんどです。しかし、実際の運用においては、リスクの高い脆弱性があることが分かっているソフトウェアについては、個別に対処して更新する必要があります。

>Docker構成ファイルの最適化

Docker 構成ファイルの場合、主な最適化はログ ドライバー、ログ サイズ、およびイメージの高速化です。その他の構成は、次のように状況によって異なります。

 cat > /etc/docker/daemon.json << EOF
 {
 "exec-opts" : [ "native.cgroupdriver=systemd" ],
 「ログドライバー」 : 「jsonファイル」 、
 「ログオプション」 : {
 「最大サイズ」 : 「100m」 、
 「最大ファイル数」 : 「10」  
    },
 "bip" : "169.254.123.1/24" 、
 「oom-スコア調整」 : -1000,
 "レジストリミラー" : [ "https://pqbap4ya.mirror.aliyuncs.com" ],
 「ストレージドライバー」 : 「オーバーレイ2」 、
 "ストレージオプション" :[ "overlay2.override_kernel_check=true" ],
 「ライブリストア」 : true  
 }
終了

>kubeletパラメータを最適化する

K8S の場合、kubelet は各ノードのチームリーダーであり、ノードの「食料、衣料、住居、日常生活」を担当します。主なパラメータ設定は次のとおりです。

 cat > /etc/systemd/system/kubelet.service <<EOF
 [ユニット]
説明=kubelet: Kubernetes ノードエージェント
ドキュメント=https://kubernetes.io/docs/ 
 
 
 [サービス]
 ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/pids/system.slice/kubelet.service
 ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/cpu/system.slice/kubelet.service
 ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/cpuacct/system.slice/kubelet.service
 ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/cpuset/system.slice/kubelet.service
 ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/memory/system.slice/kubelet.service
 ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/systemd/system.slice/kubelet.service
 ExecStart=/usr/bin/kubelet \
 --enforce-node-allocatable=ポッド、kube-reserved \  
 --kube-reserved-cgroup=/system.slice/kubelet.service \  
 --kube-reserved=CPU=200m、メモリ=250Mi \  
 --eviction-hard=メモリの空き容量<5%、nodefs の空き容量<10%、imagefs の空き容量<10% \  
 --eviction-soft=メモリの空き容量<10%、ノードの空き容量<15%、イメージの空き容量<15% \  
 --eviction-soft-grace-period=memory.available=2m、nodefs.available=2m、imagefs.available=2m \  
 --eviction-max-pod-grace-period=30 \  
 --eviction-minimum-reclaim=memory.available=0Mi、nodefs.available=500Mi、imagefs.available=500Mi  
再起動=常に
開始制限間隔=0
再起動秒数=10 
 
 
 [インストール]
 WantedBy =マルチユーザー.ターゲット
終了

その主な機能は、各ノードのリソース予約を増やし、ノードのダウンタイムをある程度防ぐことです。

>ログ構成管理

ここでのログ構成管理は、独自に開発したアプリケーション ログではなく、システム ログを対象としています。デフォルトでは、システム ログに特別な構成は必要ありません。私がこれを取り上げるのは、主にログの追跡可能性を確保するためです。何らかの理由でシステムがハッキングされ、システムが削除された場合、分析用にログが提供されます。

したがって、条件が許せば、ノードのシステム ログをリモートでバックアップする必要があります。 rsyslog は構成管理に使用でき、ログはリモート ログ センターまたは OSS に保存できます。

> セキュリティ構成

ここではセキュリティ構成はあまり関係なく、主に既知のセキュリティ問題の強化に重点を置いています。主に 5 つのタイプがあります (もちろん、状況に応じてさらに種類があります)。

• SSH パスワード有効期限ポリシー
• パスワードの複雑さに関するポリシー
• SSH ログイン制限
• システムタイムアウト設定
• 履歴設定

ポッド

Pod は K8S の最小のスケジューリング単位であり、アプリケーションのキャリアです。その安定性はアプリケーション自体に直接関係します。アプリケーションを展開するときは、次の点を考慮する必要があります。

リソースの制限

ポッドはホストのリソースを使用します。適切なリソース制限により、リソースの過剰販売やリソースの優先使用の問題を効果的に回避できます。リソース制限を構成するときは、実際のアプリケーション状況に基づいて Pod の QoS を決定する必要があります。 QoS 構成はそれぞれ異なります。

アプリケーション レベルが比較的高い場合は、保証レベル構成を次のように構成することをお勧めします。

リソース：
  制限:
    メモリ: "200Mi"  
    CPU: "700m"  
  リクエスト:
    メモリ: "200Mi"  
    CPU: "700m"  

アプリケーション レベルが通常の場合は、次のように Burstable レベルを構成することをお勧めします。

リソース：
  制限:
    メモリ: "200Mi"  
    CPU: "500m"  
  リクエスト:
    メモリ: "100Mi"  
    CPU: "100m"  

BestEffort Pod タイプを使用しないことを強くお勧めします。

> スケジュール戦略

スケジュール戦略も状況に応じて決定されます。アプリケーションを特定のノードにスケジュールする必要がある場合は、次のようにアフィニティ スケジューリングを使用できます。

親和性:
  ノードアフィニティ:
    優先スケジュール中は無視実行中:
      - 好み： {}
        重量: 100
    スケジュール中は必須、実行中は無視:
      ノードセレクタ用語:
        - 一致する表現:
            -キー: env
              演算子:  
値：
                -uat

ノードが 1 つのアプリケーションのみをスケジュールすることを許可する場合は、テイント スケジューリングが必要です。つまり、最初にノードが汚染され、次にノードにスケジュールされる必要があるポッドが汚染を許容する必要があります。最も安全な方法は、ラベル付けと染色を組み合わせることです。次のように：

許容範囲:
 - key : "key1" #許容可能な汚染キー 
  演算子: "等しい" #等しいはキー= 値、存在しないは等しくないという意味で、値が次の値と等しくない場合は正常であることを意味します
  値: "値1" #値
  効果: "NoExecute" #効果戦略
  tolerationSeconds: 3600 #元のポッドが削除されるまでにどれくらいの時間がかかりますか?これは effect: "NoExecute"が設定されている場合にのみ設定でき、それ以外の場合はエラーが報告されることに注意してください。

もちろん、Pod と Node 間の関連に加えて、Pod と Pod 間の関連もあります。一般的に、真の高可用性を実現するために、同じアプリケーションのすべての Pod を同じノードにスケジュールすることは推奨されないため、次のように Pod に対してアンチアフィニティ スケジューリングを実行する必要があります。

親和性:
  ポッドアンチアフィニティ:
    スケジュール中は必須、実行中は無視:
    - ラベルセレクター:
        一致表現:
        -キー: アプリ
          演算子:  
値：
          - 店
      トポロジーキー: "kubernetes.io/ホスト名"  

アプリケーションが他のアプリケーションの近くにある場合は、次のようにアフィニティを使用して、ネットワーク遅延をある程度まで削減できます。

親和性:
  ポッドアフィニティ:
    スケジュール中は必須、実行中は無視:
    - ラベルセレクター:
        一致表現:
        -キー: セキュリティ
          演算子:  
値：
          - S1
      トポロジキー: failure-domain.beta.kubernetes.io/zone

>エレガントなアップグレード

デフォルトでは、Pod はローリング アップデート戦略を使用します。私たちの焦点は、新しい Pod が起動した後、外部に気付かれることなく、古い Pod がトラフィックを適切に処理できる方法にあります。

最も簡単な方法は「数秒間スリープする」ことですが、これではトラフィックの 100% の適切な処理が保証されるわけではありません。方法は次のとおりです。

ライフサイクル：
  プレストップ:
実行:
      指示：
      - /bin/sh
      - -c
      - 睡眠15

登録センターがある場合は、終了する前にまず登録センターから元のサービスからログオフすることができます。たとえば、nacos は次のように登録センターとして使用されます。

ライフサイクル：
  プレストップ:
実行:
      指示：
        - /bin/sh
        - -c
        - 「curl -X DELETE your_nacos_ip:8848/nacos/v1/ns/instance?serviceName=nacos.test.1&ip=${POD_IP}&port=8880&clusterName=DEFAULT」 && sleep 15

>プローブ構成

プローブは重要ですか?はい！これは、kubelet が Pod が正常かどうかを判断するための重要な基礎となります。

Pod の主なプローブは次のとおりです。

• ライブネスプローブ
• 準備プローブ
• スタートアッププローブ

このうち、startupProbe はバージョン v1.16 以降に新しく追加されたプローブです。主に起動時間の長いアプリケーションに使用されます。ほとんどの場合、livenessProbe と readinessProbe のみを構成する必要があります。

通常、Pod はアプリケーションを表すため、プローブを構成する際には、アプリケーションが正常かどうかを直接反映するのが最適です。多くのフレームワークにはヘルス検出機能があります。プローブを構成するときに、これらのヘルス検出機能の使用を検討できます。フレームワークにそれらがない場合、標準化されたヘルス検出を容易にするために、開発者に統一されたヘルス検出インターフェースの開発を依頼することも検討できます。次のように：

準備プローブ:
  失敗しきい値: 3
  httpGet:
    パス: /health
    ポート: http
    スキーム: HTTP
  初期遅延秒数: 40
  期間秒数: 10
  成功しきい値: 1
  タイムアウト秒数: 3
ライブネスプローブ:
  失敗しきい値: 3
  httpGet:
    パス: /health
    ポート: http
    スキーム: HTTP
  初期遅延秒数: 60
  期間秒数: 10
  成功しきい値: 1
  タイムアウト秒数: 2

startupProbe を設定する必要がある場合は、次のように設定できます。

スタートアッププローブ:
  httpGet:
    パス: /health
    利益: 80
  失敗しきい値: 10
  初期遅延: 10
  期間秒数: 10

>保護戦略

ここでの保護戦略とは、主に、ポッドを積極的に破棄するときに、保護戦略を通じて実行中のポッドの数を制御することを指します。

K8S では、この機能は PodDisruptionBudget (PDB) を通じて実装されます。いくつかの重要なアプリケーションについては、次のように PDB を構成する必要があります。

 APIバージョン: ポリシー/v1beta1
種類: PodDisruptionBudget
メタデータ:
名前: pdb-demo
仕様:
  最小利用可能数: 2
  セレクタ：
    一致ラベル:
      アプリ: nginx

PDB では、Pod の数は主に次の 2 つのパラメータによって制御されます。

• minAvailable: 利用可能な Pod の最小数を示します。これは、Pod クラスター内で動作している Pod の最小数、または動作している Pod の数の合計数に対する割合を示します。
• maxUnavailable: 使用できない Pod の最大数を示します。これは、Pod クラスター内で使用できない Pod の最大数、または使用できない Pod の数の合計数に対する割合を示します。

注: minAvailable と maxUnavailable は相互に排他的であるため、同時に表示できるのはそのうちの 1 つだけです。

ログ

ログはアプリケーションのライフサイクル全体にわたって実行され、問題のトラブルシューティングやデータの分析に不可欠です。ログについては、主に以下の観点から分析が行われます。

>ログ標準

ログは一般的にビジネスログと例外ログに分けられます。ログが複雑になりすぎたり、単純になりすぎたりすることは望ましくありません。ログを通じて以下の目標を達成したいと考えています。

1. プログラム操作の記録と監視。
2. 必要に応じて、プログラムの内部実行状態に関する詳細な情報を取得できます。
3. システムパフォーマンスへの影響を最小限に抑えます。

ログ標準をどのように定義するのでしょうか?ここにいくつかの簡単なポイントがあります:

• 合理的な使用ログの分類
• 統一された出力形式
• コードエンコーディング標準
• 統合ログ出力パス
• ログ出力の命名規則の統一

この規定の主な目的は、ログの収集と表示を容易にすることです。

>コレクション

ログ出力ごとに異なるログ収集ソリューションがあり、主に次の 2 つがあります。

• 収集のためにノードにロギングエージェントをデプロイする
• サイドカーとしてポッドで収集

収集のためにノードにロギングエージェントをデプロイする

このログ収集ソリューションは、主に標準的な方法で出力されたログを対象としています。アーキテクチャは次のとおりです。

非標準の出力ログを収集する方法はありません。

サイドカーとしてポッドで収集

この収集ソリューションは、主に非標準の出力ログを対象としています。ログ センターにログを収集するためのサイドカーとして、Pod 内でログ収集クライアントを実行できます。アーキテクチャは次のとおりです。

ただし、この方法はリソースの無駄なので、すべてのアプリケーション ログを標準出力に出力して収集しやすくするのが理想的です。

>分析

業務が通常通りのときは、ログの内容を確認することはほとんどありません。問題が発生した場合にのみログを使用して問題を分析します (ほとんどの場合はこれが当てはまります)。では、なぜここで分析を持ち出したいのでしょうか?

ログには実際多くの情報が含まれています。ログを効果的に分析できれば、多くの問題を特定してトラブルシューティングするのに役立ちます。たとえば、Alibaba Cloud のログ センターはログ分析に優れています。

>アラーム

ログアラートを使用すると、問題を迅速に特定し、トラブルシューティングの範囲を絞り込むことができます。ただし、ログアラートを実行するには、ログの「キーワード」管理を適切に行う必要があります。つまり、特定のキーワードが問題を正確に表すことができるようにする必要があります。また、一般的な用語を使用しないことが最善です。これを行う利点は、時間の経過とともに麻痺してしまうようなアラートの嵐や無効なアラートが発生するのではなく、アラートをより準備できる点です。

モニター

クラスターとアプリケーションのライフサイクルは、監視システムと切り離せません。効果的な監視システムは、より高い可観測性を提供し、線形分析、トラブルシューティング、問題の特定を容易にします。また、効果的なアラーム通知と組み合わせることで、問題を迅速に特定するのにも便利です。

モニタリングに関しては、主に以下の側面から紹介します。

>クラスター監視

K8S クラスターと K8S 上で実行されるアプリケーションの場合、監視には Prometheus がよく使用されます。クラスター全体の安定性はアプリケーションの安定性に関係するため、クラスターの監視は非常に重要です。以下は、実際の業務で適宜対応できる監視項目の一部を簡単にまとめたものです。

>アプリケーション監視

多くの企業では、アプリケーション監視が接続されていません。主な原因は、監視インジケーターがアプリケーションに統合されていないため、監視ができないことです。したがって、アプリケーションを開発する際には、開発者がアプリケーション監視を追加し、インジケーターを Prometheus 標準形式で公開することを強くお勧めします。

開発者が積極的にインジケーターを公開することに加えて、Java エージェントを介して一部のエクスポーターを構成して、JVM 監視インジケーターなどの一部のインジケーターをキャプチャすることもできます。

アプリケーション レベルで監視すると、監視の粒度を細かく調整できるため、問題を検出しやすくなります。ここでは、アプリケーション監視項目をいくつか簡単に整理しました。

これらの監視項目は、対応するエクスポーターによって完了します。たとえば、redis ミドルウェアには redis-exporter があり、api 監視には blcakbox-exporter などがあります。

>イベント監視

Kubernetes には 2 種類のイベントがあります。1 つは警告イベントで、このイベントを生成する状態遷移が予期しない状態間で発生したことを示します。もう 1 つは、予想される状態が現在の状態と一致していることを示す通常イベントです。

ほとんどの場合、イベントは現在起こっていること、または起こったことを表します。実際の作業では、このような情報を無視することは簡単なので、このような問題を回避するためにイベント監視を使用する必要があります。

K8S では、一般的に使用されるイベント モニタリングは kube-eventer です。これは、pod/node/kubelet などのリソース オブジェクトのイベントや、カスタム リソース オブジェクトのイベントを収集し、この情報を関係者に送信できます。

イベントを通じて、主に注力している監視項目は以下の通りです。

>リンク監視

通常の状況では、K8S 内のアプリケーションは、明示的な接続のない個別のエンティティとして存在します。このとき、リンク全体の問題を追跡・分析できるように、アプリケーション間の関係性を示す方法が必要です。

現在、人気のあるリンク監視ツールは数多くあります。リンク監視には主にスカイウォーキングを使用します。主剤末端は比較的豊富で、高い自己拡張能力を備えています。興味のある友達はそれについて学ぶことができます。

リンク監視により、次の目標を達成できます。

>アラーム通知

多くの人は警告だけで十分だと考えて、警告通知を無視します。ただし、アラーム通知を行う際には、慎重に検討する必要があります。

以下は焦点の簡単な要約です。

個人的には、どの指標を警告する必要があるかが難しいところにあると思います。指標を選択するときは、次のルールに従う必要があります。

• アラームのインジケーターはユニークです
• アラームインジケーターは問題を正確に反映します
• 明らかになった問題は解決する必要がある

これらすべてのルールを考慮すると、必要な指標を選択しやすくなります。

2 つ目は緊急度の分類です。これは主に、アラーム インジケータによって明らかにされた問題を適時に解決する必要があるかどうかと、影響の範囲に基づいています。

障害エスカレーションは、解決する必要があるが解決されていない問題に対処するために使用される戦略です。障害レベルを上げるということは、緊急度を上げるということと同じです。通知チャネルの分類は、主にさまざまなアラームを区別し、アラーム情報をすばやく受信するのに役立ちます。

最後に

上記は基本的な操作の一部です。 YAML エンジニアにとって、それらは必須のスキルの予備軍です。このセットはほとんどの企業に適用可能です。

この記事はWeChat公開アカウント「運営保守開発ストーリー」から転載したものです。以下のQRコードからフォローできます。この記事を転載する場合は、Operation and Maintenance Development Story のパブリック アカウントにお問い合わせください。