Operator ベースのインストールにおける Red Hat Ansible Automation Platform のパフォーマンスに関する考慮事項

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

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

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

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

オプションの完全なリストは、Openshift のドキュメント にあります。

apiVersion: v1
kind: Pod
metadata:
  annotations: { ... }                      1
  labels:
    deployment: docker-registry-1
    deploymentconfig: docker-registry
    docker-registry: default
  generateName: docker-registry-1-          2
spec:
  containers:                               3
  - env:         	            	  4
    - 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 5
    imagePullPolicy: IfNotPresent
    name: registry
    ports:   		                          6
    - containerPort: 5000
      protocol: TCP
    resources: {}                                    7
    securityContext: { ... }    		 8
    volumeMounts:                       	   9
    - mountPath: /registry
      name: registry-storage
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-br6yz
      readOnly: true
  dnsPolicy: ClusterFirst
  imagePullSecrets:                                  10
  - name: default-dockercfg-at06w
  restartPolicy: Always  			     11
  serviceAccount: default			    12
  volumes:        	                            13
  - emptyDir: {}
    name: registry-storage
  - name: default-token-br6yz
    secret:
      secretName: default-token-br6yz

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

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

Pod 内のコンテナーのリソース要求を指定すると、kubenetes-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 コンテナーで、リソース要求の下限 (要求) と上限 (制限) の両方を設定できます。実行環境のコントロールプレーンは、プロジェクトの更新に使用されますが、通常はジョブのデフォルトの実行環境と同じです。

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

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

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

topology_spread_constraints を使用して制御ノードを個別の基盤となる kubernetes ワーカーノードにできるだけ分散することも推奨されるため、ノード上の実際のリソースと合計量と同じ量が、要求と制限の上限として妥当です。制限 のみが設定されている場合は、リクエストが制限と等しくなるように自動的に設定されます。ただし、コントロール Pod 内のコンテナー間でリソース使用量の変動が許容されるため、requests をより低い量 (ノードで使用可能なリソースの 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 を使用できます。次の設定方法は、Custom pod timeouts セクションの Extra Settings を参照してください。

SYSTEM_TASK_ABS_MEM = 3gi
SYSTEM_TASK_ABS_CPU = 750m

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

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

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

topology_spread_constraints は、ノードセレクターに一致するコンピュートノード全体にコントロールプレーン Pod を分散するのに役立ちます。たとえば、このオプションの maxSkew パラメーターを 100 に設定すると、使用可能なノード全体に最大限分散することを意味します。したがって、一致する 3 つのコンピュートノードと 3 つの Pod がある場合は、各コンピュートノードに 1 つの 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 の仕様にノードセレクターを追加して、それらが特定ノードに対してのみ実行されるようにできます。最初に、ジョブを実行するノードにラベルを追加します。

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

apiVersion: v1
kind: Pod
metadata:
  disktype: ssd
  namespace: ansible-automation-platform
spec:
  serviceAccountName: default
  automountServiceAccountToken: false
  nodeSelector:
    aap_node_type: execution
  containers:
    - image: >-
     registry.redhat.io/ansible-automation-platform-22/ee-supported-rhel8@sha256:d134e198b179d1b21d3f067d745dd1a8e28167235c312cdc233860410ea3ec3e
      name: worker
      args:
        - ansible-runner
        - worker
        - '--private-data-dir=/runner'
      resources:
        requests:
          cpu: 250m
          memory: 100Mi

 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"

Automation Controller のコンテナーグループジョブは、Pod を Kubernetes API に送信する直前に running 状態に移行します。その後、Automation Controller は、AWX_CONTAINER_GROUP_POD_PENDING_TIMEOUT 秒が経過する前に Pod が Running 状態になると想定します。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 よりも長い期間を pending の状態にある場合に使用されます。

制御容量が使用可能になるまで、ジョブは開始しません。コンテナーグループの実行容量よりも多くのジョブが起動している場合は、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 で次の設定変更を行ってください。