Anthos Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

Se usó la API de Cloud Translation para traducir esta página.

Integra cargas de trabajo de Kubernetes

En esta página, se muestra cómo integrar cargas de trabajo de Kubernetes con Cloud Service Mesh.

Implementa servicios de Kubernetes

Para implementar servicios de Kubernetes en clústeres con Cloud Service Mesh, debes hacer lo siguiente:

Crear objetos Service de Kubernetes para todos los contenedores. Todos los objetos Deployment deben tener un servicio de Kubernetes conectado.
Asigna un nombre a los puertos de los objetos Service. Aunque GKE te permite definir puertos de servicio sin nombre, Cloud Service Mesh requiere que proporciones un nombre para un puerto que coincida con el protocolo del puerto.
Etiqueta tus implementaciones. Esto te permite usar las funciones de administración de tráfico de Cloud Service Mesh, como dividir el tráfico entre versiones del mismo servicio.

En el siguiente ejemplo, la implementación y el servicio ilustran estos requisitos:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloserver
  template:
    metadata:
      labels:
        app: helloserver
    spec:
      containers:
      - image: gcr.io/google-samples/istio/helloserver:v0.0.1
        imagePullPolicy: Always
        name: main
      restartPolicy: Always
      terminationGracePeriodSeconds: 5

apiVersion: v1
kind: Service
metadata:
  name: hellosvc
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  selector:
    app: helloserver
  type: LoadBalancer

Después de implementar tus servicios en un clúster con Cloud Service Mesh, asegúrate de inyectar proxies de sidecar.

Ejemplo: Implementa la muestra de Online Boutique

La aplicación de ejemplo de Online Boutique en el repositorio anthos-service-mesh-packages se modifica a partir del conjunto original de manifiestos en el repositorio microservices-demo. De acuerdo con las prácticas recomendadas, cada servicio se implementa en un espacio de nombres distinto con una cuenta de servicio única.

Crea los espacios de nombres para la aplicación:

kubectl apply -f \
  DIR_PATH/samples/online-boutique/kubernetes-manifests/namespaces

Resultado esperado:

namespace/ad created
namespace/cart created
namespace/checkout created
namespace/currency created
namespace/email created
namespace/frontend created
namespace/loadgenerator created
namespace/payment created
namespace/product-catalog created
namespace/recommendation created
namespace/shipping created

Habilita los espacios de nombres para la inserción. Los pasos dependen de tu implementación del plano de control.
Administrado (TD)
Aplica la etiqueta de inserción predeterminada al espacio de nombres:
```
for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
  kubectl label namespace $ns \
      istio.io/rev- istio-injection=enabled --overwrite
done;
```
Administrada (Istiod)
Recomendado: Ejecuta el siguiente comando para aplicar la etiqueta de inserción predeterminada al espacio de nombres:
```
  for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
    kubectl label namespace $ns \
        istio.io/rev- istio-injection=enabled --overwrite
  done;
```
Si eres un usuario existente con el plano de control de Istio administrado, te recomendamos que uses la inserción predeterminada, pero también se admite la inserción basada en revisiones. Sigue estas instrucciones:
1. Ejecuta el siguiente comando para ubicar los canales de versiones disponibles:
  kubectl -n istio-system get controlplanerevision
  El resultado es similar a este:
  NAME AGE asm-managed-rapid 6d7h
  Nota: Si aparecen dos revisiones del plano de control en la lista anterior, quita una. No se admite tener varios canales de plano de control en el clúster.
  
  En el resultado, el valor en la columna NAME es la etiqueta de revisión que corresponde al canal de versiones disponible para la versión de Cloud Service Mesh.
2. Aplica la etiqueta de revisión al espacio de nombres:
  for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite done;
En el clúster
Recomendado: Ejecuta el siguiente comando para aplicar la etiqueta de inserción predeterminada al espacio de nombres:
```
  for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
    kubectl label namespace $ns \
        istio.io/rev- istio-injection=enabled --overwrite
  done;
```
Te recomendamos que uses la inserción predeterminada, pero también se admite la inserción basada en revisiones: Usa las siguientes instrucciones:
1. Usa el siguiente comando para encontrar la etiqueta de revisión en istiod:
  kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
2. Aplica la etiqueta de revisión a los espacios de nombres. En el siguiente comando, REVISION_LABEL es el valor de la etiqueta de revisión istiod que anotaste en el paso anterior.
  for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite done;

Implementa la aplicación de ejemplo en el clúster.

Crea las implementaciones y cuentas de servicio:

kubectl apply -f \
 DIR_PATH/samples/online-boutique/kubernetes-manifests/deployments

Resultado esperado:

serviceaccount/ad created
deployment.apps/adservice created
serviceaccount/cart created
deployment.apps/cartservice created
serviceaccount/checkout created
deployment.apps/checkoutservice created
serviceaccount/currency created
deployment.apps/currencyservice created
serviceaccount/email created
deployment.apps/emailservice created
serviceaccount/frontend created
deployment.apps/frontend created
serviceaccount/loadgenerator created
deployment.apps/loadgenerator created
serviceaccount/payment created
deployment.apps/paymentservice created
serviceaccount/product-catalog created
deployment.apps/productcatalogservice created
serviceaccount/recommendation created
deployment.apps/recommendationservice created
serviceaccount/shipping created
deployment.apps/shippingservice created

Crea los servicios:

kubectl apply -f \
 DIR_PATH/samples/online-boutique/kubernetes-manifests/services

Resultado esperado:

service/adservice created
service/cartservice created
service/checkoutservice created
service/currencyservice created
service/emailservice created
service/frontend created
service/frontend-external created
service/paymentservice created
service/productcatalogservice created
service/recommendationservice created
service/shippingservice created

Crea las entradas de servicio:

kubectl apply -f \
 DIR_PATH/samples/online-boutique/istio-manifests/allow-egress-googleapis.yaml

Resultado esperado:

serviceentry.networking.istio.io/allow-egress-googleapis created
serviceentry.networking.istio.io/allow-egress-google-metadata created

Asigna nombres a puertos de servicio

Para que se los incluya en Cloud Service Mesh, los puertos de servicio deben tener un nombre, y este debe incluir el protocolo del puerto, por ejemplo:

apiVersion: v1
kind: Service
metadata:
  name: ratings
  labels:
    app: ratings
    service: ratings
spec:
  ports:
  - port: 9080
    name: http

El nombre del puerto del servicio puede incluir un sufijo en la sintaxis name: protocol[-suffix], en la que los corchetes indican un sufijo opcional que debe comenzar con un guion, por ejemplo:

kind: Service
metadata:
  name: myservice
spec:
  ports:
  - number: 3306
    name: mysql
  - number: 80
    name: http-web

Para que las métricas se muestren en la consola de Google Cloud, los puertos del servicio deben tener nombres con alguno de los siguientes protocolos: http, http2 o grpc. Los puertos del servicio con el protocolo https se tratan como tcp, y no se muestran las métricas de esos servicios.

Inserta proxies de sidecar

En esta sección, se explica cómo configurar la inserción de proxy de sidecar con Cloud Service Mesh para mejorar la seguridad, la confiabilidad y la observabilidad de la red. Estas funciones se abstraen del contenedor principal de la aplicación y se implementan en un proxy fuera del proceso común (el archivo adicional), que se entrega como un contenedor por separado en el mismo Pod. Puedes usar las funciones de Cloud Service Mesh sin rediseñar tus aplicaciones de producción para participar en una malla de servicios.

La inserción automática del proxy de sidecar (la inserción automática) ocurre cuando Cloud Service Mesh detecta una etiqueta de espacio de nombres que se configura para el Pod de la carga de trabajo. El proxy intercepta todo el tráfico de entrada y de salida de las cargas de trabajo y se comunica con Cloud Service Mesh.

Permisos necesarios para estas tareas

Para realizar las tareas de esta página, debes tener la función roles/container.clusterAdmin o una superior. Consulta las funciones de Google Kubernetes Engine para obtener detalles sobre los permisos incluidos en esta función.

Habilita la inserción automática de sidecar

Habilita el espacio de nombres para la inserción. Los pasos dependen de tu implementación del plano de control.
Administrado (TD)
1. Aplica la etiqueta de inserción predeterminada al espacio de nombres:
```
kubectl label namespace NAMESPACE
    istio.io/rev- istio-injection=enabled --overwrite
```
Administrada (Istiod)
Recomendado: Ejecuta el siguiente comando para aplicar la etiqueta de inserción predeterminada al espacio de nombres:
```
  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite
```
Si eres un usuario existente con el plano de control de Istio administrado, te recomendamos que uses la inserción predeterminada, pero también se admite la inserción basada en revisiones. Sigue estas instrucciones:
1. Ejecuta el siguiente comando para ubicar los canales de versiones disponibles:
  kubectl -n istio-system get controlplanerevision
  El resultado es similar a este:
  NAME AGE asm-managed-rapid 6d7h
  NOTA: Si aparecen dos revisiones del plano de control en la lista anterior, quita una. No se admite tener varios canales de plano de control en el clúster.
  
  En el resultado, el valor en la columna NAME es la etiqueta de revisión que corresponde al canal de versiones disponible para la versión de Cloud Service Mesh.
2. Aplica la etiqueta de revisión al espacio de nombres:
  kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
En el clúster
Recomendado: Ejecuta el siguiente comando para aplicar la etiqueta de inserción predeterminada al espacio de nombres:
```
  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite
```
Te recomendamos que uses la inserción predeterminada, pero también se admite la inserción basada en revisiones: Usa las siguientes instrucciones:
1. Usa el siguiente comando para encontrar la etiqueta de revisión en istiod:
  kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
2. Aplica la etiqueta de revisión a los espacios de nombres. En el siguiente comando, REVISION_LABEL es el valor de la etiqueta de revisión istiod que anotaste en el paso anterior.
  kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Para reiniciar los Pods afectados, sigue los pasos de la siguiente sección.

Anota el espacio de nombres demo de la siguiente manera:

kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'

Reinicia los Pods para actualizar los proxies de sidecar

Con la inserción automática de sidecar, puedes actualizar los sidecars para pods existentes con un reinicio de pods:

La forma en la que reinicias los pods dependerá de si se crearon como parte de un objeto Deployment.

Si usaste un Deployment, debes reiniciarlo, de modo que se reinicien todos los pods con sidecars:
```
kubectl rollout restart deployment -n NAMESPACE
```
Si no usaste un Deployment, borra los pods, y se volverán a crear de forma automática con sidecars:
```
kubectl delete pod -n NAMESPACE --all
```
Verifica que todos los pods en el espacio de nombres tengan sidecars incorporados:
```
kubectl get pod -n NAMESPACE
```
En el siguiente resultado de ejemplo del comando anterior, observa que la columna READY indica que hay dos contenedores para cada una de tus cargas de trabajo: el contenedor principal y el contenedor del proxy de sidecar.
```
NAME                    READY   STATUS    RESTARTS   AGE
WORKLOAD           2/2     Running   0          20s
...
```

Integra cargas de trabajo de Kubernetes

Implementa servicios de Kubernetes

Ejemplo: Implementa la muestra de Online Boutique

Administrado (TD)

Administrada (Istiod)

En el clúster

Asigna nombres a puertos de servicio

Inserta proxies de sidecar

Permisos necesarios para estas tareas

Habilita la inserción automática de sidecar

Administrado (TD)

Administrada (Istiod)

En el clúster

Reinicia los Pods para actualizar los proxies de sidecar