Black lives matter.
We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the core values of the Kubernetes project and our community does not tolerate it.
We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the core values of the Kubernetes project and our community does not tolerate it.
Kubernetes v1.12 [alpha]
Cette page décrit la ressource RuntimeClass et le mécanisme de sélection d'exécution (runtime).
La RuntimeClass est une fonctionnalité alpha permettant de sélectionner la configuration d'exécution du conteneur à utiliser pour exécuter les conteneurs d'un pod.
En tant que nouvelle fonctionnalité alpha, certaines étapes de configuration supplémentaires doivent être suivies pour utiliser la RuntimeClass:
Voir Feature Gates pour une explication
sur l'activation des feature gates. La RuntimeClass
feature gate doit être activée sur les API servers et
les kubelets.
La RuntimeClass CustomResourceDefinition (CRD) se trouve dans le répertoire addons du dépôt Git Kubernetes: kubernetes/cluster/addons/runtimeclass/runtimeclass_crd.yaml
Installer la CRD avec kubectl apply -f runtimeclass_crd.yaml
.
Les configurations à sélectionner avec RuntimeClass dépendent de l'implémentation CRI. Consultez la documentation correspondante pour votre implémentation CRI pour savoir comment le configurer. Comme c'est une fonctionnalité alpha, tous les CRI ne prennent pas encore en charge plusieurs RuntimeClasses.
Note: La RuntimeClass suppose actuellement une configuration de nœud homogène sur l'ensemble du cluster (ce qui signifie que tous les nœuds sont configurés de la même manière en ce qui concerne les environnements d'exécution de conteneur). Toute hétérogénéité (configuration variable) doit être gérée indépendamment de RuntimeClass via des fonctions de planification (scheduling features) (voir Affectation de pods sur les nœuds).
Les configurations ont un nom RuntimeHandler
correspondant , référencé par la RuntimeClass.
Le RuntimeHandler doit être un sous-domaine DNS valide selon la norme RFC 1123 (alphanumériques + -
et .
caractères).
Les configurations effectuées à l'étape 3 doivent chacune avoir un nom RuntimeHandler
associé, qui
identifie la configuration. Pour chaque RuntimeHandler (et optionellement les handlers vides ""
),
créez un objet RuntimeClass correspondant.
La ressource RuntimeClass ne contient actuellement que 2 champs significatifs: le nom RuntimeClass
(metadata.name
) et le RuntimeHandler (spec.runtimeHandler
). la définition de l'objet ressemble à ceci:
apiVersion: node.k8s.io/v1alpha1 # La RuntimeClass est définie dans le groupe d'API node.k8s.io
kind: RuntimeClass
metadata:
name: myclass # Le nom avec lequel la RuntimeClass sera référencée
# La RuntimeClass est une ressource non cantonnées à un namespace
spec:
runtimeHandler: myconfiguration # Le nom de la configuration CRI correspondante
Note: Il est recommandé de limiter les opérations d'écriture sur la RuntimeClass (create/update/patch/delete) à l'administrateur du cluster. C'est la configuration par défault. Voir Vue d'ensemble d'autorisation pour plus de détails.
Une fois que les RuntimeClasses sont configurées pour le cluster, leur utilisation est très simple.
Spécifiez runtimeClassName
dans la spécficiation du pod. Par exemple:
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
runtimeClassName: myclass
# ...
Cela indiquera à la kubelet d'utiliser la RuntimeClass spécifiée pour exécuter ce pod. Si la
RuntimeClass n'existe pas, ou si la CRI ne peut pas exécuter le handler correspondant, le pod passera finalement à
l'état failed
. Recherchez
l'événement correspondant pour un
message d'erreur.
Si aucun runtimeClassName
n'est spécifié, le RuntimeHandler par défault sera utilisé, qui équivaut
au comportement lorsque la fonctionnalité RuntimeClass est désactivée.