Operator 環境のパフォーマンスに関する考慮事項

Pod の Kubernetes の概念は、「1 つのホストに一緒にデプロイされる 1 つ以上のコンテナーであり、定義、デプロイ、または管理できる最小のコンピューティングユニット」です。

Pod は、コンテナーに対して、(物理または仮想) マシンインスタンスと同等のものです。各 Pod は独自の内部 IP アドレスで割り当てられるため、そのポートスペース全体を所有し、Pod 内のコンテナーはそれらのローカルストレージおよびネットワークを共有できます。

Pod にはライフサイクルがあります。それらは定義された後にノードで実行するために割り当てられ、コンテナーが終了するまで実行するか、その他の理由でコンテナーが削除されるまで実行します。ポリシーおよび終了コードによっては、Pod は終了後に削除されるか、コンテナーのログへのアクセスを有効にするために保持される可能性があります。

Red Hat Ansible Automation Platform は単純なデフォルトの Pod 仕様を提供しますが、デフォルトの Pod 仕様をオーバーライドするカスタム YAML または JSON ドキュメントを提供できます。このカスタムドキュメントは、有効な Pod JSON または YAML としてシリアル化できる ImagePullSecrets などのカスタムフィールドを使用します。

オプションの全リストは、OpenShift Online の ドキュメントに記載されています。

長時間稼働するサービスを提供する Pod の例

この例は、数多くの Pod 機能を示していますが、そのほとんどは他のトピックで説明されるため、ここでは簡単に説明します。

apiVersion: v1
kind: Pod
metadata:
  annotations: { ... }                      

  labels:
    deployment: docker-registry-1
    deploymentconfig: docker-registry
    docker-registry: default
  generateName: docker-registry-1-          

spec:
  containers:                               

  - env:         	            	  

    - name: OPENSHIFT_CA_DATA
      value: ...
    - name: OPENSHIFT_CERT_DATA
      value: ...
    - name: OPENSHIFT_INSECURE
      value: "false"
    - name: OPENSHIFT_KEY_DATA
      value: ...
    - name: OPENSHIFT_MASTER
      value: https://master.example.com:8443
    image: openshift/origin-docker-registry:v0.6.2 

    imagePullPolicy: IfNotPresent
    name: registry
    ports:   		                          

    - containerPort: 5000
      protocol: TCP
    resources: {}                                    

    securityContext: { ... }    		 

    volumeMounts:                       	   

    - mountPath: /registry
      name: registry-storage
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-br6yz
      readOnly: true
  dnsPolicy: ClusterFirst
  imagePullSecrets:                                  

  - name: default-dockercfg-at06w
  restartPolicy: Always  			     

  serviceAccount: default			    

  volumes:        	                            

  - emptyDir: {}
    name: registry-storage
  - name: default-token-br6yz
    secret:
      secretName: default-token-br6yz

Automation Controller を使用し、Automation Controller UI で Pod 仕様を編集し、Kubernetes ベースのクラスターでジョブを実行するために使用される Pod を変更できます。ジョブを実行する Pod の作成に使用される Pod 仕様は YAML 形式です。Pod 仕様の編集の詳細は、Pod 仕様のカスタマイズ を参照してください。

次の手順で Pod をカスタマイズできます。

コンテナーグループが、認証情報を必要とするセキュアなレジストリーのコンテナーを使用する場合は、コンテナーレジストリーの認証情報を、ジョブテンプレートに割り当てられている実行環境に関連付けることができます。

Automation Controller はこれを使用して、コンテナーグループジョブが実行される OpenShift Container Platform の名前空間に ImagePullSecret を作成し、ジョブの完了後にクリーンアップします。

または、ImagePullSecret がコンテナーグループの名前空間にすでに存在する場合は、ContainerGroup のカスタム pod 仕様で ImagePullSecret を 指定できます。

コンテナーグループで実行しているジョブで使用されるイメージは、必ずそのジョブに関連付けられている実行環境によってオーバーライドされることに注意してください。

事前に作成された ImagePullSecret の使用 (上級者向け) このワークフローを使用して ImagePullSecret を事前に作成する場合は、以前にセキュアなコンテナーレジストリーにアクセスしたことのあるシステムのローカル .dockercfg ファイルから、作成に必要な情報を取得できます。

.dockercfg file ファイル (新しい Docker クライアントの場合は $HOME/.docker/config.json) は、ユーザーの情報を保管する Docker 認証情報ファイルです (以前にセキュアな/セキュアではないレジストリーにログインしている場合)。

Pod を指定すると、コンテナーが必要とする各リソースの量を指定できます。指定する最も一般的なリソースは、CPU とメモリー (RAM) です。

Pod 内のコンテナーのリソース要求を指定すると、kubernetes-scheduler がこの情報を使用して、Pod を配置するノードを割り当てます。

コンテナーのリソース制限を指定すると、kubelet またはノードエージェントがその制限を適用し、実行中のコンテナーが設定した制限を超えてそのリソースを使用することを許可しないようにします。また、kubelet は、少なくとも要求された量のシステムリソースを、そのコンテナーが使用するために予約します。

spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory

128974848, 129e6, 129M,  128974848000m, 123Mi

spec:
  task_resource_requirements:
    requests:
      cpu: 100m
      memory: 250Mi
    limits:
      cpu: 2000m
      memory: 2Gi

タスクコンテナーの CPU とメモリーのリソース制限値を設定する必要があります。実行ノードで実行されるジョブごとに、そのジョブのコールバックイベントをスケジュール、起動、および受信する処理をコントロールプレーンで行う必要があります。

Automation Controller の Operator デプロイメントの場合、このコントロールプレーンの使用容量は、controlplane インスタンスグループで追跡されます。使用可能な容量は、Automation Controller 作成時に Automation Controller の仕様または OpenShift UI の task_resource_requirements フィールドで、ユーザーがタスクコンテナーに対して設定した制限に基づき決定されます。

クラスターに適したメモリーと CPU リソースの制限も設定できます。

タスクと Web コンテナーで、リソース要求の下限 (要求) と上限 (制限) の両方を設定できます。実行環境のコントロールプレーンは、プロジェクトの更新に使用されますが、通常はジョブのデフォルトの実行環境と同じです。

リソース要求と制限を設定することはベストプラクティスです。なぜなら、両方が定義されているコンテナーは、より高い サービス品質 クラスが与えられるからです。これは、基盤となるノードにリソース制限があり、クラスターが実行中のメモリーやその他の障害を防ぐために Pod をリープする必要がある場合は、コントロールプレーン Pod がリープされる可能性が低いことを意味します。

これらの要求と制限は、Automation Controllerの コントロール Pod に適用され、制限が設定されている場合は、インスタンスの 容量 が決定されます。デフォルトでは、ジョブの制御には 1 単位の容量が必要です。タスクコンテナーのメモリーと CPU の制限は、コントロールノードの容量を決定するために使用されます。この計算方法の詳細は、Automation Controller のキャパシティ決定とジョブへの影響 を参照してください。

ワーカーノードにスケジュールされるジョブ も参照してください。

コントロールノードを複数の Kubernetes ワーカーノードに最大限分散させるために、topology_spread_constraints の使用が推奨されます。要求と制限の適切なセットは、その合計がノード上の実際のリソースと等しくなる制限です。制限値 のみが設定されている場合、リクエストは自動的に制限値と等しくなるように設定されます。しかし、制御 Pod 内のコンテナー間でリソース使用量に多少のばらつきが許容されるため、リクエスト 量をより少なく設定できます。たとえば、ノードで使用可能なリソースの 25% に設定することが可能です。クラスターに 4 つの CPU と 16GB の RAM が割り当てられたワーカーノードのコンテナーのカスタマイズ例は、以下のとおりです。

spec:
  ...
  web_resource_requirements:
    requests:
      cpu: 250m
      memory: 1Gi
    limits:
      cpu: 1000m
      memory: 4Gi
  task_resource_requirements:
    requests:
      cpu: 250m
      memory: 1Gi
    limits:
      cpu: 2000m
      memory: 4Gi
  redis_resource_requirements
    requests:
      cpu: 250m
      memory: 1Gi
    limits:
      cpu: 1000m
      memory: 4Gi
  ee_resource_requirements:
    requests:
      cpu: 250m
      memory: 1Gi
    limits:
      cpu: 1000m
      memory: 4Gi

OpenShift のコントロールノードの容量は、メモリーと CPU の制限によって決まります。ただし、これらが設定されていない場合、容量は、ファイルシステム上の Pod によって検出されたメモリーと CPU (実際には、基盤となる Kubernetes ノードの CPU とメモリー) によって決まります。

これにより、そのノードに Automation Controller Pod 以外の Pod もある場合に、基盤となる Kubernetes Pod が過負荷になるという問題が発生する可能性があります。タスクコンテナーに直接制限を設定したくない場合は、extra_settings を使用できます。以下の設定方法については、カスタム pod タイムアウト セクションの 追加設定を 参照してください。

SYSTEM_TASK_ABS_MEM = 3gi
SYSTEM_TASK_ABS_CPU = 750m

これはアプリケーション内のソフトリミットとして機能し、Automation Controller が実行しようとする作業量の制御を可能にします。これにより、Kubernetes 自体による CPU スロットリングのリスクや、メモリー使用量が必要な制限を超えた場合に Pod が強制終了されるリスクを回避します。これらの設定は、Kubernetes リソース定義のリソース要求と制限で許可されるのと同じ形式を受け入れます。

Operator が作成した Automation Controller Pod を、特定のサブセットのノードで実行するように制限できます。

以下の表は、YAML の Automation Controller の仕様セクションで (または OpenShift UI フォームを使用して) 設定できる設定とフィールドを示しています。

topology_spread_constraints は、ノードセレクターに一致するコンピュートノード全体にコントロールプレーン Pod を分散するのに役立ちます。たとえば、このオプションの maxSkew パラメーターを 100 に設定すると、使用可能なノード全体に最大限分散することを意味します。したがって、一致するコンピュートノードが 3 つと Pod が 3 つある場合、各コンピュートノードに 1 つの Pod が割り当てられます。このパラメーターは、コントロールプレーン Pod が互いにリソースをめぐって競合するのを防ぐのに役立ちます。

コントローラー Pod を特定のノードに制限するカスタム設定の例

spec:
  ...
  node_selector: |
    disktype: ssd
    kubernetes.io/arch: amd64
    kubernetes.io/os: linux
  topology_spread_constraints: |
    - maxSkew: 100
      topologyKey: "topology.kubernetes.io/zone"
      whenUnsatisfiable: "ScheduleAnyway"
      labelSelector:
        matchLabels:
          app.kubernetes.io/name: "<resourcename>"
  tolerations: |
    - key: "dedicated"
      operator: "Equal"
      value: "AutomationController"
      effect: "NoSchedule"
  postgres_selector: |
    disktype: ssd
    kubernetes.io/arch: amd64
    kubernetes.io/os: linux
  postgres_tolerations: |
    - key: "dedicated"
      operator: "Equal"
      value: "AutomationController"
      effect: "NoSchedule"

コンテナーグループ Pod の仕様にノードセレクターを追加して、それらが特定ノードに対してのみ実行されるようにできます。最初に、ジョブを実行するノードにラベルを追加します。

次の手順では、ラベルをノードに追加します。

extra_settings を 使用すると、awx オペレーターを使用して多くのカスタム設定を渡すことができます。パラメーター extra_settings は /etc/tower/settings.py に追加され、extra_volumes パラメーターの代わりに使用できます。

extra_settings パラメーターの設定例

 spec:
    extra_settings:
      - setting: MAX_PAGE_SIZE
        value: "500"

      - setting: AUTH_LDAP_BIND_DN
        value: "cn=admin,dc=example,dc=com"

      - setting: SYSTEM_TASK_ABS_MEM
        value: "500"

カスタム Pod のタイムアウト

Automation Controller のコンテナーグループジョブは、Pod を Kubernetes API に送信する直前に running 状態に移行します。その後、Automation Controller は、AWX_CONTAINER_GROUP_POD_PENDING_TIMEOUT 秒が経過する前に Pod が Running 状態になると想定します。Automation Controller が 実行 状態に移行できなかったジョブをキャンセルするまでの待機時間を長くしたい場合は、AWX_CONTAINER_GROUP_POD_PENDING_TIMEOUT を より大きな値に設定できます。AWX_CONTAINER_GROUP_POD_PENDING_TIMEOUT は、Automation Controller が Pod の作成から Pod での Ansible 作業の開始まで待機する時間です。リソース制約のために Pod をスケジュールできない場合は、時間を延長することもできます。これは、Automation Controller 仕様で extra_settings を使用して行うことができます。デフォルト値は 2 時間です。

これは、Kubernetes がスケジュールできるよりも多くのジョブを常に起動しており、ジョブが AWX_CONTAINER_GROUP_POD_PENDING_TIMEOUT よりも長い期間を 保留 の状態にある場合に使用されます。

制御容量が使用可能になるまで、ジョブは開始しません。コンテナーグループの実行容量よりも多くのジョブが起動している場合は、Kubernetes ワーカーノードのスケールアップを検討してください。

Automation Controller と Kubernetes の両方が、ジョブのスケジューリングを行います。

ジョブが起動すると、その依存関係が満たされます。つまり、ジョブテンプレート、プロジェクト、およびインベントリー設定の要求に従って、プロジェクトの更新またはインベントリーの更新が Automation Controller によって開始されます。

ジョブが Automation Controller の他のビジネスロジックによってブロックされておらず、コントロールプレーンにジョブを開始するためのコントロールプレーンがある場合、ジョブはディスパッチャーに送信されます。ジョブを制御するためのコストのデフォルト設定は 1 capacity です。したがって、100 capacity のコントロール Pod は、一度に最大 100 のジョブを制御できます。制御容量が負荷されたジョブは、pending から waiting に移行します。

コントロールプラン Pod のバックグラウンドプロセスであるディスパッチャーは、ワーカープロセスを開始してジョブを実行します。これは、コンテナーグループに関連付けられたサービスアカウントを使用して kubernetes API と通信し、Automation Controller のコンテナーグループで定義されている Pod 仕様を使用して Pod をプロビジョニングします。Automation Controllerのジョブステータスは running と表示されます。

これで Kubernetes が Pod をスケジュールするようになりました。Pod は AWX_CONTAINER_GROUP_POD_PENDING_TIMEOUT の間、pending ステータスのままになります。Pod が ResourceQuota によって拒否された場合、ジョブは pending からやり直されます。名前空間でリソースクォータを設定して、名前空間内の Pod が消費できるリソースの数を制限できます。ResourceQuotas の詳細は、リソースクォータ を参照してください。

アップグレード中のダウンタイムを最小限に抑えるために、Automation Controller で次の設定変更を行ってください。

Ansible Automation Platform Operator 内の Receptor ワーカーは、環境変数 RECEPTOR_KUBE_RETRY_COUNT を使用して設定します。この変数は、ワーカーが Kubernetes API 接続の失敗をどのように処理するかを制御します。

RECEPTOR_KUBE_RETRY_COUNT の詳細

設定に関する推奨事項

Playbook の実行時間が 20 時間を超える場合、または 2-4 時間以上出力がない場合は、RECEPTOR_KUBE_RETRY_COUNT を デフォルト値から増やしてください。20 時間かかる作業の場合、再試行回数は 10 回を推奨します。この設定では、各再試行に約 2 時間の猶予が設けられており、長時間実行される処理中にワーカーが早期にタイムアウトするのを防ぎます。