5.5. Opérateurs à la barre

Procédure

1. Create a project.

   1. Créez votre répertoire de projet :

      $ mkdir nginx-operator

   2. Allez dans le répertoire du projet :

      $ cd nginx-operator

   3. Exécutez la commande operator-sdk init avec le plugin helm pour initialiser le projet :

      $ operator-sdk init \
          --plugins=helm

2. Create an API.

   Créer une API Nginx simple :

   $ operator-sdk create api \
       --group demo \
       --version v1 \
       --kind Nginx

   Cette API utilise le modèle de graphique intégré de Helm de la commande helm create.

3. Build and push the Operator image.

   Utilisez les cibles par défaut de Makefile pour construire et pousser votre opérateur. Définissez IMG avec une spécification d'extraction pour votre image qui utilise un registre vers lequel vous pouvez pousser :

   $ make docker-build docker-push IMG=<registry>/<user>/<image_name>:<tag>

4. Run the Operator.

   1. Installer le CRD :

      $ make install

   2. Déployez le projet sur le cluster. Définissez IMG sur l'image que vous avez poussée :

      $ make deploy IMG=<registry>/<user>/<image_name>:<tag>

5. Add a security context constraint (SCC).

   Le compte de service Nginx nécessite un accès privilégié pour fonctionner dans OpenShift Container Platform. Ajoutez le SCC suivant au compte de service pour le pod nginx-sample:

   $ oc adm policy add-scc-to-user \
       anyuid system:serviceaccount:nginx-operator-system:nginx-sample

6. Create a sample custom resource (CR).

   1. Créer un échantillon de CR :

      $ oc apply -f config/samples/demo_v1_nginx.yaml \
          -n nginx-operator-system

   2. Il faut s'attendre à ce que le CR réconcilie l'opérateur :

      $ oc logs deployment.apps/nginx-operator-controller-manager \
          -c manager \
          -n nginx-operator-system

7. Delete a CR

   Supprimez un CR en exécutant la commande suivante :

   $ oc delete -f config/samples/cache_v1_memcached.yaml -n memcached-operator-system

8. Clean up.

   Exécutez la commande suivante pour nettoyer les ressources qui ont été créées dans le cadre de cette procédure :

   $ make undeploy

Procédure

1. Créer un répertoire pour le projet :

   $ mkdir -p $HOME/projects/nginx-operator

2. Accédez au répertoire :

   $ cd $HOME/projects/nginx-operator

3. Exécutez la commande operator-sdk init avec le plugin helm pour initialiser le projet :

   $ operator-sdk init \
       --plugins=helm \
       --domain=example.com \
       --group=demo \
       --version=v1 \
       --kind=Nginx

   Note

   Par défaut, le plugin helm initialise un projet à l'aide d'un diagramme Helm standard. Vous pouvez utiliser des drapeaux supplémentaires, tels que le drapeau --helm-chart, pour initialiser un projet à l'aide d'un diagramme Helm existant.

   La commande init crée le projet nginx-operator spécifiquement pour observer une ressource avec la version de l'API example.com/v1 et le type Nginx.

4. Pour les projets basés sur Helm, la commande init génère les règles RBAC dans le fichier config/rbac/role.yaml en se basant sur les ressources qui seraient déployées par le manifeste par défaut de la carte. Vérifiez que les règles générées dans ce fichier répondent aux exigences de permission de l'opérateur.

Procédure

1. Passez à l'espace de noms dans lequel votre opérateur est installé. Par exemple, si vous avez déployé l'opérateur à l'aide de la commande make deploy:

   $ oc project nginx-operator-system

2. Modifiez l'exemple de manifeste Nginx CR à l'adresse config/samples/demo_v1_nginx.yaml pour qu'il contienne la spécification suivante :

   apiVersion: demo.example.com/v1
   kind: Nginx
   metadata:
     name: nginx-sample
   ...
   spec:
   ...
     replicaCount: 3

3. Le compte de service Nginx nécessite un accès privilégié pour fonctionner dans OpenShift Container Platform. Ajoutez la contrainte de contexte de sécurité (SCC) suivante au compte de service du pod nginx-sample:

   $ oc adm policy add-scc-to-user \
       anyuid system:serviceaccount:nginx-operator-system:nginx-sample

4. Créer le CR :

   $ oc apply -f config/samples/demo_v1_nginx.yaml

5. Assurez-vous que l'opérateur Nginx crée le déploiement pour l'échantillon de CR avec la taille correcte :

   $ oc get deployments

   Exemple de sortie

   NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
   nginx-operator-controller-manager       1/1     1            1           8m
   nginx-sample                            3/3     3            3           1m

6. Vérifiez le statut des pods et du CR pour confirmer que le statut est mis à jour avec les noms des pods Nginx.

   1. Vérifier les gousses :

      $ oc get pods

      Exemple de sortie

      NAME                                  READY     STATUS    RESTARTS   AGE
      nginx-sample-6fd7c98d8-7dqdr          1/1       Running   0          1m
      nginx-sample-6fd7c98d8-g5k7v          1/1       Running   0          1m
      nginx-sample-6fd7c98d8-m7vn7          1/1       Running   0          1m

   2. Vérifier l'état de la CR :

      $ oc get nginx/nginx-sample -o yaml

      Exemple de sortie

      apiVersion: demo.example.com/v1
      kind: Nginx
      metadata:
      ...
        name: nginx-sample
      ...
      spec:
        replicaCount: 3
      status:
        nodes:
        - nginx-sample-6fd7c98d8-7dqdr
        - nginx-sample-6fd7c98d8-g5k7v
        - nginx-sample-6fd7c98d8-m7vn7

7. Mettre à jour la taille du déploiement.

   1. Mettre à jour le fichier config/samples/demo_v1_nginx.yaml pour modifier le champ spec.size dans le CR Nginx de 3 à 5:

      $ oc patch nginx nginx-sample \
          -p '{"spec":{"replicaCount": 5}}' \
          --type=merge

   2. Confirmez que l'opérateur modifie la taille du déploiement :

      $ oc get deployments

      Exemple de sortie

      NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
      nginx-operator-controller-manager       1/1     1            1           10m
      nginx-sample                            5/5     5            5           3m

8. Supprimez le CR en exécutant la commande suivante :

   $ oc delete -f config/samples/demo_v1_nginx.yaml

9. Nettoyer les ressources qui ont été créées dans le cadre de ce tutoriel.

   • Si vous avez utilisé la commande make deploy pour tester l'opérateur, exécutez la commande suivante :

     $ make undeploy

   • Si vous avez utilisé la commande operator-sdk run bundle pour tester l'opérateur, exécutez la commande suivante :

     $ operator-sdk cleanup <nom_du_projet>

Procédure

1. Apportez les modifications suivantes au fichier config/default/manager_auth_proxy_patch.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: controller-manager
     namespace: system
   spec:
     template:
       spec:
         containers:
         - name: kube-rbac-proxy
           image: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.12 1
           args:
           - "--secure-listen-address=0.0.0.0:8443"
           - "--upstream=http://127.0.0.1:8080/"
           - "--logtostderr=true"
           - "--v=0"
   ...

   1

   Mettre à jour la version de la balise de v4.11 à v4.12.

2. Apportez les modifications suivantes à votre site Makefile:

   1. Pour activer la prise en charge des architectures multiples, ajoutez la cible docker-buildx à votre projet Makefile:

      Exemple Makefile

      # PLATFORMS defines the target platforms for  the manager image be build to provide support to multiple
      # architectures. (i.e. make docker-buildx IMG=myregistry/mypoperator:0.0.1). To use this option you need to:
      # - able to use docker buildx . More info: https://docs.docker.com/build/buildx/
      # - have enable BuildKit, More info: https://docs.docker.com/develop/develop-images/build_enhancements/
      # - be able to push the image for your registry (i.e. if you do not inform a valid value via IMG=<myregistry/image:<tag>> than the export will fail)
      # To properly provided solutions that supports more than one platform you should use this option.
      PLATFORMS ?= linux/arm64,linux/amd64,linux/s390x,linux/ppc64le
      .PHONY: docker-buildx
      docker-buildx: test ## Build and push docker image for the manager for cross-platform support
      	# copy existing Dockerfile and insert --platform=${BUILDPLATFORM} into Dockerfile.cross, and preserve the original Dockerfile
      	sed -e '1 s/\(^FROM\)/FROM --platform=\$$\{BUILDPLATFORM\}/; t' -e ' 1,// s//FROM --platform=\$$\{BUILDPLATFORM\}/' Dockerfile > Dockerfile.cross
      	- docker buildx create --name project-v3-builder
      	docker buildx use project-v3-builder
      	- docker buildx build --push --platform=$(PLATFORMS) --tag ${IMG} -f Dockerfile.cross
      	- docker buildx rm project-v3-builder
      	rm Dockerfile.cross

   2. Pour permettre la prise en charge des architectures arm64 dans votre projet Operator, apportez les modifications suivantes à votre projet Makefile:

      Ancienne Makefile

      OS := $(shell uname -s | tr '[:upper:]' '[:lower:]')
      ARCH := $(shell uname -m | sed 's/x86_64/amd64/')

      Nouveau Makefile

      OS := $(shell uname -s | tr '[:upper:]' '[:lower:]')
      ARCH := $(shell uname -m | sed 's/x86_64/amd64/' |  sed 's/aarch64/arm64/')

   3. Mettez à jour la version de Kustomize à v4.5.5 comme indiqué dans l'exemple suivant :

      Ancienne Makefile

      .PHONY: kustomize
      KUSTOMIZE = $(shell pwd)/bin/kustomize
      kustomize: ## Download kustomize locally if necessary.
      ifeq (,$(wildcard $(KUSTOMIZE)))
      ifeq (,$(shell which kustomize 2>/dev/null))
      	@{ \
      	set -e ;\
      	mkdir -p $(dir $(KUSTOMIZE)) ;\
      	curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v3.8.7/kustomize_v3.8.7_$(OS)_$(ARCH).tar.gz | \
      	tar xzf - -C bin/ ;\
      	}
      else

      Nouveau Makefile

      .PHONY: kustomize
      KUSTOMIZE = $(shell pwd)/bin/kustomize
      kustomize: ## Download kustomize locally if necessary.
      ifeq (,$(wildcard $(KUSTOMIZE)))
      ifeq (,$(shell which kustomize 2>/dev/null))
      	@{ \
      	set -e ;\
      	mkdir -p $(dir $(KUSTOMIZE)) ;\
      	curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v4.5.5/kustomize_v4.5.5_$(OS)_$(ARCH).tar.gz | \ 1
      	tar xzf - -C bin/ ;\
      	}
      else

      1

      Mise à jour de la version v3.8.7 vers v4.5.5.

      Important

      La version de Kustomize 4.0.0 a supprimé le plugin go-getter et a introduit des changements qui ne sont pas compatibles avec les versions antérieures. Les projets d'opérateurs qui s'appuient sur des versions antérieures de Kustomize pourraient ne pas fonctionner avec les nouvelles versions.

   4. Pour appliquer les changements à votre Makefile et reconstruire votre Opérateur, entrez la commande suivante :

      $ make

3. Mettez à jour votre fichier config/default/kustomizations.yaml comme indiqué dans les exemples suivants :

   Exemple de fichier kustomizations.yaml

   # Adds namespace to all resources.
   namespace: memcached-operator-system
   # Value of this field is prepended to the
   # names of all resources, e.g. a deployment named
   # "wordpress" becomes "alices-wordpress".
   # Note that it should also match with the prefix (text before '-') of the namespace
   # field above.
   namePrefix: memcached-operator-
   
   # Labels to add to all resources and selectors.
   #labels: 1
   #- includeSelectors: true 2
   #  pairs:
   #    someName: someValue
   
   resources: 3
   - ../crd
   - ../rbac
   - ../manager

   1

   Remplacer le champ commonLabels par le champ labels.

   2

   Ajouter includeSelectors: true.

   3

   Remplacer le champ bases par le champ resources.

Procédure

1. Créer un répertoire pour le projet :

   $ mkdir -p $HOME/github.com/example/memcached-operator

2. Accédez au répertoire :

   $ cd $HOME/github.com/example/memcached-operator

3. Exécutez la commande operator-sdk init pour initialiser le projet. Utilisez un domaine de example.com pour que tous les groupes API soient <group>.example.com:

   $ operator-sdk init \
       --plugins=hybrid.helm.sdk.operatorframework.io \
       --project-version="3" \
       --domain example.com \
       --repo=github.com/example/memcached-operator

   La commande init génère les règles RBAC dans le fichier config/rbac/role.yaml en se basant sur les ressources qui seraient déployées par les manifestes par défaut de la carte. Vérifiez que les règles générées dans le fichier config/rbac/role.yaml répondent aux exigences de permission de votre opérateur.

Procédure

1. Exécutez la commande suivante pour créer une API Go avec le groupe cache, la version v1 et le type MemcachedBackup:

   $ operator-sdk create api \
       --group=cache \
       --version v1 \
       --kind MemcachedBackup \
       --resource \
       --controller \
       --plugins=go/v3

2. Lorsque vous y êtes invité, entrez y pour créer à la fois la ressource et le contrôleur :

   $ Create Resource [y/n]
   y
   Create Controller [y/n]
   y

Procédure

1. Exécutez les commandes make suivantes pour construire et pousser l'image de l'opérateur. Modifiez l'argument IMG dans les étapes suivantes pour référencer un référentiel auquel vous avez accès. Vous pouvez obtenir un compte pour stocker des conteneurs sur des sites de dépôt tels que Quay.io.

   1. Construire l'image :

      $ make docker-build IMG=<registry>/<user>/<image_name>:<tag>

      Note

      Le fichier Docker généré par le SDK pour l'Operator fait explicitement référence à GOARCH=amd64 pour go build. Cette référence peut être modifiée en GOARCH=$TARGETARCH pour les architectures non-AMD64. Docker définira automatiquement la variable d'environnement à la valeur spécifiée par –platform. Avec Buildah, il faudra utiliser –build-arg à cette fin. Pour plus d'informations, voir Architectures multiples.

   2. Transférer l'image dans un référentiel :

      $ make docker-push IMG=<registry>/<user>/<image_name>:<tag>

      Note

      Le nom et la balise de l'image, par exemple IMG=<registry>/<user>/<image_name>:<tag>, dans les deux commandes peuvent également être définis dans votre Makefile. Modifiez la valeur de IMG ?= controller:latest pour définir votre nom d'image par défaut.

2. Exécutez la commande suivante pour déployer l'opérateur :

   $ make deploy IMG=<registry>/<user>/<image_name>:<tag>

   Par défaut, cette commande crée un espace de noms avec le nom de votre projet Operator sous la forme <project_name>-system et est utilisé pour le déploiement. Cette commande installe également les manifestes RBAC à partir de config/rbac.

3. Exécutez la commande suivante pour vérifier que l'opérateur fonctionne :

   oc get deployment -n <nom_du_projet>-système

   Exemple de sortie

   NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
   <project_name>-controller-manager       1/1     1            1           8m

Procédure

1. Passez à l'espace de noms dans lequel votre opérateur est installé :

   $ oc project <nom_du_projet>-système

2. Mettez à jour l'exemple de manifeste Memcached CR dans le fichier config/samples/cache_v1_memcached.yaml en remplaçant le champ replicaCount par 3:

   Exemple 5.7. Exemple de fichier config/samples/cache_v1_memcached.yaml

   apiVersion: cache.my.domain/v1
   kind: Memcached
   metadata:
     name: memcached-sample
   spec:
     # Default values copied from <project_dir>/helm-charts/memcached/values.yaml
     affinity: {}
     autoscaling:
       enabled: false
       maxReplicas: 100
       minReplicas: 1
       targetCPUUtilizationPercentage: 80
     fullnameOverride: ""
     image:
       pullPolicy: IfNotPresent
       repository: nginx
       tag: ""
     imagePullSecrets: []
     ingress:
       annotations: {}
       className: ""
       enabled: false
       hosts:
       - host: chart-example.local
         paths:
         - path: /
           pathType: ImplementationSpecific
       tls: []
     nameOverride: ""
     nodeSelector: {}
     podAnnotations: {}
     podSecurityContext: {}
     replicaCount: 3
     resources: {}
     securityContext: {}
     service:
       port: 80
       type: ClusterIP
     serviceAccount:
       annotations: {}
       create: true
       name: ""
     tolerations: []

3. Créer le CR Memcached:

   $ oc apply -f config/samples/cache_v1_memcached.yaml

4. Assurez-vous que l'opérateur Memcached crée le déploiement pour l'exemple de CR avec la taille correcte :

   $ oc get pods

   Exemple de sortie

   NAME                                  READY     STATUS    RESTARTS   AGE
   memcached-sample-6fd7c98d8-7dqdr      1/1       Running   0          18m
   memcached-sample-6fd7c98d8-g5k7v      1/1       Running   0          18m
   memcached-sample-6fd7c98d8-m7vn7      1/1       Running   0          18m

5. Mettez à jour l'exemple de manifeste MemcachedBackup CR dans le fichier config/samples/cache_v1_memcachedbackup.yaml en mettant à jour le fichier size en 2:

   Exemple 5.8. Exemple de fichier config/samples/cache_v1_memcachedbackup.yaml

   apiVersion: cache.my.domain/v1
   kind: MemcachedBackup
   metadata:
     name: memcachedbackup-sample
   spec:
     size: 2

6. Créer le CR MemcachedBackup:

   $ oc apply -f config/samples/cache_v1_memcachedbackup.yaml

7. Assurez-vous que le nombre de pods memcachedbackup est le même que celui spécifié dans le CR :

   $ oc get pods

   Exemple de sortie

   NAME                                        READY     STATUS    RESTARTS   AGE
   memcachedbackup-sample-8649699989-4bbzg     1/1       Running   0          22m
   memcachedbackup-sample-8649699989-mq6mx     1/1       Running   0          22m

8. Vous pouvez mettre à jour les spec dans chacun des CR ci-dessus, puis les appliquer à nouveau. Le contrôleur procède à une nouvelle réconciliation et s'assure que la taille des pods est conforme à ce qui est spécifié dans le site spec des CR respectifs.

9. Nettoyer les ressources qui ont été créées dans le cadre de ce tutoriel :

   1. Supprimer la ressource Memcached:

      $ oc delete -f config/samples/cache_v1_memcached.yaml

   2. Supprimer la ressource MemcachedBackup:

      $ oc delete -f config/samples/cache_v1_memcachedbackup.yaml

   3. Si vous avez utilisé la commande make deploy pour tester l'opérateur, exécutez la commande suivante :

      $ make undeploy

Procédure

1. Apportez les modifications suivantes au fichier config/default/manager_auth_proxy_patch.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: controller-manager
     namespace: system
   spec:
     template:
       spec:
         containers:
         - name: kube-rbac-proxy
           image: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.12 1
           args:
           - "--secure-listen-address=0.0.0.0:8443"
           - "--upstream=http://127.0.0.1:8080/"
           - "--logtostderr=true"
           - "--v=0"
   ...

   1

   Mettre à jour la version de la balise de v4.11 à v4.12.

2. Apportez les modifications suivantes à votre site Makefile:

   1. Pour activer la prise en charge des architectures multiples, ajoutez la cible docker-buildx à votre projet Makefile:

      Exemple Makefile

      # PLATFORMS defines the target platforms for  the manager image be build to provide support to multiple
      # architectures. (i.e. make docker-buildx IMG=myregistry/mypoperator:0.0.1). To use this option you need to:
      # - able to use docker buildx . More info: https://docs.docker.com/build/buildx/
      # - have enable BuildKit, More info: https://docs.docker.com/develop/develop-images/build_enhancements/
      # - be able to push the image for your registry (i.e. if you do not inform a valid value via IMG=<myregistry/image:<tag>> than the export will fail)
      # To properly provided solutions that supports more than one platform you should use this option.
      PLATFORMS ?= linux/arm64,linux/amd64,linux/s390x,linux/ppc64le
      .PHONY: docker-buildx
      docker-buildx: test ## Build and push docker image for the manager for cross-platform support
      	# copy existing Dockerfile and insert --platform=${BUILDPLATFORM} into Dockerfile.cross, and preserve the original Dockerfile
      	sed -e '1 s/\(^FROM\)/FROM --platform=\$$\{BUILDPLATFORM\}/; t' -e ' 1,// s//FROM --platform=\$$\{BUILDPLATFORM\}/' Dockerfile > Dockerfile.cross
      	- docker buildx create --name project-v3-builder
      	docker buildx use project-v3-builder
      	- docker buildx build --push --platform=$(PLATFORMS) --tag ${IMG} -f Dockerfile.cross
      	- docker buildx rm project-v3-builder
      	rm Dockerfile.cross

   2. Pour appliquer les changements à votre Makefile et reconstruire votre Opérateur, entrez la commande suivante :

      $ make

3. Pour mettre à jour Go et ses dépendances, apportez les modifications suivantes à votre fichier go.mod:

   go 1.19 1
   
   require (
     github.com/onsi/ginkgo/v2 v2.1.4 2
     github.com/onsi/gomega v1.19.0 3
     k8s.io/api v0.25.0 4
     k8s.io/apimachinery v0.25.0 5
     k8s.io/client-go v0.25.0 6
     sigs.k8s.io/controller-runtime v0.13.0 7
   )

   1

   Mise à jour de la version 1.18 vers 1.19.

   2

   Mise à jour de la version v1.16.5 vers v2.1.4.

   3

   Mise à jour de la version v1.18.1 vers v1.19.0.

   4

   Mise à jour de la version v0.24.0 vers v0.25.0.

   5

   Mise à jour de la version v0.24.0 vers v0.25.0.

   6

   Mise à jour de la version v0.24.0 vers v0.25.0.

   7

   Mise à jour de la version v0.12.1 vers v0.13.0.

4. Pour télécharger les versions mises à jour, nettoyer les dépendances et appliquer les changements dans votre fichier go.mod, exécutez la commande suivante :

   $ go mod tidy