O Distributed Cloud Connected oferece suporte à implantação de vários serviços Google Cloud . Essas cargas de trabalho de serviço são executadas em contêineres do Kubernetes nos seus clusters conectados do Distributed Cloud.
Serviços Google Cloud compatíveis
O Distributed Cloud Connected é compatível com a implantação dos seguintes serviços doGoogle Cloud :
| Tipo de serviço | Incluído nos custos do GDC conectado | Faturado separadamente |
|---|---|---|
| Computação | Google Distributed Cloud somente software Ambiente de execução de VM no Google Distributed Cloud |
Sistemas operacionais convidados (você precisa adquirir suas próprias licenças) |
| Armazenamento | Armazenamento bruto (volume permanente) Interface de armazenamento em contêineres (CSI) Armazenamento híbrido |
Armazenamento definido por software (SDS), como o Symcloud Storage . Você precisa adquirir suas próprias licenças. |
| Rede | API Edge Network Suporte a VLAN Plug-ins de interface de rede personalizada (CNI) do GKE Balanceador de carga L4 agrupado do GKE |
Não relevante |
| IA/ML | Como implantar modelos do AutoML em contêineres | Não relevante |
| banco de dados | Nenhum | AlloyDB Omni (prévia) Soluções de banco de dados de terceiros, como o MongoDB (você precisa adquirir suas próprias licenças) |
| Observabilidade | Cloud Logging Cloud Monitoring API Cloud Logging Registros e métricas do GDCc |
Prometheus para observabilidade desconectada Registros e métricas personalizados no nível do aplicativo |
| Gerenciamento de configurações | Config Sync Pacotes da frota (prévia) |
Não relevante |
| Gerenciamento | Painel do Google Kubernetes Engine no Google Cloud console Connect Gateway A kubectl ferramenta localUpgrades de software conectados do Distributed Cloud |
Não relevante |
| Segurança | Integração do Cloud Key Management Service Unidades de disco autoencriptadas (SEDs) Identidade de carga de trabalho da frota Registro de auditoria |
Não relevante |
Pré-requisitos
Antes de implantar serviços Google Cloud no Distributed Cloud Connected, é preciso concluir os pré-requisitos listados nesta seção.
Receber credenciais do cluster
Use o comando a seguir para acessar as credenciais do cluster de destino:
gcloud container hub memberships get-credentials CLUSTER_ID \
--project="PROJECT_ID"
Substitua:
CLUSTER_ID: o nome do cluster de destino.PROJECT_ID: o ID do projeto Google Cloud de destino.
Criar ou selecionar um cluster
Se ainda não tiver feito isso, crie um cluster conectado do Distributed Cloud conforme descrito em Criar um cluster. Ao criar o cluster, especifique pelo menos oito endereços IP virtuais (VIPs). Esses VIPs serão usados pelos contêineres do Kubernetes que executam suas cargas de trabalho de serviço do Google Cloud .
Se você estiver usando um cluster atual, use o seguinte comando para verificar se há VIPs suficientes disponíveis nele:
kubectl get cluster --all-namespaces -o jsonpath="{.items[0].spec.loadBalancer.addressPools}"
O comando retorna uma saída semelhante a esta:
[
{
"addresses": [
"10.200.11.188-10.200.11.196"
],
"name": "loadBalancerAddressPool-1"
}
]
Se houver VIPs insuficientes provisionados no cluster, o seguinte erro vai aparecer,
em que n é o número necessário de VIPs e m é o número de VIPs descobertos no
cluster:
Cluster has less than n external IPs, got m.
Se esse erro aparecer, exclua e recrie o cluster com um número suficiente de VIPs.
Configurar o subdomínio do serviço Google Cloud
Antes de implantar o primeiro serviço Google Cloud em uma zona conectada do Distributed Cloud, você pode personalizar o subdomínio em que todos os serviços Google Cloud implantados nessa zona vão aguardar conexões. Não é possível modificar esse subdomínio depois de implantar pelo menos um serviço nessa zona do Distributed Cloud.
Use o comando a seguir para conferir a configuração do subdomínio:
kubectl -n dns-system get celldns cell-dns -o yaml
O comando retorna uma saída semelhante a esta:
apiVersion: system.private.gdc.goog/v1alpha1
kind: CellDNS
metadata:
name: cell-dns
namespace: dns-system
spec:
delegatedSubdomain: private.goog
Use o comando a seguir para modificar a configuração do subdomínio:
kubectl -n dns-system edit celldns cell-dns
Implantar um serviço Google Cloud no Distributed Cloud conectado
Para implantar um serviço Google Cloud no cluster conectado do Distributed Cloud, siga as etapas de implantação descritas na documentação desse serviço.
Configurar o serviço Google Cloud implantado
Esta seção descreve as etapas de configuração pós-implantação que você pode concluir com base nos requisitos da sua empresa.
Encaminhar consultas DNS do DNS interno para o DNS do cluster
Quando você implanta um serviço Google Cloud no cluster conectado do Distributed Cloud, um servidor DNS dedicado a esse serviço é implantado no cluster. Recomendamos que você encaminhe consultas DNS para o subdomínio do serviço ao servidor DNS recém-criado no cluster.
Use os comandos a seguir para receber o subdomínio do cluster:
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?}"O último comando retorna uma saída semelhante a esta:
my-zone.google.private.googUse o comando a seguir para receber o VIP do servidor DNS no cluster:
DNS_EXT_IP=$(k -n dns-system get service gpc-coredns-external-tcp -o "jsonpath={.status.loadBalancer.ingress[0].ip}")Configure seu servidor DNS interno para encaminhar consultas DNS do serviço Google Cloud implantado para o VIP obtido na etapa anterior. Exemplo:
Para
dnsmasq, adicione o seguinte a/etc/dnsmasq.conf:server=/${CLUSTER_FQDN?}/${DNS_EXT_IP?}Para o CoreDNS, adicione o seguinte ao Corefile:
${CLUSTER_FQDN?}:53 { errors cache 30 forward . ${DNS_EXT_IP?} { max_concurrent 1000 } }
Testar a resolução de DNS
Use o seguinte comando dig para testar a resolução adequada do domínio. Preste atenção especial ao ANSWER SECTION:
dig "ais-core.${CLUSTER_FQDN?}"
O comando retorna uma saída semelhante a esta:
...
;; ANSWER SECTION:
ais-core.my-zone.google.private.goog. 300 IN A 10.200.0.0
...
Recupere o certificado autoassinado para o serviço Google Cloud implantado.
Ao implantar um serviço Google Cloud no cluster conectado do Distributed Cloud, o Distributed Cloud conectado emite um certificado autoassinado que usa para criptografar o tráfego de rede desse serviço. Recomendamos que você recupere esse certificado e configure seu ambiente de negócios para confiar nele.
Para receber esse certificado no formato codificado em PEM, use o seguinte comando:
kubectl get secret -n cert-manager-cluster-resources web-ca-cert -o jsonpath="{.data.ca\.crt}" | base64 -d
O Distributed Cloud Connected gera vários pacotes de confiança em todo o cluster. Esses pacotes de confiança são armazenados como ConfigMaps em todos os namespaces do cluster. São eles:
trust-store-internal-only. Contém autoridades de certificação (CAs) para os serviços internos do Distributed Cloud Connected.trust-store-root-ext. Contém todas as CAs emtrust-store-root-ext, além da CA que assinou o certificado autoassinado do serviçoGoogle Cloud de destino. Faça a montagem desse pacote de confiança em um pod se você precisar que ele acesse o serviço Google Cloud de destino.trust-store-user-ext. Contém todas as CAs emtrust-store-root-ext, além de todas as CAs adicionadas manualmente. Faça a montagem desse pacote em um pod se ele precisar acessar o serviço Google Cloud de destino e todos os recursos internos que usam certificados assinados pelas CAs adicionadas manualmente.
Use o comando a seguir para conferir o ConfigMap de destino:
kubectl -n default get configmap trust-store-user-root-ext -o yaml
O exemplo de saída a seguir mostra um recurso ConfigMap trust-store-user-root-ext típico:
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
Configurar um serviço Google Cloud implantado para confiar nos seus próprios certificados
É possível criar um secret TLS no cluster conectado do Distributed Cloud e
anotá-lo com a anotação security.private.gdc.goog/bundles=trust-store-user-root-ext
no namespace cert-manager-cluster-resources. Isso permite que o serviço Google Cloud
implantado confie nos seus serviços internos de terceiros para facilitar a troca de dados entre
eles.
Quando você aplica esse secret ao cluster, o serviço Google Cloud implantado confia no certificado da CA armazenado no arquivo ca.crt referenciado no secret. Exemplo:
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
Configurar um provedor de autenticação
É possível configurar um provedor de autenticação para facilitar o login pela interface do usuário do serviçoGoogle Cloud implantado. O exemplo a seguir mostra uma configuração para um provedor 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"
Para mais informações, consulte Sobre a autenticação usando identidades de terceiros.
Usar um Google Cloud serviço implantado
Consulte a documentação do serviço Google Cloud implantado para informações sobre como configurá-lo para atender aos requisitos da sua empresa.
Remover um serviço Google Cloud implantado
Para remover um serviço Google Cloud implantado do cluster conectado do Distributed Cloud, siga as etapas na documentação desse serviço. Se você concluiu alguma das etapas opcionais pós-implantação descritas nesta página, faça o seguinte:
- Desative o encaminhamento de DNS para o subdomínio do serviço no seu DNS interno.
- Desative a confiança no certificado autoassinado do serviço em todos os lugares em que ela foi estabelecida.