Actualizar Apigee Hybrid a la versión 1.3.6

Actualiza a la versión de la descripción general 1.3.6.

Los procedimientos para actualizar Apigee Hybrid se organizan en las siguientes secciones:

Preparación

Crea y actualiza cuentas de servicio
Planifica los grupos de entornos.
Copia y actualiza el archivo de anulación.

Actualiza Istio y cert-manager.
Instala la versión 1.3 del entorno de ejecución híbrido.
Realiza una limpieza.

Requisitos

Apigee Hybrid versión 1.2. Si estás actualizando desde una versión anterior, consulta las instrucciones para actualizar Apigee Hybrid a la versión 1.2.

Preparación

Realiza una copia de seguridad de tu directorio $APIGEECTL_HOME/ versión 1.2. Por ejemplo:
```
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.2-backup.tar.gz $APIGEECTL_HOME
```
(Recomendado) Realiza una copia de seguridad de tu base de datos de Cassandra según las instrucciones que se indican en Copia de seguridad y recuperación de Cassandra.

Actualiza tu plataforma de Kubernetes de la siguiente manera. Si necesitas ayuda, sigue la documentación de la plataforma:

Plataforma	Actualizar a la versión
GKE	1.15.x
Anthos	1.5
AKS	1.16.x mediante clústeres conectados de Anthos

Si no usas Apigee Connect en tu instalación híbrida, habilita Apigee Connect.
1. Verifica si la API de Apigee Connect ya está habilitada:
```
gcloud services list | grep apigeeconnect

apigeeconnect.googleapis.com         Apigee Connect API
```
2. Si no es así, habilita la API:
```
gcloud services enable apigeeconnect.googleapis.com --project $PROJECT_ID
```
  En el ejemplo anterior, PROJECT_ID es el ID del proyecto de Google Cloud.
3. En la línea de comandos, obtén tus credenciales de autenticación de gcloud, como se muestra en el siguiente ejemplo:
```
TOKEN=$(gcloud auth print-access-token)
```
  Para verificar que tu token se haya propagado, usa echo, como se muestra en el siguiente ejemplo:
```
echo $TOKEN
```
  Se debería mostrar tu token como una string codificada.
  
  Para obtener más información, consulta la descripción general de la herramienta de línea de comandos de gcloud.
4. Verifica si Apigee Connect está habilitado para tu organización:
```
curl -H "Authorization: Bearer $TOKEN" \
  "https://apigee.googleapis.com/v1/organizations/$ORG_NAME"
```
  En este comando, $ORG_NAME es el ID de tu organización.
  Si el resultado contiene esta información:
```
      "name" : "features.mart.connect.enabled",
      "value" : "true"
```
  Apigee Connect está habilitado.
5. Si Apigee Connect no está habilitado, asigna la función de Agente de Apigee Connect a la cuenta de servicio MART:
```
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member serviceAccount:apigee-mart@$PROJECT_ID.iam.gserviceaccount.com \
  --role roles/apigeeconnect.Agent
```
  Sugerencia: Si necesitas obtener la dirección de correo electrónico de tu cuenta de servicio MART, ejecuta el siguiente comando:
```
gcloud iam service-accounts list | grep mart
```
6. Habilita Apigee Connect con el siguiente comando:
```
curl -H "Authorization: Bearer $TOKEN" -X PUT \
  -H "Content-Type: application/json" \
  -d '{
    "name" : "'"$ORG_NAME"'",
    "properties" : {
      "property" : [ {
        "name" : "features.hybrid.enabled",
        "value" : "true"
      }, {
        "name" : "features.mart.connect.enabled",
        "value" : "true"
      } ]
    }
  }' \
  "https://apigee.googleapis.com/v1/organizations/$ORG_NAME"
```
  Si el resultado contiene las dos propiedades siguientes, Apigee Connect se habilitó correctamente:
```
      {
        "name": "features.mart.connect.enabled",
        "value": "true"
      },
      {
        "name": "features.hybrid.enabled",
        "value": "true"
      }
```
Crea la cuenta de servicio apigee-watcher. Apigee Watcher es una cuenta de servicio nueva que se introdujo en la versión 1.3. Esta vigila el sincronizador para ver los cambios a nivel de la organización y los aplica a fin de configurar la entrada de Istio.
Desde tu directorio híbrido principal, haz lo siguiente:
```
./tools/create-service-account apigee-watcher ./service-accounts
```
Asigna la función de Agente de entorno de ejecución de Apigee a la cuenta de servicio de Watcher:
```
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member serviceAccount:apigee-watcher@$PROJECT_ID.iam.gserviceaccount.com \
  --role roles/apigee.runtimeAgent
```
En el ejemplo anterior, PROJECT_ID es el ID del proyecto de Google Cloud. Si las direcciones de correo electrónico de tu cuenta de servicio difieren de este patrón, reemplázalas según corresponda.
Sugerencia: Si necesitas obtener la dirección de correo electrónico de tu cuenta de servicio, ejecuta el siguiente comando:
```
gcloud iam service-accounts list | grep watcher
```
El resultado debe incluir una lista de todas las cuentas de servicio y sus funciones, incluidas las siguientes opciones:
```
  ...
- members:
  - serviceAccount:apigee-watcher@hybrid13rc5.iam.gserviceaccount.com
  role: roles/apigee.runtimeAgent
  ...
```
Planifica los grupos de entornos para el enrutamiento. Apigee Hybrid 1.3 administra el enrutamiento de la ruta base con grupos de entornos en lugar de routingRules. Si usas routingRules en la configuración híbrida, diseña grupos de entornos para replicar el enrutamiento.
Debes crear al menos un grupo de entorno.

Consulta Información sobre los grupos de entornos.
Haz clic a fin de ver un ejemplo de cómo usar grupos de entornos para reemplazar routingRules

En este ejemplo, el siguiente routingRules en la ruta de acceso del archivo overrides.yaml solicita a los proxies de API foo y bar en el entorno prod-env-1, y el proxy foo-test en el entorno test-env:
```
virtualhosts:
  - name: default
    hostAliases:
      - "*.acme.com"
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key
    routingRules:
      - paths:
        - /foo
        - /bar
      - env: prod-env-1
      - paths:
        - foo-test
      -env: test-env
```
Para duplicar eso en la versión híbrida 1.3.6, haz lo siguiente:
1. Implementa los proxies foo y bar en el entorno prod-env-1.
2. Implementa los proxies foo-test y bar en el entorno test-env.
3. Crea un grupo de entorno con un alias de host para los proxies, como api.acme.com.
  Sugerencia: Crea un grupo de entorno con el mismo nombre que el de hosts virtuales que usaste en la versión 1.2.
4. Revisa la estrofa virtualhosts en overrides.yaml para lo siguiente
  - Reemplaza virtualhosts:name por el nombre del grupo de entorno.
  - Quita el virtualhosts:routingRules.
  Por ejemplo:
```
virtualhosts:
  - name: default # environment group name
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key
```
Actualiza tu archivo de anulación como sigue:

Haz una copia del archivo de anulación.

Actualiza las estrofas gcp y k8sCluster.

Las siguientes propiedades de configuración se reemplazaron en la versión híbrida 1.3:

Se reemplazó gcpRegion por gcp:region
Se reemplazó gcpProjectID por gcp:projectID
Se reemplazó gcpProjectIDRuntime por gcp:gcpProjectIDRuntime
Se reemplazó k8sClusterName por k8s:clusterName
Se reemplazó k8sClusterRegion por k8s:clusterRegion

Por ejemplo, reemplaza la siguiente estructura:

gcpRegion: gcp region
gcpProjectID: gcp project ID
gcpProjectIDRuntime: gcp project ID

k8sClusterName: name
k8sClusterRegion: region

con:

gcp:
 projectID: gcp project ID
 region: gcp region
 gcpProjectIDRuntime: gcp project ID # optional. This is only required if you
                                       # want logger/metrics data to be sent in
                                       # different gcp project.

k8sCluster:
 name: gcp project ID
 region: gcp region

Si no tienes un identificador de instancia único en tu archivo de anulación, agrega uno:
```
# unique identifier for this installation. 63 chars length limit
instanceID: ID
```
En el ejemplo anterior, ID es un identificador único para esta instalación híbrida, como “my-hybrid-131-installation” o “acmecorp-hybrid-131”.

Agrega la cuenta de servicio de Watcher (apigee-watcher) al archivo de anulaciones:

# Note: the SA should have the "Apigee Runtime Agent" role
watcher:
 serviceAccountPath: "service account file"

Agrega la cuenta de servicio Metrics (apigee-metrics) al archivo de anulaciones:
```
metrics:
 serviceAccountPath: "service account file"
```
Actualiza la estrofa virtualhosts: para reemplazar routingRules por tu grupo de entorno.
1. -name: Reemplaza el nombre por el nombre de tu grupo de entorno. Puedes tener varias entradas de nombre, una para cada grupo de entorno.
2. hostAliases:[] Borra esta línea.
3. Conserva (o agrega) las entradas sslCertPath: y sslKeyPath:.
4. Borra todas las entradas routingRules
Por ejemplo:
```
virtualhosts:
  - name: default
    hostAliases:
      - "*.acme.com"
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key
    routingRules:
      - paths:
        - /foo
        - /bar
      - env: my-environment
```
Se convierte en:
```
virtualhosts:
  - name: example-env-group
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key
```
Actualiza las estrofas de mart y connectAgent:.
Nota: Si no planeas usar Apigee Connect en tu instalación híbrida 1.3, omite este paso y sigue la Sugerencia en el paso 5 en Apigee Connect después de la actualización.
1. En mart:, quita las entradas hostAlias:, sslCertPath: y sslKeyPath:.
2. Agrega una estrofa connectAgent:.
3. En connectAgent:, agrega una entrada serviceAccountPath: y proporciona la ruta al archivo de recuento de servicios que tiene asignada la función de Agente de Apigee Connect (generalmente, la cuenta de servicio MART).
Por ejemplo:
```
mart:
  hostAlias: "mart.apigee-hybrid-docs.net"
  serviceAccountPath: ./service-accounts/hybrid-project-apigee-mart.json
  sslCertPath: ./certs/fullchain.pem
  sslKeyPath: ./certs/privkey.key
```
Se convierte en:
```
mart:
  serviceAccountPath: ./service-accounts/hybrid-project-apigee-mart.json

connectAgent:
  serviceAccountPath: ./service-accounts/hybrid-project-apigee-mart.json
```

Actualiza Istio y cert-manager

La versión 1.3 de Apigee Hybrid requiere que cert-manager v0.14.2 para administrar y verificar certificados, y la distribución de Istio proporcionada con Anthos Service Mesh (ASM) versión 1.5.7 (o posterior) para crear y administrar la puerta de enlace de entrada del entorno de ejecución.

Actualiza Istio 1.4.6 a ASM 1.5.7 (o posterior)

Para minimizar el tiempo de inactividad, las implementaciones de Istio y los HPA deben tener al menos dos réplicas. Ejecuta los siguientes comandos para determinar la cantidad de réplicas:
```
kubectl -n istio-system get deployments # list of deployments
kubectl -n istio-system get hpa # list of hpa
```
Edita cada implementación que tiene solo una réplica y aumenta el replicas: a 2 o más:
```
kubectl -n istio-system edit deployment name
```
Por ejemplo:
```
spec:
  progressDeadlineSeconds: 600
  replicas: 2
```
Edita cada HPA que tenga solo una réplica y aumenta el minReplicas: a 2 o más:
```
kubectl -n istio-system edit hpa name
```
Por ejemplo:
```
spec:
  maxReplicas: 5
  minReplicas: 2
```
Descarga y, luego, instala ASM según las instrucciones de instalación que se indican en Descarga e instala ASM.

Después de la instalación, ejecuta el comando de versión para asegurarte de que tengas la versión 1.5.x instalada correctamente:

./bin/istioctl version

client version: 1.5.8-asm.0
apigee-mart-ingressgateway version:
citadel version: 1.4.6
galley version: 1.4.6
ingressgateway version: 1.5.8-asm.0
pilot version: 1.4.6
policy version: 1.4.6
sidecar-injector version: 1.4.6
telemetry version: 1.4.6
pilot version: 1.5.8-asm.0
data plane version: 1.4.6 (1 proxies), 1.5.8-asm.0 (2 proxies)

Actualiza cert-manager

Borra la implementación cert-manager actual:

kubectl delete -n cert-manager deployment cert-manager cert-manager-cainjector cert-manager-webhook

Verifica tu versión de Kubernetes:
```
kubectl version
```

Ejecuta el siguiente comando para instalar cert-manager desde Jetstack:

kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.14.2/cert-manager.yaml

Instala el entorno de ejecución híbrido

Almacena el número de versión más reciente en una variable:

export VERSION=$(curl -s \
    https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/current-version.txt?ignoreCache=1)

Verifica que la variable se propagó con un número de versión. Si deseas usar una versión diferente, puedes guardarla en la variable de entorno en su lugar. Por ejemplo:
```
echo $VERSION
  1.3.6
```

Descarga el paquete de actualización para tu sistema operativo:

Mac (64 bits)

curl -LO \
    https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/$VERSION/apigeectl_mac_64.tar.gz

Linux de 64 bits

curl -LO \
    https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/$VERSION/apigeectl_linux_64.tar.gz

Mac de 32 bits:

curl -LO \
    https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/$VERSION/apigeectl_mac_32.tar.gz

Linux de 32 bits

curl -LO \
    https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/$VERSION/apigeectl_linux_32.tar.gz

Cambia el nombre de tu directorio apigeectl/ actual por un nombre de directorio de copia de seguridad. Por ejemplo:
```
mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.2/ 
```
Extrae el contenido del archivo gzip descargado en tu directorio base híbrido. Por ejemplo:
```
tar xvzf filename.tar.gz -C hybrid-base-directory
```
cd al directorio base.
De forma predeterminada, los contenidos del archivo tar se expanden a un directorio con la versión y la plataforma en su nombre. Por ejemplo: ./apigeectl_1.0.0-f7b96a8_linux_64. Cambia el nombre de ese directorio a apigeectl:
```
mv apigeectl_1.0.0-f7b96a8_linux_64 apigeectl
```

Borra el trabajo apigee-resources-install de apigee-system:

kubectl -n apigee-system delete job apigee-resources-install

Borra el CRD más antiguo:

kubectl delete crd apigeetelemetries.apigee.cloud.google.com

Actualiza la estrofa cassandra: de tu archivo de anulaciones con una propiedad externalSeedHost. Esta propiedad ayudará a garantizar que la instalación nueva de la versión híbrida 1.3.6 use el mismo clúster de Kubernetes que la instalación de la versión 1.2. Este es un paso único necesario solo para la actualización de la versión híbrida 1.2 a la versión 1.3.6 (o posterior).
1. Busca una de las direcciones IP de Cassandra existentes en el mismo clúster de Kubernetes en el que actualizas la instalación 1.2.0.
```
kubectl -n namespace get pods -o wide
```
  En el ejemplo anterior, namespace es el espacio de nombres híbrido de Apigee.
  
  Toma nota de la dirección IP de un nodo de Cassandra. Por ejemplo:
```
kubectl -n apigee get pods -o wide
NAME                  READY   STATUS    RESTARTS   AGE   IP          NODE
apigee-cassandra-0    1/1     Running   0          33d   10.68.8.24   gke-example-cluster-rc5-apigee-data-c8bf1234-09kc
apigee-cassandra-1    1/1     Running   0          16d   10.68.8.33   gke-example-cluster-rc5-apigee-data-c9221ee7-10kc
apigee-cassandra-2    1/1     Running   0          23h   10.68.9.11   gke-example-cluster-rc5-apigee-data-d123e456-11kc
```
2. Agrega el valor de la propiedad externalSeedHost:
```
cassandra:
 externalSeedHost: Cassandra_node_IP
```
  En el ejemplo anterior, Cassandra_node_IP es la IP del nodo de Cassandra (10.68.8.24 en el ejemplo anterior).
  Nota: Quitarás la propiedad externalSeedHost en un paso posterior después de que tu Cassandra nueva esté en ejecución y verificada.
En el directorio nuevo apigeectl/, ejecuta apigeectl init, apigeectl apply y apigeectl check-ready:
1. Inicializa la versión Hybrid 1.3.6:
```
apigeectl init -f overrides_1.3.yaml
```
  En el ejemplo anterior, overrides_1.3.yaml es tu archivo overrides.yaml editado.
2. En la versión 1.3 híbrida, la sintaxis de la marca --dry-run depende de la versión de kubectl que ejecutes. Verifica la versión de kubectl:
```
gcloud version
```
3. Verifica si hay errores con una ejecución de prueba:
  versión 1.17 de kubectl y versiones anteriores:
```
apigeectl apply -f overrides_1.3.yaml --dry-run=true
```
  versión 1.18 kubectl y versiones posteriores:
```
apigeectl apply -f overrides_1.3.yaml --dry-run=client
```
4. Aplica tus anulaciones. Selecciona y sigue las instrucciones para los entornos de producción o entornos de demostración/experimental, según la instalación.
  Durante el proceso de actualización, cada componente realizará un reinicio progresivo. Por lo tanto, para los entornos de producción, es mejor aplicar la actualización a un componente a la vez.
  Producción
  
  En los entornos de producción, debes actualizar cada componente híbrido de forma individual y verificar el estado del componente actualizado antes de continuar con el siguiente.
  1. Aplica tus anulaciones para actualizar Cassandra:
    apigeectl apply -f overrides_1.3.yaml --datastore
  2. Verifica la finalización:
    kubectl -n namespace get pods
    
    En el ejemplo anterior, namespace es el espacio de nombres híbrido de Apigee.
    
    Continúa con el siguiente paso solo cuando los Pods estén listos.
  3. Aplica tus anulaciones para actualizar los componentes de telemetría y verificar la finalización:
    apigeectl apply -f overrides_1.3.yaml --telemetry
    
    kubectl -n namespace get pods
  4. Aplica tus anulaciones para actualizar los componentes a nivel de la organización (MART, Watcher y Apigee Connect) y verifica la finalización:
    apigeectl apply -f overrides_1.3.yaml --org
    
    kubectl -n namespace get pods
  5. Aplica tus anulaciones para actualizar tus entornos. Tienes dos opciones:
    
    Aplica tus anulaciones a un entorno a la vez y verificar la finalización. Repite este paso para cada entorno:
    apigeectl apply -f overrides_1.3.yaml --env env_name
    
    kubectl -n namespace get pods
    
    En el comando anterior, env_name es el nombre del entorno que estás actualizando.
    
    Aplica tus anulaciones a todos los entornos a la vez y verifica que se completen:
    apigeectl apply -f overrides_1.3.yaml --all-envs
    
    kubectl -n namespace get pods
  Demostración/Experimental
  
  En la mayoría de los entornos experimentales o de demostración, puedes aplicar las anulaciones a todos los componentes a la vez. Si tu entorno de demostración/experimental es grande y complejo, o si imita de manera estrecha a un entorno de producción, puedes usar las instrucciones para actualizar los entornos de producción.
  1. apigeectl apply -f overrides_1.3.yaml
  2. Verifica el estado:
    apigeectl check-ready -f overrides_1.3.yaml
  Para obtener más instrucciones, consulta Configuración híbrida de GKE: Paso 5: Instala el híbrido en GKE.
5. Una vez que tengas la configuración híbrida de 1.3 en funcionamiento, verifica que todos los nodos de Cassandra (antiguos y nuevos) formen parte del mismo clúster de Cassandra. Ejecuta el siguiente comando en uno de los nodos de Cassandra:
```
kubectl -n namespace get pods
kubectl -n namespace exec old Cassandra pod -- nodetool status
```
  En el siguiente resultado de ejemplo, 10.68.8.24 es de la versión 1.2.0 y es la IP de nodo que usaste como externalSeedHost. 10.68.7.11 corresponde a la versión 1.3.6:
```
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load        Tokens       Owns (effective)  Host ID                               Rack
UN  10.68.8.24  379.41 KiB  256          50.8%             11bbd43b-af64-464b-a96d-0d6dd0521de1  ra-1
UN  10.68.7.11  1.35 MiB    256          49.2%             0b4d9e08-f353-413a-b4a9-7d18a8d07e58  ra-1
```
  Si no están en el mismo clúster, verifica el valor externalSeedHost.
6. Una vez que todos los pods estén en funcionamiento, quita externalSeedHost del archivo de anulaciones y vuelve a ejecutar apigeectl apply con la opción --datastore:
```
apigeectl apply --datastore -f overrides_1.3.6.yaml
```
Limpia

Una vez que verificaste que todos los pods están en buen estado y que los extremos ASM son válidos para la instalación nueva, puedes realizar una limpieza:
- Recursos 1.2 híbridos
- La instancia anterior de Cassandra
- Recursos 1.4.6 de Istio.
Borra recursos híbridos 1.2.0
Nota: Este procedimiento requiere el comando apigeectl versión 1.2 en tu directorio de copia de seguridad. Si necesitas descargar otra copia de la versión 1.2 de apigeectl, puedes usar el siguiente comando:
```
curl -LO \
    https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/1.2.0/apigeectl_your_system.tar.gz
```
En el ejemplo anterior, your_system es linux_32, linux_64, mac_32 o mac_64.
1. Quita los detalles de enrutamiento del host virtual 1.2.0:
```
$APIGEECTL_HOME-v1.2/apigeectl delete -s virtualhost -f 1.2.0_overrides.yaml
```
  En el ejemplo anterior, $APIGEECTL_HOME-v1.2 es el directorio en el que creaste una copia de seguridad de tu directorio apigeectl versión 1.2.
2. Si el extremo aún funciona según lo esperado y verificaste que todos los componentes de 1.3.0 funcionan, ejecuta el siguiente comando para borrar los recursos híbridos de 1.2.0:
```
$APIGEECTL_HOME-v1.2/apigeectl delete -c "mart,connect-agent,synchronizer,runtime,udca,metrics,logger" \
  -f 1.2.0_overrides.yaml
```
Retira la instancia de Cassandra más antigua
1. cd en el directorio apigeectl recién instalado
2. Ejecuta la secuencia de comandos tools/cas_cleanup.sh:
  Esta secuencia de comandos retira el antiguo Pod de Cassandra del anillo de Cassandra, borra el STS viejo y borra las PVC.
```
bash cas_cleanup.sh Apigee namespace
```
Borra recursos de la versión 1.4.6 de Istio

Nota: Si borras los recursos de Istio versión 1.4.6, también se borrará la entrada de MART. La entrada de MART se reemplaza por Apigee Connect en la versión híbrida 1.3 de Apigee.
1. Ejecute el siguiente comando para borrar los recursos de Istio v.1.4.6 más recientes:
```
kubectl delete all -n istio-system --selector \
  'app in (apigee-mart-istio-ingressgateway, galley, security, istio-nodeagent, istio-mixer, sidecarInjectorWebhook, istio-mixer)'
```
2. Ejecuta los siguientes comandos para borrar trabajos anteriores de la instalación de Istio 1.4.6:
```
kubectl -n istio-system delete job istio-init-crd-10-1.4.6
kubectl -n istio-system delete job istio-init-crd-11-1.4.6
kubectl -n istio-system delete job istio-init-crd-14-1.4.6
```
¡Felicitaciones! Actualizaste correctamente a la versión 1.3.6 de Apigee Hybrid.

Actualizar Apigee Hybrid a la versión 1.3.6

Actualiza a la versión de la descripción general 1.3.6.

Requisitos

Preparación

Haz clic a fin de ver un ejemplo de cómo usar grupos de entornos para reemplazar routingRules

Actualiza Istio y cert-manager

Actualiza Istio 1.4.6 a ASM 1.5.7 (o posterior)

Actualiza cert-manager

Instala el entorno de ejecución híbrido

Producción

Demostración/Experimental

Limpia

Borra recursos híbridos 1.2.0

Retira la instancia de Cassandra más antigua

Borra recursos de la versión 1.4.6 de Istio

Haz clic a fin de ver un ejemplo de cómo usar grupos de entornos para reemplazar `routingRules`