Container Service for Kubernetes:Override multi-cluster alert configurations

Pré-requisitos

Antes de começar, verifique se você possui:

• O recurso de gerenciamento de Fleet ativado

• Dois clusters associados à instância do Fleet: o cluster provedor de serviços e o cluster consumidor de serviços

Como funciona

O ACK utiliza o KubeVela para definir e propagar políticas de substituição no nível do Fleet, seguindo o mesmo modelo de configuração diferenciada de aplicações. Defina um conjunto básico de regras de alerta na instância do Fleet e aplique políticas de substituição para clusters específicos.

A figura a seguir ilustra como as regras de alerta são diferenciadas entre os clusters. Uma política de substituição é criada na instância do Fleet. A configuração específica do cluster é entregue ao ACK Cluster 2, enquanto o ACK Cluster 1 mantém as regras de alerta originais.

Etapa 1: Crie um contato e um grupo de contatos

1. Crie um contato e um grupo de contatos.

2. Obtenha o ID do grupo de contatos.

3. Crie regras de alerta.

Etapa 2: Propagar regras de alerta diferenciadas

1. Obtenha os IDs dos clusters para os quais deseja propagar as regras de alerta:

   kubectl get managedcluster

   Saída esperada:

   NAME            HUB ACCEPTED   MANAGED CLUSTER URLS   JOINED   AVAILABLE   AGE
   c565e4****      true                                  True     True        12d
   cbaa12****      true                                  True     True        12d

   Nota

   Para selecionar clusters por rótulo em vez de por ID, consulte Selecione um cluster para distribuir aplicações.

2. Crie um arquivo chamado ackalertrule-app-override.yaml com o conteúdo a seguir. Neste exemplo, ack-cluster-1 é um cluster acelerado por CPU e ack-cluster-2 é um cluster acelerado por GPU. A política de substituição tem como alvo o ack-cluster-2, ativando alertas de GPU, modificando o limiar de alerta e alterando o grupo de contatos.

   apiVersion: core.oam.dev/v1alpha1  # Topology policy: routes baseline alert rules to ack-cluster-1.
   kind: Policy
   metadata:
     name: cluster-cpu
     namespace: kube-system
   type: topology
   properties:
     clusters: ["<ack-cluster-1>"] # Replace <ack-cluster-1> with the cluster ID of ack-cluster-1.
   ---
   apiVersion: core.oam.dev/v1alpha1  # Topology policy: routes overridden alert rules to ack-cluster-2.
   kind: Policy
   metadata:
     name: cluster-gpu
     namespace: kube-system
   type: topology
   properties:
     clusters: ["<ack-cluster-2>"] # Replace <ack-cluster-2> with the cluster ID of ack-cluster-2.
   ---
   apiVersion: core.oam.dev/v1alpha1  # Override policy: defines the cluster-specific changes for ack-cluster-2.
   kind: Policy
   metadata:
     name: override-gpu
     namespace: kube-system
   type: override
   properties:
     components:
     - name: ackalertrules  # Must match the component name in the Application.
       traits:
       - type: alert-rule   # The alert-rule trait modifies alert rules on the target cluster.
         properties:
           groups:           # Override configurations. The structure mirrors that of the alert rules.
           - name: res-exceptions      # Name of the alert group to override.
             rules:
             - contactGroups:           # Override the contact group.
               - arms_contact_group_id: "12345"
                 cms_contact_group_name: ack_Default Contact Group
                 id: "1234"
               enable: enable           # Set to enable.
               name: node_cpu_util_high # Name of the alert rule to override.
               thresholds:              # Override the alert threshold.
               - key: CMS_ESCALATIONS_CRITICAL_Threshold
                 unit: percent
                 value: "60"
           - name: cluster-error    # Name of the alert group to override.
             rules:
             - enable: enable       # Set to enable.
               name: gpu-xid-error  # Name of the alert rule to override.
   ---
   apiVersion: core.oam.dev/v1alpha1  # Workflow: defines the deployment steps.
   kind: Workflow
   metadata:
     name: deploy-ackalertrules
     namespace: kube-system
   steps:
     - type: deploy
       name: deploy-cpu
       properties:
         policies: ["cluster-cpu"]   # Deploy baseline alert rules to ack-cluster-1.
     - type: deploy
       name: deploy-gpu
       properties:
         policies: ["override-gpu", "cluster-gpu"]  # Apply the override policy and deploy to ack-cluster-2.
   ---
   apiVersion: core.oam.dev/v1beta1   # Application: the top-level KubeVela resource.
   kind: Application
   metadata:
     name: alertrules
     namespace: kube-system
     annotations:
       app.oam.dev/publishVersion: version1  # Increment this value each time you update the alert rules to trigger re-propagation.
   spec:
     components:
       - name: ackalertrules
         type: ref-objects
         properties:
           objects:
             - resource: ackalertrules    # References the alert rules created in Step 3.
               name: default
     workflow:
       ref: deploy-ackalertrules

3. Aplique a política de substituição:

   kubectl apply -f ackalertrule-app-override.yaml

4. Verifique o status da propagação:

   kubectl amc appstatus alertrules -n kube-system --tree --detail

   Saída esperada:

   CLUSTER                       NAMESPACE       RESOURCE             STATUS    APPLY_TIME          DETAIL
   c565e4**** (ack-cluster-1)─── kube-system─── AckAlertRule/default updated   2022-**-** **:**:** Age: **
   cbaa12**** (ack-cluster-2)─── kube-system─── AckAlertRule/default updated   2022-**-** **:**:** Age: **

   Ambos os clusters exibem updated, confirmando que a política de substituição foi aplicada e as regras de alerta diferenciadas foram propagadas com sucesso.