#################### BASIC-DEPLOYMENT #################### Kubernetes Deployment_ を利用した コンテナイメージのオーケストレーション機能を提供します。 通常 kubernetes ネイティブリソースである Deployment だけではアプリケーションを外部に公開出来ませんが、 本パッケージではネイティブリソースである Deploymentを拡張しており、外部公開に必要となる基本的なオプション （ネットワーク設定、データベースへの接続設定、暗号化キーストレージからシークレットの取得、ボリュームのマウントなど） を一括で設定可能としています。 +-------+------------------+ | | 設定値 | +=======+==================+ | Chart | basic-deployment | +-------+------------------+ 対応サービス ============== パッケージの機能 ================ 本パッケージでは、 Deployment_ の全ての機能に加えて以下の簡易設定機能及び、依存関係にある追加リソースの自動作成を行います。 * デプロイ戦略による自動デリバリ機能の提供 * 以下の２種類のデプロイ戦略による自動デリバリの機能を提供します。 * Blue Green Deployment * Canary Deployment * サービスの公開範囲の設定機能 * アプリケーションの外部公開・内部公開・非公開 の設定を自動化します。 * 外部公開する際のルーティング設定、マネージドDNSサービスへのレコード登録、TLSキーの発行処理を自動化します。 * ルーティング設定 * パスルーティング・外部サービスへのルーティングに対応します。 * ConfigMap/Secretリソースに関する設定 * 各クラウドの Key Management System (KMS) からの Secretリソース を作成します。 * ConfigMap/Secretリソースの環境変数への設定、もしくは任意のパスへマウントを簡易化した形で設定できます。 * 共有マウント設定 * 事前設定コンテナとメインコンテナで共有フォルダを自動的に作成して連携します。 * プライベートなコンテナレジストリへのアクセス設定機能 * プライベートなコンテナレジストリへのアクセス設定機能 Image Pull Secret の設定を行います。 * アプリケーションで利用するコンテナイメージの自動更新 * 設定した更新ポリシーに従って、アプリケーションで利用するコンテナイメージの自動更新を行います。 * アカウント作成とロール設定 * Kubernetes内のアカウントとクラウドサービスのIAMのロール・ポリシー設定との紐づけを自動的に行います。 * データベースアクセスの事前準備設定 * 疎通確認および必要な権限付与を自動的に行います。 * オートスケール * コンテナに割り合てる、CPU とメモリの設定および起動するPod数の自動スケール設定を行います。 * Prometheusメトリクスの開示 * クラスタ内のPrometheusに対して、CPU、メモリなどの基礎的なメトリクス およびアプリケーションが独自に開示したメトリクスを自動収集する設定を行います。 上記に記載した設定以外の Deployment_ リソースの設定も可能です。詳細は values.yaml に記載例をご参照ください。 以下の章では、本パッケージでサポートしている機能のそれぞれの設定方法について説明します。 デプロイ戦略による自動デリバリ機能の提供 ----------------------------------------------- 旧環境と新環境が同時に存在する環境を構築し、ルーティングの制御によってトラフィックを切り替え、ダウンタイム無しで環境を切り替えることが可能です。 Blue Green Deployment ~~~~~~~~~~~~~~~~~~~~~ ``progressiveDelivery.enabled`` を ``true`` にして ``progressiveDelivery.strategy`` に ``blueGreen`` を指定することで、更新予定ワークロードに対して、 疎通確認とリクエストの正常確認を10分間行い、成功した場合にトラフィックの切り替えを行います。 失敗した場合、トラフィックの切り替えは行われません。 実行するためには最低限疎通確認用のパス( ``progressiveDelivery.endpoints.accessTests`` ) もしくは負荷テスト用のパス ( ``progressiveDelivery.endpoints.loadTests`` )の いずれかを設定する必要があります。 Canary Deployment ~~~~~~~~~~~~~~~~~ ``progressiveDelivery.enabled`` を ``true`` にして ``progressiveDelivery.strategy`` に ``canary`` を指定することで、更新予定ワークロードに対して、徐々にトラフィックを切り変えていくことができます。 設定条件は blueGreen と同じですが、デフォルト設定では最大 50% のトラフィックが新たなワークロードに振り向けられます。 .. _deployment-mount: ネットワーク設定 ---------------- 設定された値に基づいて、アプリケーションのネットワークアクセスについて、 スタンドアロン(非公開)・クラスタネットワーク(内部公開)・インターネットアクセス(外部公開) の設定を自動化します。 ネットワークアクセスのコントロールに対応して、 Service や その他必要なリソースを自動的に作成します。 Service 名は ``-basic-deployment`` になります。 .. WARNING:: Port 設定を変更した場合、 ``livenessProbe`` ``readinessProbe`` の設定をそれに合わせて変更します。 非公開(スタンドアロン) ~~~~~~~~~~~~~~~~~~~~~~ 作成された Pod に対してクラスタ内外問わず、一切の外部からの接続を受けつけない設定パターン。 .. code-block:: yaml network: gatewayName: "" ``network.gatewayName`` に空文字を設定することで、 Gateway を利用した外部からのルーティングが行なわれなくなります。 さらに、 service の設定も行わないことで Pod にアクセスするための Service が作成されなくなり、クラスタ内でのアクセスも受け付けなくなります。 .. _vs-cluster: クラスタネットワーク(内部公開) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ クラスタ内ネットワークからの http アクセスのみ受けつけるパターン。 .. code-block:: yaml network: gatewayName: "" service: ports: - name: http containerPort: 8080 servicePort: 80 ``network.gatewayName`` に空文字を設定することで、 Gateway を利用した外部からのルーティングが行なわれなくなります。 ``network.service.ports`` の設定で service ``-basic-deployment.svc.cluster.local`` の 80 番ポートで受け付けたリクエストを Pod の 8080 番ポートに転送します。 インターネットアクセス(外部公開) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ クラスタ内及びインターネットからの http アクセスを受け付けるパターン。 .. code-block:: yaml network: domain: example.com service: ports: - name: http containerPort: 8080 servicePort: 80 ``network.domain`` に値を設定することで、指定したドメインへのリクエストを Service に転送します。 Service に転送されたリクエストは前述のクラスタネットワークと同じように処理されます。 上記の設定を行うことで、内部的に以下の機能を利用して、外部公開の設定がなされます。 * Virtual Serviceに設定されたFQDNを自動取得しDNSレコードをマネージドDNSサービスへの登録します。 * Cert Managerを経由してTLSのキーを発行します。 上記の設定では、 ``network.domain`` 宛のリクエストとデフォルト Service ( ``-basic-deployment.svc.cluster.local`` ) 宛のリクエストが デフォルト Service に転送されます。 IPアドレスを直接指定したアクセスを受け付ける場合 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ IPアドレスを直接指定したリクエストをルーティングしたい特殊なケースでは、 ``network.domain`` に ``"'*'`` または ``'"*"'`` を指定した上で、 ``network.gatewayName`` に 独自に作成した gateway を指定し、 gateway にてルーティングを制御する。 .. WARNING:: ``network.domain`` に ``"'*'`` または ``'"*"'`` を指定した場合、 他の Deployment アプリケーションでの ``network.domain`` 設定によるルーティングが無効になります。 ルーティング設定 ---------------- http によるアクセスに関しては、``routes`` を定義することによってルーティング設定を行なうことができます。 ``network.routes`` はリスト形式のため、複数のルーティングパターンを登録することができます。 ``network.routes`` を設定していない場合は、Service に宛てた全てのリクエストがデフォルトの Service に転送されます。 パスによるルーティング ~~~~~~~~~~~~~~~~~~~~~~ 特定のパスに対するリクエストのみを受けつけたい場合は、以下のように ``match`` を指定します。 .. code-block:: yaml network: routes: - match: - uri: prefix: /apiv1 - uri: prefix: /apiv1beta1 rewrite: uri: / この場合、 path の prefix に ``/apiv1`` と ``/apiv1beta1`` が設定されたリクエストのみデフォルトの Service に転送します。 ``rewrite`` を設定することで転送する際に、 prefix で指定した path を ``/`` に書き変えています。 そのまま転送したい場合には、rewrite の設定は不要です。 Header 等の他の条件によるルーティングを行いたい場合は、 HTTPMatchRequest_ を参照して match 条件を設定します。 外部サービスへの転送 ~~~~~~~~~~~~~~~~~~~~ デフォルトの Service ではなく他の Service にリクエストを転送したい場合は、 ``network.routes[].services`` で転送先の Service を指定します。 .. code-block:: yaml network: routes: - services: - name: other-service match: - uri: prefix: /apiv1 - uri: prefix: /apiv1beta1 rewrite: uri: / この場合、 ``/apiv1`` と ``/apiv1beta1`` prefix を持つリクエストは、 Service ``other-service.svc.cluster.local`` に転送されます。 転送先の Service は :ref:`vs-cluster` の設定をしておきます。 .. _deploy-init: ConfigMap/Secretの自動マウント ------------------------------ * Key Management System (KMS) からの Secretリソース を作成します * ConfigMap/Secretリソースの環境変数への設定、もしくは任意のパスへマウントします なお、External Secret Operator(ESO) がデフォルトで有効となっているため、Secretリソースの作成は自動で行うことが可能です。 （ExternalSecretOperator: Key Management System (KMS)を参照し、Secretリソースを自動で作成する機能） 以下はConfigMapをマウントする例です。 既存の ConfigMap である env-config 内の samplekey という key に対応する値が コンテナ の /var/www2/samplekey というパスにマウントされ、環境変数 ENV_CONFIGMAP にも設定されます。 また、マウント時のアクセス権限の設定も実施できます。デフォルトのアクセス権限は 0644 になります。 .. code-block:: yaml mountConfigmaps: - name: env-config key: samplekey mountPath: /var/www2 mode: "0755" env: ENV_CONFIGMAP 以下は、Kubernetes Secret リソースをマウントする例です。 既存の Kubernetes Secrets である secret-env 内の test という key に対応する値が、 コンテナ の /var/www2/test というパスにマウントされ、環境変数 ENV_SECRET にも設定されます。 また、マウント時のアクセス権限の設定も実施できます。デフォルトのアクセス権限は 0644 になります。 .. code-block:: yaml mountSecrets: - secretRef: name: secret-env key: test mountPath: /var/www2 mode: "0755" env: ENV_SECRET 以下は、KMS に設定された値をマウントする例です。 KMS にて test2 という key で登録された値が、 コンテナ の /var/www2/test2 というパスにマウントされ、環境変数 ENV_KMS_SECRET にも設定されます。 また、マウント時のアクセス権限の設定も実施できます。デフォルトのアクセス権限は 0644 になります。 .. code-block:: yaml mountSecrets: - remoteRef: key: test2 # property: testkey # AWSではキー名の他にプロパティの指定が必要 mountPath: /var/www2 mode: "0600" env: ENV_KMS_SECRET SecretStore ~~~~~~~~~~~ 本パッケージは ESO の SecretStore 及び ClusterSecretStore を経由して KMS からシークレット情報を取得します。 CNAP クラスタでは ``default`` ClusterSecretStore がクラスタ作成時に登録されます。 values の ``secretStore`` にはデフォルトでこれが設定されているため、すぐにシークレットを使用することができます。 アプリケーション専用の SecretStore や ClusterSecretStore を作成したい場合は、VAULT パッケージを使用することで、 簡単に一連の設定を行なうことができます。 共有マウント ------------ ``sharedMounts`` を設定することで、 :ref:`deploy-init` で実行する全てのコンテナとメインのコンテナに共有のフォルダを 設定することができます。 これによって、事前処理で作成したデータをメインコンテナに引き継ぐことができます。 .. _deploy-pullsecret: プライベートなコンテナレジストリへのアクセス設定機能 --------------------------------------------------------------------- 認証のかかったプライベート Docker リポジトリから Docker イメージを取得する場合は、imagePullSecret を利用します。 利用にあたっては、Docker レジストリの認証情報を事前に KMS に登録しておき、 values の ``image.pullSecrets.[]`` に利用する imagePullSecret の設定を列挙します。 これによって、自動的にクラスタ上に secret が作成され、Pod が参照するように設定されます。 なお、 ``image.pullSecrets.[].passwordSecret`` の値は作成される Kubernetes リソースの名前に付与されるため、 英小文字で始まり、英小文字・ハイフン・ピリオドのみを含むように設定してください。 .. IMPORTANT:: EKS では同一アカウント GKE では同一プロジェクト内に作成されたプライベートコンテナレジストリに対するアクセス権は 自動的に付与されるため imagePullSecret の設定を行う必要はありません。 .. _deployment-image-update-automation: アプリケーションで利用するコンテナイメージの自動更新 --------------------------------------------------------------------- アプリケーションで利用するコンテナイメージのタグを自動的に更新することが可能です。 前提条件 ~~~~~~~~~ 本機能を使用するためには、Deploykeyをリポジトリに追加するときに書き込みアクセス権を付与しておく必要があります。 GitHubでDeploykeyに書き込みアクセス権が設定されているかどうかを確認するためには、該当のリポジトリより、 Settings -> Deploy keys を押下し、以下の図の赤枠のように「Read/write」となっていれば問題ありません。 .. image:: /_static/images/packages/deployment-github-deploykey.png 「Read-only」となっていた場合、deploykeyを一度削除し、再登録する必要があります。 deploykeyが削除されると一時的にGitRepositoryとの連携が切断されますが、アプリケーションへの影響はありません。 deploykeyの登録方法は、チュートリアルのDeploykeyの登録の章 を参照してください。 利用方法 ~~~~~~~~~ 利用にあたっては、 ``image.autoUpdate`` に ユーザー設定用リポジトリ、イメージのリポジトリ、タグの更新ポリシーを設定した上で、 ``image.tag`` に ``{"$imagepolicy": "[metadata.namespaceの値]:[image.repositoryのイメージ名]-[metadata.nameの値]-application:tag"}`` という形式で自動更新のポリシーを指定するコメントを記載します。 この設定を行うことで、ユーザー設定用リポジトリ内の Application マニフェストが自動的に編集され、アプリケーションで利用されるイメージのタグを更新することが可能です。 ここで、[image.repositoryのイメージ名]に入力する値はイメージ名のみとすることに注意してください。 以下は、 ``metadata.name: customer-app`` , ``metadata.namespace: staging`` , ``image.repository: path/to/sample-img`` とした場合のコメントの記述例です。 .. code-block:: yaml image: tag: "1.0.0" # {"$imagepolicy": "staging:sample-img-customer-app-application:tag"} 環境ごとに違う自動更新のポリシーを適用する方法 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 各環境(開発・検証・本番)ごとに異なる自動更新のポリシーを、以下の設定を利用して適用することができます。 以下でいくつかの自動更新のポリシーの例を示します。 以下の例は開発環境向けのポリシーの一例になります。 メジャー・マイナー・パッチ・プレリリース全てのバージョンの最新のバージョンになるよう自動更新します。 .. code-block:: yaml image: autoUpdate: imagePolicy: policy: semver: range: x-alpha 以下の例は検証環境向けのポリシーの一例になります。 メジャー・マイナー・パッチの全てのバージョン、およびプレリリースバージョンのうちrcバージョンのみを対象として、最新のバージョンになるよう自動更新します。 .. code-block:: yaml image: autoUpdate: imagePolicy: policy: semver: range: x-alpha filter: inclusionPattern: '.*-rc.*' 以下の例は本番環境向けのポリシーの一例になります。 パッチバージョンに限定してバージョンを自動更新します。 メジャー・マイナーバージョンのアップデート時には、 `image.autoUpdate.imagePolicy.policy.semver` を 1.0.x から 1.1.x や 2.0.x に手動で更新します。 .. code-block:: yaml image: autoUpdate: imagePolicy: policy: semver: range: 1.0.x また、各環境ごとにパッチファイル等利用してマニフェストを分割して作成している場合、 更新対象となるマニフェストが配置されているパスを `image.autoUpdate.userRepository.path` にて指定します。 プライベートなコンテナレジストリを利用した自動更新 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ コンテナイメージの自動更新を行うためには、コンテナイメージをホストするコンテナレジストリへのアクセス権限の 設定を行う必要があります。 :ref:`deploy-pullsecret` を行っている場合、コンテナレジストリへのアクセスは、この imagePullSecret を利用して行なわれます。 imagePullSecret が設定されていない場合は、CNAP のデフォルト設定によるイメージバージョン更新情報の取得を試みます。 CNAP はデフォルトで以下のコンテナレジストリに対して、自動更新機能にリードオンリーのアクセス権を付与します。 * AWS: 同一アカウント内に作成されたコンテナレジストリ * Azure: 同一サブスクリプション内に作成されたコンテナレジストリ * Google: 同一プロジェクト内に作成されたコンテナレジストリ .. _deployment-role: アカウント作成とロール設定 -------------------------- 本パッケージをインストールすると、デフォルトでワークロードに割り当てられる専用のアカウントが発行されます。 このアカウントにクラウドサービスのロールを付与することで、コンテナ内のプロセスで個別の認証の手続を行うことなく、 任意のクラウドサービスにアクセスすることができるようになります。 * マネージドサービスアカウントの作成 * マネージドサービスアカウントに対するロールの付与 * コンテナからマネージドサービスアカウントに付与された権限を使用する設定 これらのリソースは Pod から利用することを想定して、作成したリソースを適切に適用できるように構成されます。 各ステップで使用するリソースは既存のものを利用、もしくは新規作成どちらも可能です。 .. IMPORTANT:: ``auth.serviceAccount.create`` が **false** の場合、アカウントは新規発行されず、指定された既存のアカウントを使用します。 既存のアカウントを指定した場合、設定の重複を避けるため本パッケージではロールの付与を行いません。 このため、既存のアカウントを利用する場合は個別にロール設定をする必要があります。 GCP ロール設定 ~~~~~~~~~~~~~~ ``auth.gcp.roles[].name`` に指定するロール名は `GCPロールのページ`_ から適切なロール(roles/XXXX)を探して適用します。 ストレージバケット等の特定のリソースにのみ権限を付与したい場合は ``auth.gcp.roles[].resourceRef`` に `ターゲットリソース`_ を指定します。 .. code-block:: yaml auth: gcp: roles: - name: roles/redis.editor - name: roles/storage.objectAdmin resourceRef: kind: StorageBucket external: example-storage-bucket Azure ロール設定 ~~~~~~~~~~~~~~~~ ``auth.azure.roles[].id`` に指定するロールidは `Azureロールのページ`_ から適切なロール **id** を探して適用します。 .. code-block:: yaml auth: azure: roles: - id: "17d1049b-9a84-46fb-8f53-869881c3d3ab" - id: "f25e0fa2-a7c8-4377-a976-54943a77a395" .. TIP:: コンテナでaz cli を使用する場合、以下のコマンドでAzureログインをしてください。 ``az login --federated-token "$(cat $AZURE_FEDERATED_TOKEN_FILE)" --service-principal -u $AZURE_CLIENT_ID -t $AZURE_TENANT_ID`` AWS ロール設定 ~~~~~~~~~~~~~~ * AWS 管理のポリシーを適用する場合 AWS 管理の IAM ポリシーを設定したい場合は ``auth.aws.awsManagedPolicies[]`` に対し、 ポリシー arn の ``arn:aws:iam::aws:policy/[NAME]`` NAME 部分を設定します。 .. code-block:: yaml auth: aws: awsManagedPolicies: - name: AmazonRDSReadOnlyAccess * 既存のカスタマー管理のポリシーを適用する場合 既存のカスタマー管理の IAM ポリシーを設定したい場合は、 ``auth.aws.customerManagedPolicy.name`` と ``auth.aws.awsManagedPolicies[].name`` に、 ポリシー arn の ``arn:aws:iam::111122223333:policy/[NAME]`` NAME 部分を設定します。 また、 ``auth.aws.awsManagedPolicies[].customerManaged`` に ``true`` を、 ``auth.aws.customerManagedPolicy.create`` に ``false`` を設定します。 .. code-block:: yaml auth: aws: awsManagedPolicies: - name: test-cs-policy-name customerManaged: true customerManagedPolicy: name: test-cs-policy-name create: false * 新規にカスタマー管理のポリシーを作成して適用する場合 新規にカスタマー管理のポリシーを作成して適用する場合も ``auth.aws.customerManagedPolicy.name`` と ``auth.aws.awsManagedPolicies[].name`` に、 ポリシー arn の ``arn:aws:iam::111122223333:policy/[NAME]`` NAME 部分を設定します。 また、 ``auth.aws.awsManagedPolicies[].customerManaged`` に ``true`` を、 ``auth.aws.customerManagedPolicy.create`` に ``true`` を設定してください。 これにより、 ``auth.aws.customerManagedPolicy.actions`` , ``auth.aws.customerManagedPolicy.resources`` に設定した値に基づいて新規に作成したポリシーが適用されます。 .. code-block:: yaml auth: aws: awsManagedPolicies: - name: test-cs-policy-name customerManaged: true customerManagedPolicy: name: test-cs-policy-name actions: - action: ec2:DescribeAddresses - action: ec2:DescribeAvailabilityZones resources: - resource: serviceName: eks resourceType: "*" Id: "*" create: true AWS IRSA と IAM ポリシーの詳細については、 `ロールとサービスアカウントの設定`_ を参照してください。 データベースアクセス -------------------- クラウドのマネージド RDBMS (PostgreSQL, MySQL) を利用する場合は ``preConnectRdb`` フィールドを設定することによって、 データベースとの接続に関する以下の設定を行うことができます。 * データベースへの疎通確認の実施 * (Google Cloudのみ) Cloud SQLで作成されたデータベースに対する、アクセス権限の設定 Google Cloudでは データベース利用時にロールの設定が必要ですが、 これによって適切なロールがワークロードに付与されるため、 rdb に関する :ref:`deployment-role` を行なう必要はありません。 設定されるのはマネージド RDBMS インスタンスへのアクセス設定のみのため、データベースアカウントによる、個々のデータベースへの接続はコンテナ内のアプリケーションで実装します。 アクセスに必要なパスワードなどの取得には :ref:`deployment-mount` の機能が利用できます。 Cloud SQL Auth Proxy ~~~~~~~~~~~~~~~~~~~~ GCP の Cloud SQL を利用する場合は、自動的に `Cloud SQL Auth Proxy`_ がサイドカーコンテナに設定されます。 Cloud SQL Auth Proxy を利用する場合はインスタンスのロケーションに関係なく、コンテナからは常に ``localhost`` を host に指定してアクセスします。 .. code-block:: yaml preConnectRdb: - gcp: instance: my-mysql-instance-1 port: 3306 - gcp: instance: my-postgres-instance-2 port: 5432 ポートは localhost にバインドされるため、重複しないように設定します。 事前処理用コンテナの登録 ------------------------ サービスを提供するコンテナとは異なるコンテナで事前処理を行いたい場合や、 同じコンテナであっても事前処理ではより強い権限のユーザーで処理を行い、 メインコンテナは必要最低限の権限で実行するといった要件がある場合 ``initContainers`` を使用できます。 initContainers にリストで登録したコンテナは昇順で実行され、全てのコンテナの実行が終わってから、メインのコンテナが実行されます。 .. code-block:: yaml initContainers: - name: waiting image: repository: waiting-dependency tag: latest - name: init image: repository: sdkimage tag: v1.0.0 workingDir: /app command: - sh - initapp sharedMounts: - /app/data - /app/cache 上記の例では ``sharedMounts`` の設定によって、 ``/app/data`` と ``/app/cache`` が各コンテナにマウントされます。 .. TIP:: データベースマイグレーションのような、フレームワークに組み込まれている処理は、サービス起動前に実行する必要がありますが、 同一コンテナ上で実行できるため、基本的には initContainers は利用せず、起動スクリプトに処理を組み込むように設計してください。 .. IMPORTANT:: GKE の場合 DB 接続はサイドカーコンテナの sql auth proxy を経由して行われます。 サイドカーコンテナは initContainers の終了後に起動するため、 GKE では initContainer 内で DB を必要とする処理を行うことはできません。 .. WARNING:: Pod の起動は initContainers の終了を待ちます。フォアグラウンドで終了しないコンテナを initContainers に登録すると Pod が起動しなくなります。 オートスケール -------------- ``scaling.scalingType`` を ``auto`` に設定し、 ``scaling.autoscaling`` の設定を行なうことで、コンテナに割り合てる、CPU とメモリの設定及び、 Pod の自動スケール設定を行います。 CPU 利用率によるスケール ~~~~~~~~~~~~~~~~~~~~~~~~ ``scaling.requests.cpu`` で指定した起動時に要求する CPU 値に対して ``scaling.autoscaling.targetAverageUtilization.cpu`` で指定した利用率を越えた場合スケールを行います。 CPU 要求はクラスタを構成する vcpu から1つを要求する場合、1000m を指定します。 メモリ利用率によるスケール ~~~~~~~~~~~~~~~~~~~~~~~~~~ ``scaling.requests.request`` で指定した起動時に要求するメモリ値に対して ``scaling.autoscaling.targetAverageUtilization.memory`` で指定した利用率を越えた場合スケールを行います。 メモリ要求はクラスタを構成するメモリから、 Gi, Mi, Ki のような単位で指定します。 .. IMPORTANT:: request 利用率のいずれかが指定されていない場合、オートスケールは実行されません。 利用率以外でのスケールを行いたい場合は、 Kubernetes の `ドキュメント`_ を参照し、 直接 ``HorizontalPodAutoscaler`` を作成してください。 Prometheusメトリクス -------------------- 本パッケージでは CNAP の作成したマネージド Prometheus ワークスペースにメトリクスの 収集を行うための設定を行うことができます。 本パッケージを利用すると、デフォルトでコンテナの基本的なメトリクス(CPU、メモリ、ディスクIO、ネットワークIO)がPrometheusへ収集されます。 収集されるメトリクスの詳細については、 `cAdvisor Prometheus container metrics`_ を参照ください。 CNAP が cAdvisor から収集するメトリクスはコストを抑えるため厳選されたメトリクスのみ収集します。 .. table:: CNAP の取得するメトリクス +---------------------------------------------+----------------------------------------+ | メトリクス | 概要 | +=============================================+========================================+ | container_cpu_usage_seconds_total | コンテナの cpu 使用時間 | +---------------------------------------------+----------------------------------------+ | container_memory_rss | コンテナの rss 使用量 | +---------------------------------------------+----------------------------------------+ | container_memory_usage_bytes | コンテナの現在のメモリ使用量 | +---------------------------------------------+----------------------------------------+ | container_cpu_load_average_10s | コンテナの過去10秒間のロードアベレージ | +---------------------------------------------+----------------------------------------+ | container_network_receive_bytes_total | コンテナの受信バイト合計 | +---------------------------------------------+----------------------------------------+ | kube_pod_status_ready | Pod の Ready 状態 | +---------------------------------------------+----------------------------------------+ | kube_pod_container_resource_requests | コンテナのリソース要求値 | +---------------------------------------------+----------------------------------------+ | kube_pod_container_resource_limits | コンテナのリソース制限値 | +---------------------------------------------+----------------------------------------+ | kube_pod_container_status_restarts_total | コンテナの再起動回数 | +---------------------------------------------+----------------------------------------+ | kube_pod_status_reason | Pod の理由 | +---------------------------------------------+----------------------------------------+ | kube_pod_status_phase | Pod の実行フェイズ | +---------------------------------------------+----------------------------------------+ | kube_pod_container_status_terminated | コンテナの終了ステータス | +---------------------------------------------+----------------------------------------+ | kube_pod_container_status_terminated_reason | コンテナの終了理由 | +---------------------------------------------+----------------------------------------+ | kube_pod_owner | Pod のコントローラー情報 | +---------------------------------------------+----------------------------------------+ | kube_pod_info | Pod の情報 | +---------------------------------------------+----------------------------------------+ | kube_deployment_status_condition | Deployment の状態 | +---------------------------------------------+----------------------------------------+ | kube_job_status_failed | Job の失敗 | +---------------------------------------------+----------------------------------------+ | kube_statefulset_replicas_status_ready | Statefulset の Ready 状態 | +---------------------------------------------+----------------------------------------+ | kube_daemonset_status_number_unavailable | 実行できていない Daemonset の数 | +---------------------------------------------+----------------------------------------+ | kube_[xxx]_labels | リソースのラベル | +---------------------------------------------+----------------------------------------+ また、アプリケーションが開示した独自のメトリクスをPrometheusへ収集させることも可能です。 Pod から直接メトリクスを収集する場合は、 ``PodMonitor`` 。Service を経由してメトリクスを収集する場合には ``ServiceMonitor`` を利用します。 コンテナがメトリクスを開示するエクスポーターの利用するポートと、指定がある場合はエンドポイントパスを PodMonitor を利用する場合は ``monitoring.prometheus.podMonitor.podMetricsEndpoint`` ServiceMonitor を利用する場合は ``monitoring.prometheus.serviceMonitor.endpoints`` に設定します。 * `PodMonitor podMetricsEndpoint`_ のドキュメント * `ServiceMonitor endpoints`_ のドキュメント なお、アプリケーションでのPrometheusメトリクスの開示方法については、 `Prometheus Client Libraries`_ を参照ください。 Prometheusへのメトリクス収集を無効化したい場合は、 ``monitoring.prometheus.enabled`` を ``false`` に設定します。 マイグレーション ================ 1.3.0 ----- 1.3.0 以前のバージョンから 1.3.0 以降のバージョンにアップデートすると、 デフォルトで podMonitor の設定は行われなくなります。 これによって Pod のコンピュートリソースのメトリクスが取得されなくなることはありませんが、 コンテナに独自のエクスポーターを組み込んでデフォルト設定を行っている場合は、 Application マニフェストに以下の設定を追加する必要があります。 .. code-block:: yaml monitoring: prometheus: podMonitor: podMetricsEndpoints: - path: /metrics port: http # network.service.ports.name で指定した値と同じ値を設定 Values ====== Default values -------------- .. literalinclude:: values/basic-deployment.values.yaml :language: yaml Schema reference ---------------- .. jsonschema:: schema/basic-deployment.schema.json Example ======= Example1. Kanboard作成 ---------------------- .. literalinclude:: example/basic-deployment/example1_kanboard.yaml :language: yaml Example2. Blue-Green Deployment ------------------------------- .. literalinclude:: example//basic-deployment/example2_BueGreen_deployment.yaml :language: yaml Change Log ========== .. changelog:: :changelog-url: https://msp-project-gcp.an.r.appspot.com/managed/basic-deployment.html :github: https://github.com/sbopsv/MASTER-CONTAINER-HELM-DEPLOYMENT/releases/ .. _MASTER-CONTAINER-HELM-DEPLOYMENT: https://github.com/sbopsv/MASTER-CONTAINER-HELM-DEPLOYMENT .. _Deployment: https://kubernetes.io/ja/docs/concepts/workloads/controllers/deployment/ .. _Cloud SQL Auth Proxy: https://cloud.google.com/sql/docs/mysql/sql-proxy .. _`GCPロールのページ`: https://cloud.google.com/iam/docs/understanding-roles .. _`Azureロールのページ`: https://docs.microsoft.com/ja-jp/azure/role-based-access-control/built-in-roles .. _`ターゲットリソース`: https://cloud.google.com/config-connector/docs/reference/resource-docs/iam/iampolicymember#supported_resources .. _HTTPMatchRequest: https://istio.io/latest/docs/reference/config/networking/virtual-service/#HTTPMatchRequest .. _`ドキュメント`: https://kubernetes.io/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/ .. _cAdvisor Prometheus container metrics: https://github.com/google/cadvisor/blob/master/docs/storage/prometheus.md#prometheus-container-metrics .. _PodMonitor podMetricsEndpoint: https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#monitoring.coreos.com/v1.PodMetricsEndpoint .. _ServiceMonitor endpoints: https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#monitoring.coreos.com/v1.Endpoint .. _Prometheus Client Libraries: https://prometheus.io/docs/instrumenting/clientlibs/ .. _ロールとサービスアカウントの設定: ttps://docs.aws.amazon.com/ja_jp/eks/latest/userguide/associate-service-account-role.html