Au début de cette semaine
, la prochaine version de Kubernetes a
eu lieu , qui a été surnommée «angélique»,
1.13 . Ce nom est associé au nombre 113, qui
est considéré comme «angélique» et, selon les développeurs de Kubernetes, symbolise «de nouveaux commencements, la transformation et la fin d'un chapitre avant d'en ouvrir de nouveaux». Sans entrer dans une analyse plus approfondie du symbolisme de ce qui se passe, selon la tradition déjà établie pour notre blog, nous rendrons compte pour la septième fois des changements clés dans la nouvelle version de Kubernetes, qui sont conçus pour plaire aux ingénieurs DevOps / SRE travaillant avec ce produit.
En tant que sources d'informations, nous avons exploité les données du
suivi des améliorations de Kubernetes , du
tableau CHANGELOG-1.13 et des problèmes connexes, des demandes d'extraction, des propositions d'amélioration de Kubernetes (KEP).
GA pour kubeadm
L'un des principaux événements de la version Kubernetes 1.13 a été l'annonce d'un état stable (General Availability, GA) pour l'
utilitaire de console
kubeadm . Le blog K8s y a même consacré une
publication séparée . Comme beaucoup de gens le savent, kubeadm est un outil pour créer des clusters Kubernetes selon les meilleures pratiques du projet, ainsi que leur support minimal supplémentaire. Une caractéristique distinctive est que les développeurs s'efforcent de le garder compact et indépendant du fournisseur / de l'infrastructure, sans inclure de solutions à des problèmes tels que les infrastructures d'approvisionnement, les solutions réseau tierces, les modules complémentaires (surveillance, journalisation, etc.), les intégrations spécifiques avec le cloud prestataires.
Le statut GA a marqué la maturité du kubeadm dans les domaines suivants:
- interface de console stable qui suit la politique d'obsolescence de Kubernetes: les commandes et drapeaux présentés dans la version GA doivent être pris en charge pendant au moins un an après leur dépréciation;
- implémentation stable "sous le capot" du fait que le cluster est créé par des méthodes qui ne changeront pas dans un avenir proche: le plan de contrôle démarre autant de pods statiques, des jetons de bootstrap sont utilisés pour la
kubeadm join et ComponentConfig est utilisé pour configurer kubelet; - schéma de configuration avec une nouvelle API (v1beta1), qui permet de décrire de manière déclarative presque tous les composants de cluster (GitOps est possible pour les clusters créés avec kubeadm) - une mise à niveau vers la version v1 est prévue sans ou avec des changements minimes;
- les soi-disant phases (ou interface de boîte à outils ) dans kubeadm (
kubeadm init phase ), vous permettant de choisir les procédures d'initialisation à effectuer; kubeadm upgrade équipe de kubeadm upgrade garantit les mises à jour du cluster entre les versions 1.10.x, 1.11.x, 1.12.x et 1.13.x (mises à jour etcd, API Server, Controller Manager et Scheduler);- installation sécurisée de etcd par défaut (il utilise TLS partout) avec la possibilité de s'étendre au cluster HA si nécessaire.
On peut également noter que kubeadm reconnaît désormais correctement Docker 18.09.0 et ses versions les plus récentes. Enfin, les développeurs demandent aux utilisateurs de kubeadm de répondre à une petite
enquête en
ligne dans laquelle ils peuvent exprimer leurs souhaits sur l'utilisation et le développement du projet.
CoreDNS par défaut
CoreDNS, qui a reçu un statut stable dans la version
Kubernetes 1.11 , est allé encore plus loin et
est devenu le serveur DNS par défaut dans K8s (au lieu des kube-dns utilisés jusqu'à présent). Il était prévu que cela se produise dès la 1.12, mais les développeurs étaient confrontés au besoin d'optimisations supplémentaires en termes d'évolutivité et de consommation de mémoire, qui n'ont été achevées que par la version actuelle.
La prise en charge de kube-dns continuera "pour au moins une prochaine version", mais les développeurs parlent de la nécessité
de commencer la migration vers une solution à jour maintenant.
Parmi les modifications liées à la rubrique CoreDNS dans Kubernetes 1.13, le
plug- in
NodeLocal DNS Cache peut également
être noté pour améliorer les performances DNS. L'amélioration est obtenue en exécutant un agent sur les nœuds du cluster pour le cache DNS, qui sera accessible directement par les pods de ce nœud. Par défaut, la fonction est désactivée et pour l'activer, vous devez définir
KUBE_ENABLE_NODELOCAL_DNS=true .
Installations de stockage
Une grande attention dans les dernières versions de Kubernetes est accordée à l'utilisation de
Container Storage Interface (CSI), qui a commencé avec la version alpha de CSI dans
K8s 1.9 , a continué avec la version bêta à
1.10 ... Cependant, nous avons déjà
écrit à ce sujet plus
d'une fois . Une nouvelle étape importante a été franchie dans les K8 1.13: le
support CSI est déclaré stable (GA).
(Diagramme de l'article « Comprendre l'interface de stockage de conteneurs »)Parallèlement à cela, la prise en charge de la spécification CSI v1.0.0 est apparue et la prise en charge des anciennes versions de la norme (0.3 et antérieures) a été déconseillée. Cela signifie que les anciens pilotes CSI nécessiteront une mise à niveau vers CSI 1.0 (et un déplacement vers le nouveau répertoire d'enregistrement du plug-in Kubelet) pour fonctionner dans Kubernetes 1.15 et versions antérieures. Soit dit en passant, à partir des pilotes eux-mêmes, il convient de noter l'
apparition de la version alpha de l'interface CSI pour gérer le cycle de vie des volumes AWS EBS (Elastic Block Store).
Un nouvel ajout au gestionnaire d'extensions installe désormais automatiquement CRI à partir de CSI si au moins l'une des deux portes de fonctionnalité est activée:
CSIDriverRegistry et
CSINodeInfo . Il a le statut de la version alpha, mais en fait ce n'est qu'une solution temporaire au problème, décrit en détail comme
un mécanisme d'installation CRD .
La planification du volume basée sur la topologie (
Topology Aware Volume Scheduling ), dont nous avons parlé dans le contexte de la version
Kubernetes 1.10 , est
devenue stable . En bref, l'ordonnanceur dans son travail prend en compte les limites de la topologie du volume du pod (par exemple, sa zone et son nœud).
L'
opportunité introduite dans
Kubernetes 1.9 d' utiliser
des périphériques bruts bloqués (pas le réseau) en tant que volumes persistants a
été traduite en version bêta et est désormais activée par défaut.
Nous concluons le sujet du stockage par le fait que la prise en charge de GCERegionalPersistentDisk est
déclarée stable.
Noeuds de cluster
La version alpha de la
prise en charge des plug-ins de surveillance d'appareils tiers a été introduite. L'idée derrière cette initiative est de faire ressortir des connaissances spécifiques à l'appareil
de l'arbre de Kubelet. Les administrateurs de cluster recevront des métriques signalées par les plugins de périphérique au niveau du conteneur, et les fabricants pourront créer ces métriques sans avoir à apporter de modifications au noyau Kubernetes. Les détails de l'implémentation se trouvent dans la proposition, appelée
API de métadonnées Kubelet .
Déclaré stable,
Kubelet Plugin Watcher (également connu sous le nom d'enregistrement de plug-in de
périphérique Kubelet) permet aux plug-ins de niveau nœud (plug-ins de périphérique, CSI et CNI) de communiquer avec Kubelet à leur sujet.
Une nouvelle fonctionnalité en état alpha est
NodeLease . Si auparavant le «battement de cœur» d'un nœud était déterminé par NodeStatus, alors avec une nouvelle fonctionnalité, chaque nœud a un objet
Lease associé (dans l'espace de noms
kube-node-lease ), qui est périodiquement mis à jour par le nœud. «Pulse» est désormais défini par les deux paramètres: l'ancien NodeStatus, qui n'est signalé au maître qu'en cas de changement ou par un timeout fixe (par défaut c'est une fois par minute), et un nouvel objet (il est mis à jour fréquemment). Étant donné que cet objet est très petit, il améliorera considérablement l'évolutivité et les performances. Les auteurs se sont mis à créer une nouvelle «impulsion» après avoir testé des clusters avec une taille de plus de 2 000 nœuds, qui pendant leur travail pourraient reposer sur les limites etcd, pour plus de détails, voir
KEP-0009 .
type Lease struct { metav1.TypeMeta `json:",inline"` // Standard object's metadata. // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata // +optional ObjectMeta metav1.ObjectMeta `json:"metadata,omitempty"` // Specification of the Lease. // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status // +optional Spec LeaseSpec `json:"spec,omitempty"` } type LeaseSpec struct { HolderIdentity string `json:"holderIdentity"` LeaseDurationSeconds int32 `json:"leaseDurationSeconds"` AcquireTime metav1.MicroTime `json:"acquireTime"` RenewTime metav1.MicroTime `json:"renewTime"` LeaseTransitions int32 `json:"leaseTransitions"` }
(La spécification compacte du nouvel objet pour représenter l '"impulsion" du nœud - Lease - est identique à LeaderElectionRecord )La sécurité
La version alpha de
Dynamic Audit Control suit les idées de Dynamic Admission Control et fournit une configuration dynamique de capacités d'audit avancées - pour cela, vous pouvez maintenant enregistrer (dynamiquement) un webhook qui recevra un flux d'événements. La nécessité de cette fonctionnalité s'explique par le fait que l'audit Kubernetes offre des fonctionnalités très puissantes, mais elles sont difficiles à configurer, et chaque changement de configuration nécessitait toujours un redémarrage d'apiserver.
Le chiffrement des données dans etcd (voir la documentation officielle ) a été transféré du statut expérimental à la version bêta.
kind: EncryptionConfiguration apiVersion: apiserver.config.k8s.io/v1 resources: - resources: - secrets providers: - identity: {} - aesgcm: keys: - name: key1 secret: c2VjcmV0IGlzIHNlY3VyZQ== - name: key2 secret: dGhpcyBpcyBwYXNzd29yZA== - aescbc: keys: - name: key1 secret: c2VjcmV0IGlzIHNlY3VyZQ== - name: key2 secret: dGhpcyBpcyBwYXNzd29yZA== - secretbox: keys: - name: key1 secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
(Un exemple de configuration avec des données chiffrées est tiré de la documentation .)Parmi les innovations les moins significatives de cette catégorie:
- Apiserver peut maintenant être configuré pour refuser les demandes qui ne peuvent pas entrer dans les journaux d'audit.
PodSecurityPolicy objets PodSecurityPolicy ont PodSecurityPolicy ajoutés avec la prise en charge de la règle MayRunAs pour les options fsGroup et supplementalGroups , qui permet de définir la plage d'identificateurs de groupe autorisés (GID) pour les pods / conteneurs sans forcer le GID par défaut. De plus, avec PodSecurityPolicy , la stratégie RunAsGroup est désormais possible dans la spécification des RunAsGroup , c'est-à-dire Vous pouvez contrôler le GID principal pour les conteneurs.- Pour kube-scheduler, nous avons remplacé le port non sécurisé précédent (10251) par le nouveau port sécurisé (10259) et l'avons activé par défaut. Si aucun indicateur supplémentaire n'est spécifié, lors du chargement, des certificats auto-signés sont créés pour lui en mémoire.
CLI
La
kubectl diff ,
montrant la différence entre la configuration locale et la description actuelle de l'objet de travail (fonctionne et récursivement pour les répertoires avec des configurations), a reçu le statut bêta.
En fait,
diff "prédit" les changements qui seront effectués avec la
kubectl apply , et une autre nouvelle fonctionnalité est
utilisée -
APIServer DryRun . Son essence - démarrage inactif - devrait être claire d'après le nom, et une description plus détaillée est disponible dans la
documentation de Kubernetes . Soit dit en passant, dans la version 1.13, la fonction DryRun a également été «mise à niveau» vers la version bêta et activée par défaut.
Et une autre avancée vers la version bêta dans le monde de la console de Kubernetes a affecté le
nouveau mécanisme de plugin . En cours de route, ils ont
corrigé l' ordre de sortie des plugins (
kubectl plugin list des plugins
kubectl plugin list ), supprimant le tri supplémentaire à partir de là.
De plus, la sortie des ressources de
stockage éphémère utilisées a été
ajoutée au
kubectl describe node , et les volumes de type
projetés ont été ajoutés à la
kubectl describe pod .
Autres changements
La fonction de planification
Tiction Based Eviction a été convertie en état bêta et est activée par défaut après une
longue accalmie en développement. Son but est d'ajouter automatiquement des
taches aux nœuds (via NodeController ou kubelet) lors de l'apparition de certaines conditions, telles que, par exemple,
node.kubernetes.io/not-ready , qui correspond à la valeur
NodeCondition dans
Ready=False .
Une annotation de pods critiques pour le fonctionnement du cluster -
critical-pod - est obsolète. Au lieu de cela, il est proposé d'utiliser des
priorités (en version bêta avec Kubernetes 1.11) .
Pour AWS pour la première fois (dans le cadre des versions alpha), les éléments suivants sont devenus disponibles:
- intégration pour AWS ALB (Application Load Balancer) avec les ressources Kubernetes Ingress - aws-alb-ingress-controller (le projet a été initialement créé par Ticketmaster et CoreOS pour migrer le premier vers le cloud AWS);
- CCM externe AWS (Cloud Controller Manager) - cloud-provider-aws , qui est responsable du lancement des contrôleurs avec la fonctionnalité de fournisseur spécifique au cloud (AWS).
SIG Azure a implémenté une prise en charge supplémentaire pour Azure Disk (Ultra SSD, Standard SSD et Premium Azure Files) et a promu les
nœuds du groupe de ressources croisées en version bêta. De plus, les plugins CNI pour Windows ont désormais
la possibilité de configurer DNS dans un conteneur.
La compatibilité
- La version etcd est 3.2.24 (n'a pas changé depuis Kubernetes 1.12).
- Versions vérifiées de Docker - 1.11.1, 1.12.1, 1.13.1, 17.03, 17.06, 17.09, 18.06 (également inchangées).
- Go version - 1.11.2, coïncide avec le minimum pris en charge.
- La version CNI est 0.6.0.
- La version CSI est 1.0.0.
- La version CoreDNS est 1.2.6.
PS
Lisez aussi dans notre blog: