Le réseautage

Procédure

1. Change managementState to Ungaged dans l’opérateur DNS:

   oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'

   Copy to Clipboard Toggle word wrap

2. État de l’opérateur DNS utilisant la ligne de commande jsonpath JSON parser:

   $ oc get dns.operator.openshift.io default -ojsonpath='{.spec.managementState}'

   Copy to Clipboard Toggle word wrap

   Exemple de sortie

   "Unmanaged"

   Copy to Clipboard Toggle word wrap

Procédure

1. La modification de l’objet DNS Operator nommé par défaut:

   $ oc edit dns.operator/default

   Copy to Clipboard Toggle word wrap

   Les administrateurs de clusters peuvent configurer la sécurité des couches de transport (TLS) pour les requêtes DNS transmises.

   Configuration du transfert DNS avec TLS

   apiVersion: operator.openshift.io/v1
   kind: DNS
   metadata:
     name: default
   spec:
     servers:
     - name: example-server 

   1

   
       zones:
       - example.com 

   2

   
       forwardPlugin:
         transportConfig:
           transport: TLS 

   3

   
           tls:
             caBundle:
               name: mycacert
             serverName: dnstls.example.com  

   4

   
         policy: Random 

   5

   
         upstreams: 

   6

   
         - 1.1.1.1
         - 2.2.2.2:5353
     upstreamResolvers: 

   7

   
       transportConfig:
         transport: TLS
         tls:
           caBundle:
             name: mycacert
           serverName: dnstls.example.com
       upstreams:
       - type: Network 

   8

   
         address: 1.2.3.4 

   9

   
         port: 53 

   10

   Copy to Clipboard Toggle word wrap

   1

   Doit se conformer à la syntaxe du nom de service rfc6335.

   2

   Doit être conforme à la définition d’un sous-domaine dans la syntaxe du nom de service rfc1123. Le domaine cluster, cluster.local, est un sous-domaine invalide pour le champ zones. Le domaine cluster, cluster.local, est un sous-domaine invalide pour les zones.

   3

   Lorsque vous configurez TLS pour les requêtes DNS transmises, définissez le champ de transport pour avoir la valeur TLS.

   4

   Lors de la configuration de TLS pour les requêtes DNS transmises, il s’agit d’un nom de serveur obligatoire utilisé dans le cadre de l’indication de nom de serveur (SNI) pour valider le certificat de serveur TLS en amont.

   5

   Définit la stratégie pour sélectionner les résolveurs en amont. La valeur par défaut est aléatoire. Il est également possible d’utiliser les valeurs RoundRobin et Sequential.

   6

   C’est nécessaire. L’utiliser pour fournir des résolveurs en amont. Au maximum 15 entrées en amont sont autorisées par entrée forwardPlugin.

   7

   En option. Il peut être utilisé pour remplacer la stratégie par défaut et transférer la résolution DNS vers les résolveurs DNS spécifiés (résolutionurs en amont) pour le domaine par défaut. Dans le cas où vous ne fournissez pas de résolveurs en amont, les requêtes de nom DNS vont aux serveurs de /etc/resolv.conf.

   8

   Le type réseau est uniquement autorisé lors de l’utilisation de TLS et vous devez fournir une adresse IP. Le type de réseau indique que ce résolveur en amont doit gérer les demandes transmises séparément des résolveurs en amont listés dans /etc/resolv.conf.

   9

   Le champ d’adresse doit être une adresse IPv4 ou IPv6 valide.

   10

   En option, vous pouvez fournir un port. Le port doit avoir une valeur comprise entre 1 et 65535. Dans le cas où vous ne spécifiez pas un port pour l’amont, le port par défaut est 853.

   Note

   Lorsque les serveurs sont indéfinis ou invalides, la carte de configuration ne contient que le serveur par défaut.

La vérification

1. Afficher la carte de configuration:

   $ oc get configmap/dns-default -n openshift-dns -o yaml

   Copy to Clipboard Toggle word wrap

   Exemple de DNS ConfigMap basé sur l’exemple de transfert TLS

   apiVersion: v1
   data:
     Corefile: |
       example.com:5353 {
           forward . 1.1.1.1 2.2.2.2:5353
       }
       bar.com:5353 example.com:5353 {
           forward . 3.3.3.3 4.4.4.4:5454 

   1

   
       }
       .:5353 {
           errors
           health
           kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods insecure
               upstream
               fallthrough in-addr.arpa ip6.arpa
           }
           prometheus :9153
           forward . /etc/resolv.conf 1.2.3.4:53 {
               policy Random
           }
           cache 30
           reload
       }
   kind: ConfigMap
   metadata:
     labels:
       dns.operator.openshift.io/owning-dns: default
     name: dns-default
     namespace: openshift-dns

   Copy to Clipboard Toggle word wrap

   1

   Les modifications apportées à forwardPlugin déclenchent une mise à jour continue du jeu de démon CoreDNS.

1. Créez une ressource Secret contenant le certificat personnalisé dans l’espace de noms openshift-ingress à l’aide des fichiers tls.crt et tls.key.

   $ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key

   Copy to Clipboard Toggle word wrap

2. Actualisez l’IngressController CR pour faire référence au nouveau secret de certificat:

   $ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
     --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'

   Copy to Clipboard Toggle word wrap

3. La mise à jour a été efficace:

   $ echo Q |\
     openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\
     openssl x509 -noout -subject -issuer -enddate

   Copy to Clipboard Toggle word wrap

   là où:

   <domaine>

   Indique le nom de domaine de base de votre cluster.

   Exemple de sortie

   subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com
   issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com
   notAfter=May 10 08:32:45 2022 GM

   Copy to Clipboard Toggle word wrap

   Astuce

   Alternativement, vous pouvez appliquer le YAML suivant pour définir un certificat par défaut personnalisé:

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: default
     namespace: openshift-ingress-operator
   spec:
     defaultCertificate:
       name: custom-certs-default

   Copy to Clipboard Toggle word wrap

   Le nom secret du certificat doit correspondre à la valeur utilisée pour mettre à jour le CR.

Procédure

1. Créez un compte de service à authentifier avec Thanos en exécutant la commande suivante:

   $ oc create -n openshift-ingress-operator serviceaccount thanos && oc describe -n openshift-ingress-operator serviceaccount thanos

   Copy to Clipboard Toggle word wrap

   Exemple de sortie

   Name:                thanos
   Namespace:           openshift-ingress-operator
   Labels:              <none>
   Annotations:         <none>
   Image pull secrets:  thanos-dockercfg-kfvf2
   Mountable secrets:   thanos-dockercfg-kfvf2
   Tokens:              <none>
   Events:              <none>

   Copy to Clipboard Toggle word wrap

2. Créez manuellement le jeton secret de compte de service avec la commande suivante:

   $ oc apply -f - <<EOF
   apiVersion: v1
   kind: Secret
   metadata:
     name: thanos-token
     namespace: openshift-ingress-operator
     annotations:
       kubernetes.io/service-account.name: thanos
   type: kubernetes.io/service-account-token
   EOF

   Copy to Clipboard Toggle word wrap

3. Définissez un objet TriggerAuthentication dans l’espace de noms openshift-ingress-operator en utilisant le jeton du compte de service.

   1. Créez l’objet TriggerAuthentication et passez la valeur de la variable secrète au paramètre TOKEN:

      $ oc apply -f - <<EOF
      apiVersion: keda.sh/v1alpha1
      kind: TriggerAuthentication
      metadata:
        name: keda-trigger-auth-prometheus
        namespace: openshift-ingress-operator
      spec:
        secretTargetRef:
        - parameter: bearerToken
          name: thanos-token
          key: token
        - parameter: ca
          name: thanos-token
          key: ca.crt
      EOF

      Copy to Clipboard Toggle word wrap

4. Créer et appliquer un rôle pour la lecture des métriques à partir de Thanos:

   1. Créez un nouveau rôle, thanos-metrics-reader.yaml, qui lit des métriques à partir de pods et de nœuds:

      à propos de Thanos-metrics-reader.yaml

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: thanos-metrics-reader
        namespace: openshift-ingress-operator
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        - nodes
        verbs:
        - get
      - apiGroups:
        - metrics.k8s.io
        resources:
        - pods
        - nodes
        verbs:
        - get
        - list
        - watch
      - apiGroups:
        - ""
        resources:
        - namespaces
        verbs:
        - get

      Copy to Clipboard Toggle word wrap

   2. Appliquez le nouveau rôle en exécutant la commande suivante:

      $ oc apply -f thanos-metrics-reader.yaml

      Copy to Clipboard Toggle word wrap

5. Ajoutez le nouveau rôle au compte de service en entrant les commandes suivantes:

   $ oc adm policy -n openshift-ingress-operator add-role-to-user thanos-metrics-reader -z thanos --role-namespace=openshift-ingress-operator

   Copy to Clipboard Toggle word wrap

   $ oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanos

   Copy to Clipboard Toggle word wrap
   Note

   L’argument add-cluster-role-to-user n’est requis que si vous utilisez des requêtes cross-namespace. L’étape suivante utilise une requête de l’espace de noms kube-metrics qui nécessite cet argument.

6. Créez un nouveau fichier ScaledObject YAML, ingress-autoscaler.yaml, qui cible le déploiement par défaut du contrôleur Ingress:

   Exemple ScaledObject Définition

   apiVersion: keda.sh/v1alpha1
   kind: ScaledObject
   metadata:
     name: ingress-scaler
     namespace: openshift-ingress-operator
   spec:
     scaleTargetRef: 

   1

   
       apiVersion: operator.openshift.io/v1
       kind: IngressController
       name: default
       envSourceContainerName: ingress-operator
     minReplicaCount: 1
     maxReplicaCount: 20 

   2

   
     cooldownPeriod: 1
     pollingInterval: 1
     triggers:
     - type: prometheus
       metricType: AverageValue
       metadata:
         serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 

   3

   
         namespace: openshift-ingress-operator 

   4

   
         metricName: 'kube-node-role'
         threshold: '1'
         query: 'sum(kube_node_role{role="worker",service="kube-state-metrics"})' 

   5

   
         authModes: "bearer"
       authenticationRef:
         name: keda-trigger-auth-prometheus

   Copy to Clipboard Toggle word wrap

   1

   La ressource personnalisée que vous ciblez. Dans ce cas, le contrôleur Ingress.

   2

   Facultatif: Le nombre maximum de répliques. En cas d’omission de ce champ, le maximum par défaut est défini à 100 répliques.

   3

   Le point d’extrémité du service Thanos dans l’espace de noms de surveillance openshift.

   4

   L’espace de noms Ingress Operator.

   5

   Cette expression évalue cependant de nombreux nœuds de travail sont présents dans le cluster déployé.

   Important

   Lorsque vous utilisez des requêtes cross-namespace, vous devez cibler le port 9091 et non le port 9092 dans le champ serverAddress. Il faut aussi avoir des privilèges élevés pour lire les métriques à partir de ce port.

7. Appliquez la définition de ressource personnalisée en exécutant la commande suivante:

   $ oc apply -f ingress-autoscaler.yaml

   Copy to Clipboard Toggle word wrap

Procédure

1. Afficher le nombre actuel de répliques disponibles pour le logiciel IngressController par défaut:

   $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

   Copy to Clipboard Toggle word wrap

   Exemple de sortie

   2

   Copy to Clipboard Toggle word wrap

2. Adaptez le logiciel IngressController par défaut au nombre de répliques souhaité à l’aide de la commande oc patch. L’exemple suivant met à l’échelle le IngressController par défaut à 3 répliques:

   $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge

   Copy to Clipboard Toggle word wrap

   Exemple de sortie

   ingresscontroller.operator.openshift.io/default patched

   Copy to Clipboard Toggle word wrap

3. Assurez-vous que l’IngreressController par défaut a mis à l’échelle le nombre de répliques que vous avez spécifiées:

   $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

   Copy to Clipboard Toggle word wrap

   Exemple de sortie

   3

   Copy to Clipboard Toggle word wrap

   Astuce

   Alternativement, vous pouvez appliquer le YAML suivant pour mettre à l’échelle un contrôleur Ingress en trois répliques:

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: default
     namespace: openshift-ingress-operator
   spec:
     replicas: 3               

   1

   Copy to Clipboard Toggle word wrap

   1

   Lorsque vous avez besoin d’une quantité différente de répliques, modifiez la valeur des répliques.

Procédure

1. Créez une ressource personnalisée IngressController (CR) dans un fichier nommé <name>-ingress-controller.yaml, comme dans l’exemple suivant:

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     namespace: openshift-ingress-operator
     name: <name> 

   1

   
   spec:
     domain: <domain> 

   2

   
     endpointPublishingStrategy:
       type: LoadBalancerService
       loadBalancer:
         scope: Internal 

   3

   Copy to Clipboard Toggle word wrap

   1

   <name> par un nom pour l’objet IngressController.

   2

   Indiquez le domaine de l’application publié par le responsable du traitement.

   3

   Indiquez une valeur d’Interne pour utiliser un équilibreur de charge interne.

2. Créez le contrôleur Ingress défini à l’étape précédente en exécutant la commande suivante:

   $ oc create -f <name>-ingress-controller.yaml 

   1

   Copy to Clipboard Toggle word wrap

   1

   <name> par le nom de l’objet IngressController.

3. Facultatif: Confirmer que le contrôleur Ingress a été créé en exécutant la commande suivante:

   $ oc --all-namespaces=true get ingresscontrollers

   Copy to Clipboard Toggle word wrap

Procédure

1. Configurez le contrôleur Ingress par défaut pour que votre cluster soit interne en le supprimant et en le recréant.

   $ oc replace --force --wait --filename - <<EOF
   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     namespace: openshift-ingress-operator
     name: default
   spec:
     endpointPublishingStrategy:
       type: LoadBalancerService
       loadBalancer:
         scope: Internal
   EOF

   Copy to Clipboard Toggle word wrap

Procédure

1. Configurez la stratégie de wildcard.

   1. À l’aide de la commande suivante pour modifier la ressource IngressController:

      $ oc edit IngressController

      Copy to Clipboard Toggle word wrap

   2. Dans la section Spécification, définissez le champ wildcardPolicy sur WildcardsDisallowed ou WildcardsAllowed:

      spec:
        routeAdmission:
          wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed

      Copy to Clipboard Toggle word wrap

Procédure

1. Éditer la ressource Ingress Controller:

   $ oc -n openshift-ingress-operator edit ingresscontroller/default

   Copy to Clipboard Toggle word wrap

2. De remplacer l’en-tête de requête HTTP X-SSL-Client-Der par l’en-tête de requête HTTP X-Forwarded-Client-Cert:

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: default
     namespace: openshift-ingress-operator
   spec:
     httpHeaders:
       actions: 

   1

   
         request: 

   2

   
         - name: X-Forwarded-Client-Cert 

   3

   
           action:
             type: Set 

   4

   
             set:
              value: "%{+Q}[ssl_c_der,base64]" 

   5

   
         - name: X-SSL-Client-Der
           action:
             type: Delete

   Copy to Clipboard Toggle word wrap

   1

   La liste des actions que vous souhaitez effectuer sur les en-têtes HTTP.

   2

   Le type d’en-tête que vous voulez changer. Dans ce cas, un en-tête de demande.

   3

   Le nom de l’en-tête que vous voulez changer. Dans le cas d’une liste d’en-têtes disponibles que vous pouvez définir ou supprimer, voir la configuration d’en-tête HTTP.

   4

   Le type d’action en cours sur l’en-tête. Ce champ peut avoir la valeur Set ou Supprimer.

   5

   Lorsque vous définissez des en-têtes HTTP, vous devez fournir une valeur. La valeur peut être une chaîne à partir d’une liste de directives disponibles pour cet en-tête, par exemple DENY, ou il peut s’agir d’une valeur dynamique qui sera interprétée à l’aide de la syntaxe de valeur dynamique de HAProxy. Dans ce cas, une valeur dynamique est ajoutée.

   Note

   Les valeurs d’en-tête dynamiques pour les réponses HTTP sont ré.hdr et ssl_c_der. Les valeurs d’en-tête dynamiques pour les requêtes HTTP sont req.hdr et ssl_c_der. Les valeurs dynamiques de requête et de réponse peuvent utiliser les convertisseurs inférieur et base64.

3. Enregistrez le fichier pour appliquer les modifications.

Procédure

1. Configurez le champ HTTPHeaders pour le contrôleur Ingress.

   1. À l’aide de la commande suivante pour modifier la ressource IngressController:

      $ oc edit IngressController

      Copy to Clipboard Toggle word wrap

   2. Dans la section Spécification, définissez le champ de stratégie HTTPHeaders pour ajouter, remplacer, IfNone ou jamais:

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpHeaders:
          forwardedHeaderPolicy: Append

      Copy to Clipboard Toggle word wrap

Procédure

1. Modifiez la ressource Ingress Controller en entrant la commande suivante dans votre CLI:

   $ oc -n openshift-ingress-operator edit ingresscontroller/default

   Copy to Clipboard Toggle word wrap

2. Définir la configuration PROXY:

   • Lorsque votre contrôleur Ingress utilise le type de stratégie de publication du point de terminaison HostNetwork, définissez le sous-champ spec.endpointPublishingStrategy.hostNetwork.protocol sur PROXY:

     Exemple de configuration hostNetwork à PROXY

     # ...
       spec:
         endpointPublishingStrategy:
           hostNetwork:
             protocol: PROXY
           type: HostNetwork
     # ...

     Copy to Clipboard Toggle word wrap

   • Lorsque votre contrôleur Ingress utilise le type de stratégie de publication NodePortService, définissez le sous-champ spec.endpointPublishingStrategy.nodePort.protocol sur PROXY:

     Exemple de configuration nodePort à PROXY

     # ...
       spec:
         endpointPublishingStrategy:
           nodePort:
             protocol: PROXY
           type: NodePortService
     # ...

     Copy to Clipboard Toggle word wrap

   • Dans le cas où votre contrôleur Ingress utilise le type de stratégie de publication de points de terminaison privés, définissez le sous-champ spec.endpointPublishingStrategy.priv.protocol sur PROXY:

     Exemple de configuration privée à PROXY

     # ...
       spec:
         endpointPublishingStrategy:
           private:
             protocol: PROXY
         type: Private
     # ...

     Copy to Clipboard Toggle word wrap

Procédure

1. Configurez le champ appsDomain en spécifiant un domaine par défaut alternatif pour les itinéraires créés par l’utilisateur.

   1. Éditer la ressource du cluster d’entrée:

      $ oc edit ingresses.config/cluster -o yaml

      Copy to Clipboard Toggle word wrap

   2. Éditer le fichier YAML:

      Exemple d’applicationsConfiguration de la main pour tester.example.com

      apiVersion: config.openshift.io/v1
      kind: Ingress
      metadata:
        name: cluster
      spec:
        domain: apps.example.com            

      1

      
        appsDomain: <test.example.com>      

      2

      Copy to Clipboard Toggle word wrap

      1

      Indique le domaine par défaut. Après l’installation, vous ne pouvez pas modifier le domaine par défaut.

      2

      En option: Domaine pour OpenShift Infrastructure dédiée à utiliser pour les itinéraires d’application. Au lieu du préfixe par défaut, les applications, vous pouvez utiliser un préfixe alternatif comme le test.

2. Assurez-vous qu’une route existante contient le nom de domaine spécifié dans le champ appsDomain en exposant l’itinéraire et en vérifiant le changement de domaine d’itinéraire:

   Note

   Attendez que l’apiserver ouvert termine les mises à jour de roulement avant d’exposer l’itinéraire.

   1. Exposer l’itinéraire:

      $ oc expose service hello-openshift
      route.route.openshift.io/hello-openshift exposed

      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      $ oc get routes
      NAME              HOST/PORT                                   PATH   SERVICES          PORT       TERMINATION   WILDCARD
      hello-openshift   hello_openshift-<my_project>.test.example.com
      hello-openshift   8080-tcp                 None

      Copy to Clipboard Toggle word wrap

Procédure

1. Configurez le champ httpCompression pour le contrôleur Ingress.

   1. À l’aide de la commande suivante pour modifier la ressource IngressController:

      $ oc edit -n openshift-ingress-operator ingresscontrollers/default

      Copy to Clipboard Toggle word wrap

   2. Dans spec, définissez le champ de stratégie httpCompression sur mimeTypes et spécifiez une liste de types MIME qui devraient avoir une compression appliquée:

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpCompression:
          mimeTypes:
          - "text/html"
          - "text/css; charset=utf-8"
          - "application/json"
         ...

      Copy to Clipboard Toggle word wrap

Procédure

1. Obtenez le nom de la pod de routeur en exécutant la commande suivante:

   $ oc get pods -n openshift-ingress

   Copy to Clipboard Toggle word wrap

   Exemple de sortie

   NAME                              READY   STATUS    RESTARTS   AGE
   router-default-76bfffb66c-46qwp   1/1     Running   0          11h

   Copy to Clipboard Toggle word wrap

2. Accédez au nom d’utilisateur et au mot de passe du routeur, que le routeur stocke dans les fichiers /var/lib/haproxy/conf/metrics-auth/statsUsername et /var/lib/haproxy/conf/metrics-auth/statsword:

   1. Obtenez le nom d’utilisateur en exécutant la commande suivante:

      $ oc rsh <router_pod_name> cat metrics-auth/statsUsername

      Copy to Clipboard Toggle word wrap

   2. Accédez au mot de passe en exécutant la commande suivante:

      $ oc rsh <router_pod_name> cat metrics-auth/statsPassword

      Copy to Clipboard Toggle word wrap

3. Obtenez les certificats IP et métriques du routeur en exécutant la commande suivante:

   $ oc describe pod <router_pod>

   Copy to Clipboard Toggle word wrap

4. Bénéficiez des statistiques brutes au format Prometheus en exécutant la commande suivante:

   $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics

   Copy to Clipboard Toggle word wrap

5. Accédez aux métriques en toute sécurité en exécutant la commande suivante:

   $ curl -u user:password https://<router_IP>:<stats_port>/metrics -k

   Copy to Clipboard Toggle word wrap

6. Accédez au port de statistiques par défaut, 1936, en exécutant la commande suivante:

   $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics

   Copy to Clipboard Toggle word wrap

   Exemple 2.1. Exemple de sortie

   ...
   # HELP haproxy_backend_connections_total Total number of connections.
   # TYPE haproxy_backend_connections_total gauge
   haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route"} 0
   haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route-alt"} 0
   haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route01"} 0
   ...
   # HELP haproxy_exporter_server_threshold Number of servers tracked and the current threshold value.
   # TYPE haproxy_exporter_server_threshold gauge
   haproxy_exporter_server_threshold{type="current"} 11
   haproxy_exporter_server_threshold{type="limit"} 500
   ...
   # HELP haproxy_frontend_bytes_in_total Current total of incoming bytes.
   # TYPE haproxy_frontend_bytes_in_total gauge
   haproxy_frontend_bytes_in_total{frontend="fe_no_sni"} 0
   haproxy_frontend_bytes_in_total{frontend="fe_sni"} 0
   haproxy_frontend_bytes_in_total{frontend="public"} 119070
   ...
   # HELP haproxy_server_bytes_in_total Current total of incoming bytes.
   # TYPE haproxy_server_bytes_in_total gauge
   haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_no_sni",service=""} 0
   haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_sni",service=""} 0
   haproxy_server_bytes_in_total{namespace="default",pod="docker-registry-5-nk5fz",route="docker-registry",server="10.130.0.89:5000",service="docker-registry"} 0
   haproxy_server_bytes_in_total{namespace="default",pod="hello-rc-vkjqx",route="hello-route",server="10.130.0.90:8080",service="hello-svc-1"} 0
   ...

   Copy to Clipboard Toggle word wrap

7. Lancez la fenêtre de statistiques en entrant l’URL suivante dans un navigateur:

   http://<user>:<password>@<router_IP>:<stats_port>

   Copy to Clipboard Toggle word wrap

8. Facultatif: Obtenez les statistiques au format CSV en entrant l’URL suivante dans un navigateur:

   http://<user>:<password>@<router_ip>:1936/metrics;csv

   Copy to Clipboard Toggle word wrap