Distributed Cloud Connected は、複数の Google Cloud サービスのデプロイをサポートしています。これらのサービス ワークロードは、Distributed Cloud 接続クラスタの Kubernetes コンテナで実行されます。
サポート対象の Google Cloud サービス
Distributed Cloud Connected は、次のGoogle Cloud サービスのデプロイをサポートしています。
| サービスタイプ | GDC コネクテッドの費用に含まれる | 別途請求 |
|---|---|---|
| コンピューティング | ソフトウェアのみの Google Distributed Cloud Google Distributed Cloud 上の VM ランタイム |
ゲスト オペレーティング システム (お客様がライセンスを取得する必要があります) |
| ストレージ | Raw(永続ボリューム)ストレージ Container Storage Interface(CSI) ハイブリッド ストレージ |
ソフトウェア定義ストレージ(SDS)、 (Symcloud Storage など) (独自のライセンスを取得する必要があります) |
| ネットワーキング | Edge Network API VLAN のサポート GKE カスタム ネットワーク インターフェース(CNI)プラグイン GKE バンドル L4 ロードバランサ |
該当なし |
| AI/ML | コンテナでの AutoML モデルのデプロイ | 該当なし |
| データベース | なし | AlloyDB Omni(プレビュー) MongoDB などのサードパーティ データベース ソリューション (独自のライセンスを取得する必要があります) |
| オブザーバビリティ | Cloud Logging Cloud Monitoring Cloud Logging API GDCc のログと指標 |
切断されたオブザーバビリティのための Prometheus アプリケーション レベルのカスタムログと指標 |
| 構成管理 | Config Sync フリート パッケージ(プレビュー) |
該当なし |
| 管理 | Google Cloud コンソール の Google Kubernetes Engine ダッシュボード Connect Gateway kubectlローカルツールDistributed Cloud 接続ソフトウェアのアップグレード |
該当なし |
| セキュリティ | Cloud Key Management Service の統合 自己暗号化ディスク(SED)ドライブ フリート ワークロード ID 監査ロギング |
該当なし |
前提条件
Distributed Cloud Connected にサービスをデプロイする前に、このセクションに記載されている前提条件を満たす必要があります。 Google Cloud
クラスタの認証情報を取得する
次のコマンドを使用して、ターゲット クラスタにアクセスするための認証情報を取得します。
gcloud container hub memberships get-credentials CLUSTER_ID \
--project="PROJECT_ID"
次のように置き換えます。
CLUSTER_ID: 対象とするクラスタの名前。PROJECT_ID: ターゲット Google Cloud プロジェクトの ID。
クラスタを作成または選択する
まだ作成していない場合は、クラスタを作成するの説明に従って、Distributed Cloud 接続クラスタを作成します。クラスタの作成時に、少なくとも 8 個の仮想 IP アドレス(VIP)を指定します。これらの VIP は、 Google Cloud サービス ワークロードを実行する Kubernetes コンテナで使用されます。
既存のクラスタを使用している場合は、次のコマンドを使用して、そのクラスタで十分な VIP が利用可能であることを確認します。
kubectl get cluster --all-namespaces -o jsonpath="{.items[0].spec.loadBalancer.addressPools}"
このコマンドでは、次のような出力が返されます。
[
{
"addresses": [
"10.200.11.188-10.200.11.196"
],
"name": "loadBalancerAddressPool-1"
}
]
クラスタにプロビジョニングされた VIP が不足している場合は、次のエラーが表示されます。ここで、n は必要な VIP の数、m はクラスタで検出された VIP の数です。
Cluster has less than n external IPs, got m.
このエラーが発生した場合は、十分な数の VIP を使用してクラスタを削除して再作成する必要があります。
Google Cloud サービス サブドメインを構成する
Distributed Cloud 接続ゾーンに最初の Google Cloud サービスをデプロイする前に、そのゾーンにデプロイされたすべての Google Cloud サービスが接続をリッスンするサブドメインをカスタマイズできます。このサブドメインは、その Distributed Cloud ゾーンに 1 つ以上のサービスをデプロイした後は変更できません。
サブドメイン構成を表示するには、次のコマンドを使用します。
kubectl -n dns-system get celldns cell-dns -o yaml
このコマンドでは、次のような出力が返されます。
apiVersion: system.private.gdc.goog/v1alpha1
kind: CellDNS
metadata:
name: cell-dns
namespace: dns-system
spec:
delegatedSubdomain: private.goog
次のコマンドを使用して、サブドメイン構成を変更します。
kubectl -n dns-system edit celldns cell-dns
Distributed Cloud コネクテッドに Google Cloud サービスをデプロイする
Distributed Cloud 接続クラスタに Google Cloud サービスをデプロイするには、そのサービスのドキュメントに記載されているデプロイ手順に沿って操作します。
デプロイされた Google Cloud サービスを構成する
このセクションでは、ビジネス要件に基づいて完了するデプロイ後の構成手順について説明します。
内部 DNS からクラスタの DNS に DNS クエリを転送する
Distributed Cloud 接続クラスタに Google Cloud サービスをデプロイすると、そのサービスの専用 DNS サーバーがクラスタにデプロイされます。サービスのサブドメインの DNS クエリを、クラスタに新しく作成された DNS サーバーに転送することをおすすめします。
次のコマンドを使用して、クラスタのサブドメインを取得します。
CLUSTER_SUBDOMAIN=$(kubectl get configmap -n \ $(kubectl get clusters -A -o jsonpath="{.items[0].metadata.namespace}") \ dns-prefix -o jsonpath="{.data.dnsPrefix}") DELEGATED_SUBDOMAIN=$(kubectl get celldns -n dns-system cell-dns -o \ jsonpath="{.spec.delegatedSubdomain}") CLUSTER_FQDN="${CLUSTER_SUBDOMAIN?}.${DELEGATED_SUBDOMAIN?}" echo "${CLUSTER_FQDN?}"最後のコマンドは、次のような出力を返します。
my-zone.google.private.goog次のコマンドを使用して、クラスタ内 DNS サーバーの VIP を取得します。
DNS_EXT_IP=$(k -n dns-system get service gpc-coredns-external-tcp -o "jsonpath={.status.loadBalancer.ingress[0].ip}")デプロイされた Google Cloud サービスの DNS クエリを前の手順で取得した VIP に転送するように、内部 DNS サーバーを構成します。次に例を示します。
dnsmasqの場合は、/etc/dnsmasq.confに以下を追加します。server=/${CLUSTER_FQDN?}/${DNS_EXT_IP?}CoreDNS の場合は、Corefile に次を追加します。
${CLUSTER_FQDN?}:53 { errors cache 30 forward . ${DNS_EXT_IP?} { max_concurrent 1000 } }
DNS 解決をテストする
次の dig コマンドを使用して、ドメインが正しく解決されるかどうかをテストします。ANSWER SECTION には特に注意してください。
dig "ais-core.${CLUSTER_FQDN?}"
このコマンドでは、次のような出力が返されます。
...
;; ANSWER SECTION:
ais-core.my-zone.google.private.goog. 300 IN A 10.200.0.0
...
デプロイされた Google Cloud サービスの自己署名証明書を取得する
Distributed Cloud 接続クラスタに Google Cloud サービスをデプロイすると、Distributed Cloud 接続は自己署名証明書を発行し、その証明書を使用してサービスのネットワーク トラフィックを暗号化します。この証明書を取得し、信頼するようにビジネス環境を構成することをおすすめします。
この証明書を PEM エンコード形式で取得するには、次のコマンドを使用します。
kubectl get secret -n cert-manager-cluster-resources web-ca-cert -o jsonpath="{.data.ca\.crt}" | base64 -d
Distributed Cloud connected は、クラスタ全体で複数の信頼バンドルを生成します。これらの信頼バンドルは、クラスタのすべての Namespace に ConfigMap として保存されます。それらは次のとおりです。
trust-store-internal-only。Distributed Cloud connected の内部サービス用の認証局(CA)が含まれています。trust-store-root-ext。trust-store-root-ext内のすべての CA と、ターゲットGoogle Cloud service の自己署名証明書に署名した CA が含まれます。この信頼バンドルを Pod にマウントします。この Pod がターゲット Google Cloud サービスにアクセスする必要がある場合です。trust-store-user-ext。trust-store-root-ext内のすべての CA と、手動で追加した CA が含まれます。この Pod がターゲット Google Cloud サービスと、手動で追加した CA によって署名された証明書を使用する内部リソースの両方にアクセスする必要がある場合は、このバンドルを Pod にマウントします。
次のコマンドを使用して、ターゲット ConfigMap を表示します。
kubectl -n default get configmap trust-store-user-root-ext -o yaml
次の出力例は、一般的な trust-store-user-root-ext ConfigMap リソースを示しています。
apiVersion: v1
binaryData:
ca.jks: WW91IGFyZSBhd2Vzb21lIQo=
data:
ca.crt: |-
-----BEGIN CERTIFICATE-----
WW91IGFyZSBncmVhdCEK
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
WW91IGFyZSBmYW50YXN0aWMhCg==
-----END CERTIFICATE-----
kind: ConfigMap
metadata:
labels:
trust.cert-manager.io/bundle: trust-store-user-root-ext
name: trust-store-user-root-ext
namespace: default
独自の証明書を信頼するようにデプロイされた Google Cloud サービスを構成する
Distributed Cloud 接続クラスタに TLS Secret を作成し、cert-manager-cluster-resources Namespace の security.private.gdc.goog/bundles=trust-store-user-root-ext アノテーションでアノテーションを付けることができます。これにより、デプロイされた Google Cloudサービスが内部のサードパーティ サービスを信頼し、それらの間でデータを交換できるようになります。
このシークレットをクラスタに適用すると、デプロイされた Google Cloud サービスは、シークレットで参照されている ca.crt ファイルに保存されている CA 証明書を信頼します。次に例を示します。
apiVersion: v1
data:
ca.crt: base64EncodedCaCert
tls.crt: base64EncodedCert
tls.key: base64EncodedKey
kind: Secret
metadata:
annotations:
security.private.gdc.goog/bundles: trust-store-user-root-ext
name: my-corporate-cert
namespace: cert-manager-cluster-resources
type: kubernetes.io/tls
認証プロバイダを構成する
デプロイされたGoogle Cloud サービスのユーザー インターフェースを使用して、認証プロバイダを構成し、ログオンを容易にすることができます。次の例は、OpenID Connect プロバイダの構成を示しています。
apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
name: default
namespace: kube-public
spec:
authentication:
- name: "google-oidc"
oidc:
clientID: "my-supersecret-client-id.apps.googleusercontent.com"
clientSecret: "my-supersecret-secret"
issuerURI: "https://accounts.google.com"
scopes: "email"
userClaim: "email"
name: "default"
詳細については、個々のクラスタに GKE Identity Service を設定するをご覧ください。
デプロイされた Google Cloud サービスを使用する
ビジネス要件を満たすように構成する方法については、デプロイされた Google Cloud サービスのドキュメントをご覧ください。
デプロイされた Google Cloud サービスを削除する
デプロイされた Google Cloud サービスを Distributed Cloud 接続クラスタから削除するには、そのサービスのドキュメントの手順に沿って操作します。このページで説明されている省略可能なデプロイ後の手順を完了した場合は、次の操作も行います。
- 内部 DNS で、サービスのサブドメインへの DNS 転送を無効にします。
- 信頼が確立されている場所で、サービスの自己署名証明書の信頼を無効にします。