より優れたコンテナ オーケストレーションのための 10 の Kubernetes ベスト プラクティス

Kubernetes を使用する際に従うべきベスト プラクティスのいくつかについて説明しましょう。

Kubernetes は、コンテナのデプロイ、継続的なスケーリングとスケール解除、コンテナの負荷分散などを自動化するオープンソースのコンテナ オーケストレーション プラットフォームです。

コンテナ化は、数千個のコンテナを備えた多くの実稼働サーバーで使用されているため、それらを適切に管理することが非常に重要になり、それを Kubernetes が行います。

Kubernetes を使用している場合は、コンテナ オーケストレーションを改善するためのベスト プラクティスを採用する必要があります。

ここでは、従う必要がある Kubernetes のベスト プラクティスのいくつかをリストします。

#1. リソースのリクエストと制限を設定する

リソースが限られた実稼働クラスターに大規模なアプリケーションをデプロイしている場合、ノードのメモリまたは CPU が不足すると、アプリケーションは動作を停止します。このアプリケーションのダウンタイムは、ビジネスに大きな影響を与える可能性があります。ただし、リソースのリクエストと制限を設定することでこれを解決できます。

リソースに対するリクエストと制限は、メモリや CPU などのリソースの使用を制御する Kubernetes のメカニズムです。 1 つのポッドがすべての CPU とメモリを消費すると、他のポッドはリソースが不足し、アプリケーションを実行できなくなります。したがって、信頼性を高めるために、ポッドにリソースのリクエストと制限を設定する必要があります。

参考までに、制限は常にリクエストよりも高くなります。リクエストが定義された制限を超えている場合、コンテナーは実行されません。ポッド内のコンテナごとにリクエストと制限を設定できます。 CPU はミリコアを使用して定義され、メモリはバイト (メガバイト/メビバイト) を使用して定義されます。

以下は、制限を 500 ミリコア CPU および 128 メビバイトに設定し、リクエストのクォータを 300 ミリコア CPU および 64 メビバイトに設定する例です。

 containers:
- name: prodcontainer1
    image: ubuntu
    resources:
        requests:
            memory: “64Mi”
            cpu: “300m”
        limits:                              
            memory: “128Mi”
            cpu: “500m”

#2. livenessProbe と readinessProbe を使用する

Kubernetes ではヘルスチェックは非常に重要です。

Readiness プローブと Liveness プローブという 2 種類のヘルスチェックが提供されます。

Readiness プローブは、アプリがトラフィックの処理を開始する準備ができているかどうかを確認するために使用されます。このプローブは、コンテナ内でアプリケーションを実行しているポッドへのトラフィックの送信を開始する前に、Kubernetes を通過する必要があります。 Kubernetes は、この準備状況チェックが失敗するまで、ポッドへのトラフィックの送信を停止します。

Liveness プローブは、アプリがまだ実行中 (生きている) か、停止している (停止している) かを確認するために使用されます。アプリが適切に実行されている場合、Kubernetes は何も行いません。アプリケーションが停止した場合、Kubernetes は新しいポッドを起動し、その中でアプリケーションを実行します。

これらのチェックが適切に実行されない場合、ポッドは終了するか、準備が整う前にユーザー リクエストの取得を開始する可能性があります。

稼働状況と準備状況のチェックに使用できるプローブには、 HTTP 、 Command 、 および TCP の 3 種類があります。

最も一般的な HTTP プローブの例を示します。

ここで、アプリケーションの内部には HTTP サーバーが含まれます。 Kubernetes が HTTP サーバーへのパスに ping を実行し、HTTP 応答を取得すると、アプリケーションは正常であるとマークされ、それ以外の場合は異常であるとマークされます。

 apiVersion: v1
kind: Pod
metadata:
 name: container10
spec:
 containers:
   - image: ubuntu
     name: container10
     livenessProbe:
       httpGet:
         path: /prodhealth
         port: 8080

#3. 小さなコンテナイメージを構築する

必要なストレージが少なくなり、イメージのプルとビルドをより速く行うことができるため、より小さいコンテナー イメージを使用することをお勧めします。画像のサイズが小さくなるため、セキュリティ攻撃の可能性も低くなります。

コンテナーのサイズを縮小するには、より小さいベースイメージを使用する方法とビルダーパターンを使用する方法の 2 つがあります。現在、最新の NodeJS 基本イメージは 345 MB ですが、NodeJS アルパイン イメージはわずか 28 MB で、10 分の 1 以上小さいです。したがって、常に小さいイメージを使用し、アプリケーションの実行に必要な依存関係を追加してください。

コンテナー イメージをさらに小さくするには、ビルダー パターンを使用できます。コードは最初のコンテナーでビルドされ、コンパイルされたコードは、コンパイルされたコードの作成に必要なコンパイラーやツールをすべて使用せずに最後のコンテナーにパッケージ化されるため、コンテナー イメージはさらに小さくなります。

#4. 許可の安全なアクセス レベル (RBAC)

安全な Kubernetes クラスターを構築することは非常に重要です。

クラスターへのアクセスは適切に構成する必要があります。ユーザーごとの秒/分/時間あたりのリクエスト数、IP アドレスごとに許可される同時セッション数、リクエストのサイズ、パスとホスト名の制限を定義する必要があります。これは、クラスターを DDoS 攻撃から安全に保つのに役立ちます。

Kubernetes クラスターで作業する開発者および DevOps エンジニアは、定義されたレベルのアクセス権を持っている必要があります。ここでは、Kubernetes のロールベースのアクセス制御 (RBAC) 機能が役立ちます。ロールとクラスターロールを使用してアクセスプロファイルを定義できます。 RBAC の構成を容易にするために、構文の簡素化に役立つオープンソースの rbac-manager を 使用するか、デフォルトで RBAC を提供する Rancher を 使用できます。

 apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

Kubernetes Secret には、認証トークン、パスワード、SSH キーなどの機密情報が保存されます。 IaC リポジトリ上の Kubernetes Secret を決してチェックしないでください。チェックしないと、Git リポジトリにアクセスできるユーザーに公開されてしまいます。

DevSecOps は現在、DevOps とセキュリティについて語るバズワードです。組織はその重要性を理解しており、このトレンドを採用しています。

#5. 最新の状態を保つ

クラスターには常に最新バージョンの Kubernetes をインストールすることをお勧めします。

Kubernetes の最新バージョンには、新機能、以前の機能の更新、セキュリティ更新、バグ修正などが含まれています。クラウド プロバイダーで Kubernetes を使用している場合、更新は非常に簡単になります。

#6. 名前空間を使用する

Kubernetes には、 default 、 kube-system、 および kube-public という 3 つの異なる名前空間が付属しています。

これらの名前空間は、Kubernetes クラスターにおいてチーム間の組織化とセキュリティのために非常に重要な役割を果たします。

5 ～ 10 個のマイクロサービスだけを扱う小規模なチームの場合は、デフォルトの名前空間を使用するのが合理的です。しかし、急速に成長しているチームや大規模な組織では、複数のチームがテスト環境または運用環境で作業しているため、管理を容易にするために各チームに個別の名前空間が必要です。

そうしないと、気付かないうちに、他のチームのアプリケーション/機能を誤って上書きしたり、中断したりしてしまう可能性があります。複数の名前空間を作成し、それらを使用してサービスを管理可能なチャンクに分割することをお勧めします。

名前空間内にリソースを作成する例を次に示します。

 apiVersion: v1
kind: Pod
metadata:
   name: pod01
namespace: prod
   labels:
      image: pod01
spec:
   containers:
- name: prod01
  Image: ubuntu

＃7。 ラベルを使用する

Kubernetes デプロイメントが拡大するにつれて、必ず複数のサービス、ポッド、その他のリソースが含まれるようになります。これらを追跡するのは面倒になる場合があります。さらに難しいのは、これらのさまざまなリソースがどのように相互作用するか、それらをどのようにレプリケート、スケーリング、サービスするかを Kubernetes で説明することです。 Kubernetes のラベルは、これらの問題を解決するのに非常に役立ちます。

ラベルは、Kubernetes インターフェイス内で項目を整理するために使用されるキーと値のペアです。

たとえば、アプリ: kube-app、フェーズ: テスト、ロール: フロントエンド。これらは、クラスター内のさまざまなオブジェクトやリソースがどのように連携するかを Kubernetes で記述するために使用されます。

 apiVersion: v1
kind: Pod
metadata:
 name: test-pod
 labels:
   environment: testing
   team: test01
spec:
 containers:
   - name: test01
     image: "Ubuntu"
     resources:
       limits:
        cpu: 1

したがって、リソースとオブジェクトに常にラベルを付けることで、Kubernetes 運用の​​手間を軽減できます。

#8. 監査ログ

Kubernetes クラスター内の脅威を特定するには、ログの監査が非常に重要です。監査は、何が起こったのか、なぜ起こったのか、誰がそれを引き起こしたのかなどの質問に答えるのに役立ちます。

kube-apiserver に対して行われたリクエストに関連するすべてのデータは、 audit.log というログ ファイルに保存されます。このログ ファイルは JSON 形式で構造化されています。

Kubernetes では、デフォルトで監査ログは <em>/var/log/audit.log</em> に保存され、監査ポリシーは <em>/etc/kubernetes/audit-policy.yaml</em> </em> に存在します。 <em>/etc/kubernetes/audit-policy.yaml</em> 。

監査ログを有効にするには、次のパラメータを使用して kube-apiserver を起動します。

 --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/audit.log

ポッドの変更をログに記録するように構成されたサンプルの audit.log ファイルを次に示します。

 apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - "RequestReceived"
rules:
  - level: RequestResponse
    resources:
    - group: ""
      resources: ["pods"]
   - level: Metadata
     resources:
     - group: ""
      resources: ["pods/log", "pods/status"]

Kubernetes クラスターで問題が発生した場合には、いつでも監査ログに戻って確認することができます。これは、クラスターの正しい状態を復元するのに役立ちます。

#9. アフィニティ ルールの適用 (ノード/ポッド)

Kubernetes には、ポッドとノードをより適切に関連付けるための 2 つのメカニズム、 ポッド と ノードの アフィニティがあります。パフォーマンスを向上させるために、これらのメカニズムを使用することをお勧めします。

ノード アフィニティを使用すると、定義された基準に基づいてノード上のポッドをスケジュールできます。ポッドの要件に応じて、一致するノードが選択され、Kubernetes クラスターに割り当てられます。

 apiVersion: v1
kind: Pod
metadata:
  name: ubuntu
spec:
  affinity:
    nodeAffinity:    
preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 2
        preference:        
matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd          
  containers:
  - name: ubuntu
    image: ubuntu
    imagePullPolicy: IfNotPresent

ポッド アフィニティを使用すると、同じノード上で複数のポッドをスケジュールしたり (レイテンシの改善のため)、またはパフォーマンスを向上させるために (高可用性のため) ポッドを別のノードに保持することを決定したりできます。

 apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-pod
spec:
  affinity:
    podAffinity:
     
requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
         
matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: failure-domain.beta.kubernetes.io/zone
  containers:
  - name: ubuntu-pod
    image: ubuntu

クラスターのワークロードを分析した後、どのアフィニティ戦略を使用するかを決定する必要があります。

＃10。 Kubernetesの終了

Kubernetes は、ポッドが不要になるとポッドを終了します。これはコマンドまたは API 呼び出しを通じて開始でき、選択したポッドは終了状態になり、それらのポッドにトラフィックは送信されません。その後、SIGTERM メッセージがそれらのポッドに送信され、その後ポッドがシャットダウンされます。

ポッドは正常に終了されます。デフォルトの猶予期間は 30 秒です。ポッドがまだ実行中の場合、Kubernetes はポッドを強制的にシャットダウンする SIGKILL メッセージを送信します。最後に、これらのポッドは Kubernetes によってマスター マシン上の API サーバーから削除されます。

ポッドに常に 30 秒以上かかる場合は、この猶予期間を 45 秒または 60 秒に増やすことができます。

 apiVersion: v1
kind: Pod
metadata:
 name: container10
spec:
 containers:
   - image: ubuntu
     name: container10
  terminationGracePeriodSeconds: 60

結論

これらのベスト プラクティスが、Kubernetes を使用したコンテナ オーケストレーションの向上に役立つことを願っています。より良い結果を得るために、これらを Kubernetes クラスターに実装してみてください。

次に、DevOps の成功に最適な Kubernetes ツールを検討します。