Chapitre 7. CLI Knative

Conditions préalables

• OpenShift Serverless Operator et Knative Serving sont installés sur votre cluster.
• Vous avez installé le CLI Knative (kn).
• Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.

Procédure

• Créer un service Knative :

  $ kn service create <service-name> --image <image> --tag <tag-value>

  Où ?

  • --image est l'URI de l'image pour l'application.

  • --tag est un indicateur facultatif qui peut être utilisé pour ajouter une étiquette à la révision initiale créée avec le service.

    Example command

    $ kn service create event-display \
        --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

    Exemple de sortie

    Creating service 'event-display' in namespace 'default':
    
      0.271s The Route is still working to reflect the latest desired specification.
      0.580s Configuration "event-display" is waiting for a Revision to become ready.
      3.857s ...
      3.861s Ingress has not yet been reconciled.
      4.270s Ready to serve.
    
    Service 'event-display' created with latest revision 'event-display-bxshg-1' and URL:
    http://event-display-default.apps-crc.testing

Exemple de commandes

• Mettre à jour un service en ajoutant une nouvelle variable d'environnement :

  $ kn service update <service_name> --env <key>=<value>

• Mettre à jour un service en ajoutant un nouveau port :

  $ kn service update <service_name> --port 80

• Mettre à jour un service en ajoutant de nouveaux paramètres de demande et de limite :

  $ kn service update <service_name> --request cpu=500m --limit memory=1024Mi --limit cpu=1000m

• Attribuer la balise latest à une révision :

  $ kn service update -YRFFGUNA nom_du_service> --tag -YRFFGUNA nom_de_la_révision>=latest

• Mettre à jour une balise de testing à staging pour la dernière révision READY d'un service :

  $ kn service update <service_name> --untag testing --tag @latest=staging

• Ajoutez la balise test à une révision qui reçoit 10 % du trafic, et envoyez le reste du trafic à la dernière révision READY d'un service :

  $ kn service update -YRFFGUNA nom_du_service> --tag -YRFFGUNA nom_de_la_révision>=test --traffic test=10,@latest=90

Exemple de commandes

• Créer un service :

  kn service apply <service_name> --image <image> $ kn service apply <service_name> --image <image>

• Ajouter une variable d'environnement à un service :

  $ kn service apply <service_name> --image <image> --env <key>=<value>

• Lire la déclaration de service à partir d'un fichier JSON ou YAML :

  $ kn service apply <service_name> -f <filename>

Exemple de commandes

• Décrire un service :

  kn service describe --verbose <service_name>

  Le drapeau --verbose est facultatif mais peut être inclus pour fournir une description plus détaillée. La différence entre une sortie normale et une sortie verbeuse est illustrée dans les exemples suivants :

  Exemple de sortie sans l'indicateur --verbose

  Name:       hello
  Namespace:  default
  Age:        2m
  URL:        http://hello-default.apps.ocp.example.com
  
  Revisions:
    100%  @latest (hello-00001) [1] (2m)
          Image:  docker.io/openshift/hello-openshift (pinned to aaea76)
  
  Conditions:
    OK TYPE                   AGE REASON
    ++ Ready                   1m
    ++ ConfigurationsReady     1m
    ++ RoutesReady             1m

  Exemple de sortie avec l'indicateur --verbose

  Name:         hello
  Namespace:    default
  Annotations:  serving.knative.dev/creator=system:admin
                serving.knative.dev/lastModifier=system:admin
  Age:          3m
  URL:          http://hello-default.apps.ocp.example.com
  Cluster:      http://hello.default.svc.cluster.local
  
  Revisions:
    100%  @latest (hello-00001) [1] (3m)
          Image:  docker.io/openshift/hello-openshift (pinned to aaea76)
          Env:    RESPONSE=Hello Serverless!
  
  Conditions:
    OK TYPE                   AGE REASON
    ++ Ready                   3m
    ++ ConfigurationsReady     3m
    ++ RoutesReady             3m

• Décrire un service au format YAML :

  $ kn service describe <service_name> -o yaml

• Décrire un service au format JSON :

  $ kn service describe -YRFFGUNA nom_du_service> -o json

• Imprimer uniquement l'URL du service :

  $ kn service describe <service_name> -o url

• Vous pouvez modifier manuellement le fichier descripteur avant de l'utiliser pour effectuer des modifications sur le cluster.
• Vous pouvez suivre localement le fichier descripteur d'un service dans un système de contrôle de version. Cela vous permet de réutiliser le fichier descripteur ailleurs que dans le cluster cible, par exemple dans des pipelines d'intégration continue (CI), des environnements de développement ou des démonstrations.
• Vous pouvez examiner les fichiers descripteurs créés pour en savoir plus sur les services Knative. En particulier, vous pouvez voir comment le service résultant est influencé par les différents arguments passés à la commande kn.

Conditions préalables

• OpenShift Serverless Operator et Knative Serving sont installés sur votre cluster.
• Vous avez installé le CLI Knative (kn).

• Ajouter un conteneur à partir d'une image et l'imprimer sur la sortie standard :

  kn container add <container_name> --image <image_uri>

  Example command

  $ kn container add sidecar --image docker.io/example/sidecar

  Exemple de sortie

  containers:
  - image: docker.io/example/sidecar
    name: sidecar
    resources: {}

• Enchaînez deux commandes kn container add, puis passez-les à une commande kn service create pour créer un service Knative avec deux conteneurs :

  $ kn container add <first_container_name> --image <image_uri> | \
  kn container add <second_container_name> --image <image_uri> | \
  kn service create <service_name> --image <image_uri> --extra-containers -

  --extra-containers - spécifie un cas particulier où kn lit l'entrée du tuyau au lieu d'un fichier YAML.

  Example command

  $ kn container add sidecar --image docker.io/example/sidecar:first | \
  kn container add second --image docker.io/example/sidecar:second | \
  kn service create my-service --image docker.io/example/my-app:latest --extra-containers -

  L'option --extra-containers peut également accepter un chemin vers un fichier YAML :

  $ kn service create <service_name> --image <image_uri> --extra-containers <filename>

  Example command

  $ kn service create my-service --image docker.io/example/my-app:latest --extra-containers my-extra-containers.yaml

Conditions préalables

• L'opérateur OpenShift Serverless et Knative Serving sont installés sur votre cluster.

• Vous avez créé un service ou une route Knative, et vous contrôlez un domaine personnalisé que vous souhaitez associer à ce CR.

  Note

  Votre domaine personnalisé doit pointer vers le DNS du cluster OpenShift Container Platform.

• Vous avez installé le CLI Knative (kn).
• Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.

Procédure

• Associe un domaine à un CR dans l'espace de noms actuel :

  kn domain create <domain_mapping_name> --ref <target_name>

  Example command

  $ kn domain create example-domain-map --ref example-service

  L'indicateur --ref spécifie un CR cible adressable pour le mappage de domaine.

  Si aucun préfixe n'est fourni lors de l'utilisation de l'indicateur --ref, il est supposé que la cible est un service Knative dans l'espace de noms actuel.

• Associer un domaine à un service Knative dans un espace de noms spécifié :

  kn domain create <domain_mapping_name> --ref <ksvc:service_name:service_namespace>

  Example command

  $ kn domain create example-domain-map --ref ksvc:example-service:example-namespace

• Associer un domaine à une route Knative :

  $ kn domain create <domain_mapping_name> --ref <kroute:route_name>

  Example command

  $ kn domain create example-domain-map --ref kroute:example-route

Conditions préalables

• L'opérateur OpenShift Serverless et Knative Serving sont installés sur votre cluster.
• Vous avez créé au moins un CR DomainMapping.
• Vous avez installé l'outil CLI Knative (kn).
• Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.

Procédure

• Liste des CR existants sur DomainMapping:

  $ kn domain list -n <domain_mapping_namespace>

• Voir les détails d'un DomainMapping CR existant :

  $ kn domain describe <domain_mapping_name>

• Mettre à jour un CR DomainMapping pour qu'il pointe vers une nouvelle cible :

  $ kn domain update --ref <target>

• Supprimer un CR DomainMapping:

  kn domain delete <domain_mapping_name>