🛎️ 👎🏿 🚝 L'équipe d'OC à la rescousse 👸🏻 👴🏻 👨🏾‍⚕️

Si vous êtes spécial dans OpenShift, il est peu probable que ce message vous révèle beaucoup. Mais si vous commencez tout juste à le maîtriser, cela vous fera économiser beaucoup de temps et de nerfs. Nous avons demandé à Jorge Tudela González de Riancho, consultant cloud au bureau espagnol de Red Hat, d'écrire quelques astuces de vie pour l'utilitaire oc .

C'est une équipe sympa, elle est bien pensée, elle est puissante, elle est flexible et, comme vous le verrez, elle a de nombreuses fonctionnalités cachées qui valent la peine d'être essayées.

1. Tout d'abord: le débogage

Lorsque je ne sais pas ce qui se passe ou que j'obtiens un message d'erreur incompréhensible, j'utilise toujours l'indicateur --loglevell , qui permet de se connecter à stderr. Selon la valeur de cet indicateur, vous pouvez voir les appels curl API Rest, le contenu des réponses API Rest ou des informations encore plus détaillées.

$ oc --loglevel 7 get pod
...
I0216 21:24:12.027793 973 cached_discovery.go:72] returning cached discovery info from /home/jtudelag/.kube/192.168.42.77_8443/v1/serverresources.json
I0216 21:24:12.028046 973 round_trippers.go:383] GET https://192.168.42.77:8443/api/v1/namespaces/myproject/pods
I0216 21:24:12.028052 973 round_trippers.go:390] Request Headers:
I0216 21:24:12.028057 973 round_trippers.go:393] Accept: application/json
I0216 21:24:12.028061 973 round_trippers.go:393] User-Agent: oc/v1.7.6+a08f5eeb62 (linux/amd64) kubernetes/c84beff
I0216 21:24:12.053230 973 round_trippers.go:408] Response Status: 200 OK in 25 milliseconds
I0216 21:24:12.055143 973 cached_discovery.go:119] returning cached discovery info from /home/jtudelag/.kube/192.168.42.77_8443/servergroups.json
I0216 21:24:12.055228 973 cached_discovery.go:72] returning cached discovery info from /home/jtudelag/.kube/192.168.42.77_8443/authentication.k8s.io/v1/serverresources.json
I0216 21:24:12.055288 973 cached_discovery.go:72]
...

Par exemple, loglevel 9 est très pratique lorsque vous corrigez un objet OCP, car il vous permet de voir le correctif lui-même (le contenu de la demande d'API).

Si, par exemple, un patch change le nom du service en «app: hello-jorge», il ressemblera à ceci:

$ oc --loglevel 9 edit svc hello-openshift
...
I0216 21:33:15.786463 1389 request.go:994] Request Body: {"metadata":{"labels":{"app":"hello-jorge"}}}
I0216 21:33:15.786590 1389 round_trippers.go:386] curl -k -v -XPATCH -H "Accept: application/json" -H "Content-Type: application/strategic-merge-patch+json" -H "User-Agent: oc/v1.7.6+a08f5eeb62 (linux/amd64) kubernetes/c84beff" https://192.168.42.77:8443/api/v1/namespaces/myproject/services/hello-openshift
I0216 21:33:15.797185 1389 round_trippers.go:405] PATCH https://192.168.42.77:8443/api/v1/namespaces/myproject/services/hello-openshift 200 OK in 10 milliseconds
...

Remarque En période de désespoir, au lieu d'un neuf, vous pouvez conduire plusieurs à la fois. La sortie de la commande oc ne changera pas à partir de cela, mais cela peut vous sembler mieux.

$ oc --loglevel 9999 get pod

2. su -

Oui, vous avez bien compris. La commande oc peut être exécutée au nom d'un autre utilisateur ou, en utilisant le langage OCP, utiliser l' emprunt d'identité . Bien sûr, avec les droits appropriés. Et pour cela, il suffit d'utiliser le drapeau --as .

Par exemple:

# jorge
$ oc --as=jorge get pods

L'emprunt d'identité fonctionne non seulement pour les utilisateurs, mais aussi pour les groupes:

# developers
$ oc --as-group=developers get pods

L'emprunt d'identité est utile dans divers cas. Par exemple, lorsque vous devez vérifier si l'utilisateur peut effectuer l'une ou l'autre action, ou voir ce que lui envoie la commande oc . L'emprunt d'identité contribue également beaucoup à la confusion avec les rôles et les autorisations.

3. Whoami

L'équipe oc whoami est probablement familière à tout le monde. Surtout le drapeau -t , qui vous permet d'obtenir le jeton de média pour l'utilisateur / session en cours. Mais que se passe-t-il si vous avez un jeton, mais que vous n'en êtes pas le propriétaire?

Dans ce cas, vous pouvez vous connecter à OpenShift à l'aide de ce jeton, puis exécuter la commande oc whoami . Bien, attendez, vous pouvez immédiatement trouver le nom du propriétaire en passant simplement le jeton à la commande oc whoami comme troisième argument sans aucun indicateur.

Voir:

#
$ token=$(oc whoami -t)

#
$ oc whoami $token
jorge

4. oc debug

Comme vous le savez, un shell peut être exécuté directement dans un pod en cours d'exécution. Parfois, il est utile de faire une copie complète de la configuration du pod en cours d'exécution et de dépanner le shell. Il s'agit de la méthode dite par défaut.

Jetez maintenant un œil à ce que les options de débogage oc vous permettent de faire: vous pouvez exécuter le conteneur en tant que root ou tout autre utilisateur; vous pouvez l'exécuter sur le nœud sélectionné ou vous pouvez l'exécuter non pas un shell, mais une autre commande.

Dans ce cas, vous devez spécifier le bon DC, par exemple:

# shell pod' dc/jorge
$ oc debug dc/jorge

# , root
$ oc debug --as-root=true dc/jorge

5. oc expliquer

Les objets OpenShift / Kubernetes ont parfois un grand nombre de champs. Lorsque vous recherchez des exemples de définitions pour de tels objets, vous devez souvent vous tourner vers la documentation d'OCP ou d'autres sources principales. Cependant, vous pouvez également utiliser la commande oc expliquer .

Cette commande affiche la documentation sur les ressources et leurs champs, ce qui est très utile lors de la déclaration de nouveaux objets OCP ou dans les cas où vous n'avez pas accès à la documentation OCP officielle.

Par exemple, voici comment obtenir la documentation du pod et une description des champs d'affinité:

# obtenir de l'aide sur le pod
$ oc expliquer pod
DESCRIPTION:
Pod est une collection de conteneurs pouvant s'exécuter sur un hôte. Cette ressource est créée par les clients et planifiée sur les hôtes.

CHAMPS:
métadonnées <Objet>
Métadonnées de l'objet standard. Plus d'infos:
http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#metadata

spec <Objet>
Spécification du comportement souhaité du pod. Plus d'infos:
http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#spec-and-status

statut <Objet>
Dernier état observé de la gousse. Ces données peuvent ne pas être à jour.
Peuplé par le système. Lecture seule. Plus d'infos:
http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#spec-and-status

apiVersion <chaîne>
APIVersion définit le schéma versionné de cette représentation d'un
objet. Les serveurs doivent convertir les schémas reconnus vers la dernière version interne
et peut rejeter des valeurs non reconnues. Plus d'infos:
http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#resources

genre <chaîne>
Kind est une valeur de chaîne représentant la ressource REST de cet objet
représente. Les serveurs peuvent déduire cela du point final soumis par le client
demande. Ne peut être mis à jour. Dans CamelCase. Plus d'infos:
http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#types-kinds

# obtenir la description du champ d'affinité
$ oc explique pod.spec.affinity
RESSOURCE: affinité <Objet>

DESCRIPTION:
Si spécifié, les contraintes de planification du pod

L'affinité est un groupe de règles de planification d'affinité.

CHAMPS:
nodeAffinity <Object>
Décrit les règles de planification d'affinité de nœud pour le pod.

podAffinity <Object>
Décrit les règles de programmation d'affinité des pods (par exemple, colocaliser ce pod dans le
même noeud, zone, etc. comme certains autres pods).

podAntiAffinity <Objet>
Décrit les règles de planification anti-affinité des pods (par exemple, évitez de placer ce pod
dans le même nœud, zone, etc. comme certains autres pods).

6. Oubliez grep, awk, cut, etc.

Une autre fonctionnalité intéressante de la commande oc est les fonctions de formatage de sortie intégrées. Tout le monde connaît les options -o json ou -o yaml , mais le drapeau -o a de nombreuses autres options.

Les plus puissants sont probablement go-template et jsonpath :

json|yaml|wide|name|custom-columns=...|custom-columns-file=...|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...

Supposons que vous souhaitiez savoir quel service est fourni par une route spécifique (la route du registre des dockers):

# , , my-docker-registry.example.com
$ oc get routes -o=go-template='{{range .items}}{{if eq .spec.host "my-docker-registry.example.com"}}{{.metadata.name}}{{end}}{{end}}'
docker-registry

Ou, disons que vous devez connaître la stratégie de déploiement du routeur dc router:

#
$ oc get dc router -o=go-template='{{ .spec.strategy.type }}'
Rolling

Comme vous pouvez le voir, oc est une équipe incroyable. Cela vaut vraiment la peine de jouer avec, car c'est l'une des choses les plus cool d'OpenShift.

Si vous souhaitez en savoir plus sur les fonctionnalités intéressantes d'OpenShift, nous vous recommandons de consulter notre blog des développeurs Red Hat - vous y trouverez non seulement des articles de nos développeurs sur presque tous les sujets, mais également un énorme catalogue de littérature gratuite . Et vous pouvez rafraîchir notre article sur la façon de déployer Minishift sur votre ordinateur portable et de commencer à vivre .