1.2. 可観測性サービスの有効化
可観測性サービス (multicluster-observability-operator) でマネージドクラスターの状態を監視します。
必要なアクセス権: クラスター管理者、open-cluster-management:cluster-manager-admin ロール、または S3 管理者。
1.2.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- Red Hat Advanced Cluster Management for Kubernetes がインストールされている。詳細は、ネットワーク接続時のオンラインインストール を参照してください。
-
デフォルトのストレージクラスが指定されていない場合、
MultiClusterObservabilityCR でストレージクラスを定義する必要があります。 ストレージソリューションを作成するようにオブジェクトストアが設定されている。Red Hat Advanced Cluster Management は、安定したオブジェクトストアで以下のクラウドプロバイダーをサポートします。
- Amazon Web Services S3 (AWS S3)
- Red Hat Ceph (S3 互換 API)
- Google Cloud Storage
- Azure ストレージ
- Red Hat OpenShift Data Foundation (旧称: Red Hat OpenShift Container Storage)
Red Hat OpenShift on IBM(ROKS)
重要: オブジェクトストアを設定する場合は、機密データを永続化する時に必要な暗号化要件を満たすようにしてください。Thanos がサポートするオブジェクトストアの詳細は、Thanos のドキュメント を参照してください。
1.2.2. 可観測性の有効化 リンクのコピーリンクがクリップボードにコピーされました!
MultiClusterObservability カスタムリソース (CR) を作成して可観測性サービスを有効にします。可観測性を有効にする前に、可観測性 Pod の容量要求 を参照してください。
注記: Red Hat Advanced Cluster Management が管理する OpenShift Container Platform マネージドクラスターで可観測性を有効または無効にすると、可観測性エンドポイント Operator は、ローカル Prometheus を自動的に再起動する alertmanager 設定を追加して cluster-monitoring-config ConfigMap を更新します。
可観測性サービスを有効にするには、以下の手順を実行します。
- Red Hat Advanced Cluster Management ハブクラスターにログインします。
以下のコマンドを使用して可観測性サービスの namespace を作成します。
oc create namespace open-cluster-management-observabilityプルシークレットを生成します。Red Hat Advanced Cluster Management が
open-cluster-managementnamespace に インストールされている場合は、以下のコマンドを実行します。DOCKER_CONFIG_JSON=`oc extract secret/multiclusterhub-operator-pull-secret -n open-cluster-management --to=-`multiclusterhub-operator-pull-secretが namespace に定義されていない場合には、pull-secretをopenshift-confignamespace からopen-cluster-management-observabilitynamespace にコピーします。以下のコマンドを実行します。DOCKER_CONFIG_JSON=`oc extract secret/pull-secret -n openshift-config --to=-`次に
open-cluster-management-observabilitynamespace でプルリクエストを作成して、以下のコマンドを実行します。oc create secret generic multiclusterhub-operator-pull-secret \ -n open-cluster-management-observability \ --from-literal=.dockerconfigjson="$DOCKER_CONFIG_JSON" \ --type=kubernetes.io/dockerconfigjsonお使いのクラウドプロバイダーのオブジェクトストレージのシークレットを作成します。シークレットには、ストレージソリューションへの認証情報を追加する必要があります。たとえば、以下のコマンドを実行します。
oc create -f thanos-object-storage.yaml -n open-cluster-management-observabilityサポートされるオブジェクトストアのシークレットの例を以下に示します。
Amazon S3 または S3 と互換性のある場合、シークレットは以下のファイルのようになります。
apiVersion: v1 kind: Secret metadata: name: thanos-object-storage namespace: open-cluster-management-observability type: Opaque stringData: thanos.yaml: | type: s3 config: bucket: YOUR_S3_BUCKET endpoint: YOUR_S3_ENDPOINT insecure: true access_key: YOUR_ACCESS_KEY secret_key: YOUR_SECRET_KEY詳細は、Amazon Simple Storage Service ユーザーガイド を参照してください。
Google の場合は、以下のファイルのようになります。
apiVersion: v1 kind: Secret metadata: name: thanos-object-storage namespace: open-cluster-management-observability type: Opaque stringData: thanos.yaml: | type: GCS config: bucket: YOUR_GCS_BUCKET service_account: YOUR_SERVICE_ACCOUNT詳細は、Google Cloud Storage とは を参照してください。
Azure の場合は、以下のファイルのようになります。
apiVersion: v1 kind: Secret metadata: name: thanos-object-storage namespace: open-cluster-management-observability type: Opaque stringData: thanos.yaml: | type: AZURE config: storage_account: YOUR_STORAGE_ACCT storage_account_key: YOUR_STORAGE_KEY container: YOUR_CONTAINER endpoint: blob.core.windows.net max_retries: 0詳細は、Azure Storage のドキュメント を参照してください。
注記: Azure を Red Hat OpenShift Container Platform クラスターのオブジェクトストレージとして使用する場合には、クラスターに関連付けられたストレージアカウントはサポートされません。新規ストレージアカウントを作成する必要があります。
Red Hat OpenShift Data Foundation では、シークレットは以下のファイルのようになります。
apiVersion: v1 kind: Secret metadata: name: thanos-object-storage namespace: open-cluster-management-observability type: Opaque stringData: thanos.yaml: | type: s3 config: bucket: YOUR_RH_DATA_FOUNDATION_BUCKET endpoint: YOUR_RH_DATA_FOUNDATION_ENDPOINT insecure: false access_key: YOUR_RH_DATA_FOUNDATION_ACCESS_KEY secret_key: YOUR_RH_DATA_FOUNDATION_SECRET_KEY詳細は、Red Hat OpenShift Data Foundation を参照してください。Red Hat OpenShift on IBM (ROKS) では、シークレットは以下のファイルのようになります。
apiVersion: v1 kind: Secret metadata: name: thanos-object-storage namespace: open-cluster-management-observability type: Opaque stringData: thanos.yaml: | type: s3 config: bucket: YOUR_ROKS_S3_BUCKET endpoint: YOUR_ROKS_S3_ENDPOINT insecure: true access_key: YOUR_ROKS_ACCESS_KEY secret_key: YOUR_ROKS_SECRET_KEY詳細は、IBM Cloud のドキュメント Cloud Object Storage を参照してください。サービスの認証情報を使用してオブジェクトストレージに接続するようにしてください。詳細は、IBM Cloud のドキュメント、Cloud Object Store および Service Credentials を参照してください。
Amazon S3 または S3 と互換性のあるストレージの場合、AWS Security Token Service (AWS STS) で生成された短期間の限定特権認証情報を使用することもできます。詳細については、AWS Security Token Service ドキュメント を参照してください。
AWS Security Service を使用してアクセスキーを生成するには、次の追加の手順が必要です。
- S3 バケットへのアクセスを制限する IAM ポリシーを作成します。
- OpenShift Container Platform サービスアカウントの JWT トークンを生成するための信頼ポリシーを持つ IAM ロールを作成します。
- S3 バケットへのアクセスが必要な可観測性サービスアカウントのアノテーションを指定します。Red Hat OpenShift Service on AWS (ROSA) クラスターでオブザーバビリティを設定して AWS STS トークンを使用する方法の例は 環境の設定 ステップで確認できます。詳細については、Red Hat OpenShift Service on AWS (ROSA) を参照してください。また、STS トークンを使用するための要件とセットアップの詳細な説明については、ROSA with STS の説明 を参照してください。
AWS Security Service を使用してアクセスキーを生成するには、次の手順を実行します。
AWS 環境をセットアップします。以下のコマンドを実行します。
export POLICY_VERSION=$(date +"%m-%d-%y") export TRUST_POLICY_VERSION=$(date +"%m-%d-%y") export CLUSTER_NAME=<my-cluster> export S3_BUCKET=$CLUSTER_NAME-acm-observability export REGION=us-east-2 export NAMESPACE=open-cluster-management-observability export SA=tbd export SCRATCH_DIR=/tmp/scratch export OIDC_PROVIDER=$(oc get authentication.config.openshift.io cluster -o json | jq -r .spec.serviceAccountIssuer| sed -e "s/^https:\/\///") export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) export AWS_PAGER="" rm -rf $SCRATCH_DIR mkdir -p $SCRATCH_DIR次のコマンドで S3 バケットを作成します。
aws s3 mb s3://$S3_BUCKETS3 バケットにアクセスするための
s3-policyJSON ファイルを作成します。以下のコマンドを実行します。{ "Version": "$POLICY_VERSION", "Statement": [ { "Sid": "Statement", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetObject", "s3:DeleteObject", "s3:PutObject", "s3:PutObjectAcl", "s3:CreateBucket", "s3:DeleteBucket" ], "Resource": [ "arn:aws:s3:::$S3_BUCKET/*", "arn:aws:s3:::$S3_BUCKET" ] } ] }次のコマンドでポリシーを適用します。
S3_POLICY=$(aws iam create-policy --policy-name $CLUSTER_NAME-acm-obs \ --policy-document file://$SCRATCH_DIR/s3-policy.json \ --query 'Policy.Arn' --output text) echo $S3_POLICYTrustPolicyJSON ファイルを作成します。以下のコマンドを実行します。{ "Version": "$TRUST_POLICY_VERSION", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_PROVIDER}" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "${OIDC_PROVIDER}:sub": [ "system:serviceaccount:${NAMESPACE}:observability-thanos-query", "system:serviceaccount:${NAMESPACE}:observability-thanos-store-shard", "system:serviceaccount:${NAMESPACE}:observability-thanos-compact" "system:serviceaccount:${NAMESPACE}:observability-thanos-rule", "system:serviceaccount:${NAMESPACE}:observability-thanos-receive", ] } } } ] }次のコマンドを使用して、AWS Prometheus と CloudWatch のロールを作成します。
S3_ROLE=$(aws iam create-role \ --role-name "$CLUSTER_NAME-acm-obs-s3" \ --assume-role-policy-document file://$SCRATCH_DIR/TrustPolicy.json \ --query "Role.Arn" --output text) echo $S3_ROLEポリシーをロールにアタッチします。以下のコマンドを実行します。
aws iam attach-role-policy \ --role-name "$CLUSTER_NAME-acm-obs-s3" \ --policy-arn $S3_POLICYシークレットは、次のファイルのようになる場合があります。
configセクションではsignature_version2: falseが指定されており、access_keyとsecret_keyは指定されていません。apiVersion: v1 kind: Secret metadata: name: thanos-object-storage namespace: open-cluster-management-observability type: Opaque stringData: thanos.yaml: | type: s3 config: bucket: $S3_BUCKET endpoint: s3.$REGION.amazonaws.com signature_version2: false-
MultiClusterObservability CR の作成 セクションで説明されているように、
MultiClusterObservabilityカスタムリソース (CR) を使用するときに、サービスアカウントアノテーションを指定します。 以下のコマンドを使用して、クラウドプロバイダーの S3 アクセスキーおよびシークレットキーを取得できます。シークレットの
base64文字列のデコード、編集、エンコードが必要です。YOUR_CLOUD_PROVIDER_ACCESS_KEY=$(oc -n open-cluster-management-observability get secret <object-storage-secret> -o jsonpath="{.data.thanos\.yaml}" | base64 --decode | grep access_key | awk '{print $2}') echo $ACCESS_KEY YOUR_CLOUD_PROVIDER_SECRET_KEY=$(oc -n open-cluster-management-observability get secret <object-storage-secret> -o jsonpath="{.data.thanos\.yaml}" | base64 --decode | grep secret_key | awk '{print $2}') echo $SECRET_KEY次のデプロイメントとステートフルセットの Pod をチェックして、可観測性が有効になっていることを確認します。次の情報が表示される場合があります。
observability-thanos-query (deployment) observability-thanos-compact (statefulset) observability-thanos-receive-default (statefulset) observability-thanos-rule (statefulset) observability-thanos-store-shard-x (statefulsets)
1.2.2.1. MultiClusterObservability CR の作成 リンクのコピーリンクがクリップボードにコピーされました!
次の手順を実行して、ハブクラスターに MultiClusterObservability カスタムリソース (CR) を作成します。
multiclusterobservability_cr.yamlという名前のMultiClusterObservabilityカスタムリソースの YAML ファイルを作成します。可観測性については、以下のデフォルト YAML ファイルを確認してください。
apiVersion: observability.open-cluster-management.io/v1beta2 kind: MultiClusterObservability metadata: name: observability spec: observabilityAddonSpec: {} storageConfig: metricObjectStorage: name: thanos-object-storage key: thanos.yamladvancedセクションでretentionConfigパラメーターの値を変更する必要がある場合があります。詳細は、Thanos Downsampling resolution and retention を参照してください。マネージドクラスターの数によっては、ステートフルセットのストレージの量を更新する必要がある場合があります。S3 バケットが STS トークンを使用するように設定されている場合は、S3 ロールで STS を使用するようにサービスアカウントにアノテーションを付けます。次の設定を表示します。spec: advanced: compact: eks.amazonaws.com/role-arn=$S3_ROLE store: eks.amazonaws.com/role-arn=$S3_ROLE rule: eks.amazonaws.com/role-arn=$S3_ROLE receive: eks.amazonaws.com/role-arn=$S3_ROLE query: eks.amazonaws.com/role-arn=$S3_ROLE詳細については、可観測性 API を参照してください。
インフラストラクチャーマシンセットにデプロイするには、
MultiClusterObservabilityYAML のnodeSelectorを更新して、セットのラベルを設定する必要があります。YAML の内容は以下のようになります。nodeSelector: node-role.kubernetes.io/infra:詳細は、インフラストラクチャーマシンセットの作成 を参照してください。
以下のコマンドを実行して可観測性 YAML をクラスターに適用します。
oc apply -f multiclusterobservability_cr.yamlThanos、Grafana および AlertManager の
open-cluster-management-observabilitynamespace に全 Pod を作成します。Red Hat Advanced Cluster Management ハブクラスターに接続されたマネージドクラスターはすべて、メトリクスを Red Hat Advanced Cluster Management の可観測性サービスに送信できます。Grafana ダッシュボードを起動して可観測性サービスが有効になっていることを検証し、データが入力されていることを確認します。コンソールの 概要 ページまたは クラスター ページから、コンソールヘッダーの近くにある Grafana リンク をクリックします。
注記: 可観測性データを収集しないように特定のマネージドクラスターを除外するには、クラスターに
observability: disabledクラスターラベルを追加します。
可観測性サービスを有効化します。可観測性サービスを有効にすると、次の機能が開始されます。
- マネージドクラスターからのアラートマネージャーはすべて、Red Hat Advanced Cluster Management ハブクラスターに転送されます。
Red Hat Advanced Cluster Management ハブクラスターに接続されたマネージドクラスターはすべて、アラートを Red Hat Advanced Cluster Management の可観測性サービスに送信できます。Red Hat Advanced Cluster Management Alertmanager を設定して、重複を排除してグループ化し、アラートをメール、PagerDuty、または OpsGenie などの適切なレシーバー統合にルーティングすることができます。アラートの通知解除や抑制にも対応できます。
注記: Red Hat Advanced Cluster Management ハブクラスター機能へのアラート転送は、Red Hat OpenShift Container Platform バージョン 4.8 以降のマネージドクラスターでのみサポートされます。可観測性を有効にして Red Hat Advanced Cluster Management をインストールすると、OpenShift Container Platform v4.8 以降のアラートは自動的にハブクラスターに転送されます。
詳細は、送信アラート を参照してください。
-
次の URL を使用して OpenShift Container Platform 3.11 Grafana ダッシュボードにアクセスします:
https://$ACM_URL/grafana/dashboards。OCP 3.11 という名前のフォルダーを選択して、OpenShift Container Platform 3.11 ダッシュボードを表示します。
-
次の URL を使用して OpenShift Container Platform 3.11 Grafana ダッシュボードにアクセスします:
1.2.3. Red Hat OpenShift Container Platform コンソールからの可観測性の有効化 リンクのコピーリンクがクリップボードにコピーされました!
オプションで、Red Hat OpenShift Container Platform コンソールから可観測性を有効にし、open-cluster-management-observability という名前のプロジェクトを作成します。open-cluster-management-observability プロジェクトに、multiclusterhub-operator-pull-secret という名前のイメージプルシークレットを作成してください。
open-cluster-management-observability プロジェクトに thanos-object-storage という名前のオブジェクトストレージシークレットを作成します。オブジェクトストレージシークレットの詳細を入力し、Create をクリックします。
注記: シークレットの例を表示するには、可観測性の有効化 セクションの手順 4 を参照してください。
MultiClusterObservability CR インスタンスを作成します。Observability components are deployed and running のメッセージが表示されると、OpenShift Container Platform から可観測性サービスが正常に有効化されています。
1.2.3.1. 外部メトリクスクエリーの使用 リンクのコピーリンクがクリップボードにコピーされました!
可観測性には、外部 API があり、OpenShift ルート (rbac-query-proxy) を使用してメトリクスをクエリーできます。以下のタスクを確認して、rbac-query-proxy ルートを使用します。
以下のコマンドを使用して、ルートの詳細を取得できます。
oc get route rbac-query-proxy -n open-cluster-management-observability-
rbac-query-proxyルートにアクセスするには、OpenShift OAuth アクセストークンが必要です。トークンは、namespace 取得のパーミッションがあるユーザーまたはサービスアカウントと関連付ける必要があります。詳細は、ユーザーが所有する OAuth アクセストークンの管理 について参照してください。 デフォルトの CA 証明書を取得し、
tls.crtキーの内容をローカルファイルに保存します。以下のコマンドを実行します。oc -n openshift-ingress get secret router-certs-default -o jsonpath="{.data.tls\.crt}" | base64 -d > ca.crt以下のコマンドを実行してメトリクスのクエリーを実行します。
curl --cacert ./ca.crt -H "Authorization: Bearer {TOKEN}" https://{PROXY_ROUTE_URL}/api/v1/query?query={QUERY_EXPRESSION}注記:
QUERY_EXPRESSIONは標準の Prometheus クエリー式です。たとえば、cluster_infrastructure_providerメトリクスのクエリーには、前述したコマンドの URL をhttps://{PROXY_ROUTE_URL}/api/v1/query?query=cluster_infrastructure_providerの URL に置き換えます。詳細は、prometheus のクエリー を参照してください。rbac-query-proxyルートの証明書を置き換えることもできます。証明書を生成するための OpenSSL コマンド を参照して、証明書を作成します。csr.cnfをカスタマイズする時に、DNS.1をrbac-query-proxyルートのホスト名に更新します。以下のコマンドを実行し、生成された証明書を使用して
proxy-byo-caシークレッおよびproxy-byo-certシークレットを作成します。oc -n open-cluster-management-observability create secret tls proxy-byo-ca --cert ./ca.crt --key ./ca.key oc -n open-cluster-management-observability create secret tls proxy-byo-cert --cert ./ingress.crt --key ./ingress.key
1.2.3.2. 単一ノード OpenShift クラスターの動的メトリック リンクのコピーリンクがクリップボードにコピーされました!
動的メトリクスコレクションは、特定の条件に基づく自動メトリクス収集をサポートします。デフォルトで、SNO クラスターは Pod およびコンテナーのリソースメトリクスを収集しません。SNO クラスターが特定のリソース消費レベルに達すると、定義された詳細なメトリクスが動的に収集されます。クラスターリソースの消費量が一定期間しきい値を一貫して下回ると、詳細なメトリック収集が停止します。
メトリクスは、コレクションルールで指定されたマネージドクラスターの状態に基づいて動的に収集されます。これらのメトリクスは動的に収集されるため、以下の Red Hat Advanced Cluster Management Grafana ダッシュボードではデータは表示されません。コレクションルールがアクティブになり、対応するメトリクスが収集されると、以下のパネルには、コレクションルールが開始される期間のデータが表示されます。
- Kubernetes/コンピューティングリソース/namespace (Pod)
- Kubernetes/コンピューティングリソース/namespace (ワークロード)
- Kubernetes/コンピューティングリソース/ノード (Pod)
- Kubernetes/コンピューティングリソース/Pod
- Kubernetes/コンピューティングリソース/ワークロード
コレクションルールには、以下の条件が含まれます。
- 動的に収集するメトリクスのセット。
- PromQL 式として記述された条件。
-
コレクションの間隔。
trueに設定する必要があります。 - 収集ルールを評価する必要のあるクラスターを選択するための一致式。
デフォルトでは、コレクションルールは、30 秒ごとにマネージドクラスターで継続的に評価されるか、または特定の間隔で評価されます。コレクションの間隔と時間間隔の最小値が優先されます。収集ルールの条件が for 属性で指定された期間持続すると、収集ルールが開始され、ルールで指定されたメトリックがマネージドクラスターに自動的に収集されます。メトリックの収集は、収集ルールの条件がマネージドクラスターに存在しなくなった後、開始してから少なくとも 15 分後に自動的に停止します。
収集ルールは、collect_rules という名前のパラメーターセクションとしてグループ化され、グループとして有効または無効にできます。Red Hat Advanced Cluster Management インストールには、コレクションルールグループ (HighCPUUsage および HighMemoryUsage) のデフォルトコレクションルール SNOResourceUsage が含まれます。HighCPUUsage コレクションルールは、ノードの CPU 使用率が 70% を超えると開始されます。HighMemoryUsage コレクションルールは、SNO クラスターの全体的なメモリー使用率が利用可能なノードメモリーの合計 70% を超えると開始されます。現在、上記のしきい値は固定されており、変更できません。コレクションルールが for 属性で指定された間隔を超えて開始すると、システムは dynamic_metrics セクションに指定されたメトリクスの収集を自動的に開始します。
以下の YAML ファイルで、collect_rules セクションからの動的メトリクスの一覧を表示します。
collect_rules:
- group: SNOResourceUsage
annotations:
description: >
By default, a SNO cluster does not collect pod and container resource metrics. Once a SNO cluster
reaches a level of resource consumption, these granular metrics are collected dynamically.
When the cluster resource consumption is consistently less than the threshold for a period of time,
collection of the granular metrics stops.
selector:
matchExpressions:
- key: clusterType
operator: In
values: ["SNO"]
rules:
- collect: SNOHighCPUUsage
annotations:
description: >
Collects the dynamic metrics specified if the cluster cpu usage is constantly more than 70% for 2 minutes
expr: (1 - avg(rate(node_cpu_seconds_total{mode=\"idle\"}[5m]))) * 100 > 70
for: 2m
dynamic_metrics:
names:
- container_cpu_cfs_periods_total
- container_cpu_cfs_throttled_periods_total
- kube_pod_container_resource_limits
- kube_pod_container_resource_requests
- namespace_workload_pod:kube_pod_owner:relabel
- node_namespace_pod_container:container_cpu_usage_seconds_total:sum_irate
- node_namespace_pod_container:container_cpu_usage_seconds_total:sum_rate
- collect: SNOHighMemoryUsage
annotations:
description: >
Collects the dynamic metrics specified if the cluster memory usage is constantly more than 70% for 2 minutes
expr: (1 - sum(:node_memory_MemAvailable_bytes:sum) / sum(kube_node_status_allocatable{resource=\"memory\"})) * 100 > 70
for: 2m
dynamic_metrics:
names:
- kube_pod_container_resource_limits
- kube_pod_container_resource_requests
- namespace_workload_pod:kube_pod_owner:relabel
matches:
- __name__="container_memory_cache",container!=""
- __name__="container_memory_rss",container!=""
- __name__="container_memory_swap",container!=""
- __name__="container_memory_working_set_bytes",container!=""
以下の例のように、collect_rules.group は custom-allowlist で無効にできます。collect_rules.group を無効にすると、メトリクスコレクションは以前の動作に戻ります。これらのメトリクスは定期的に、指定された間隔で収集されます。
collect_rules:
- group: -SNOResourceUsage
データは、ルールの開始時のみ Grafana に表示されます。
1.2.4. 可観測性の無効化 リンクのコピーリンクがクリップボードにコピーされました!
observability リソースをアンインストールして、可観測性サービスを無効にします。OpenShift Container Platform コンソールナビゲーションから、Operators > Installed Operators > Advanced Cluster Manager for Kubernetes の順に選択します。MultiClusterObservability カスタムリソースを削除します。
可観測性サービスのカスタマイズ方法の詳細は、可観測性のカスタマイズ を参照してください。