Marques
Catégories de formation
Technique Microsoft
Utilisateur final Microsoft
Dans ce module du cours de préparation en ligne CKA Broad Skills, nous couvrirons les sujets d'architecture, d'installation et de configuration du cluster identifiés par le programme d'examen CNCF CKA. Si vous n'êtes pas déjà familiarisé avec le programme, prenez un moment pour vous familiariser, car vous devrez connaître chacun des sujets afin de réussir le test.
Les rôles, ClusterRoles, RoleBinding et ClusterRoleBindings contrôlent les autorisations de compte d'utilisateur qui contrôlent la manière dont ils interagissent avec les ressources déployées dans le cluster. ClusterRoles et ClusterRoleBindings sont des ressources sans espace de noms. Roles and RoleBindings définit des autorisations et des autorisations de liaison dans un espace de noms spécifique. Kubernetes utilise des mécanismes de contrôle d'accès basé sur les rôles (RBAC) pour contrôler la capacité des utilisateurs à effectuer une tâche spécifique sur les objets Kubernetes. Les clusters amorcés avec kubeadm ont RBAC activé par défaut. Les autorisations sur les ressources d'API sont accordées à l'aide de rôles et de rôles de cluster (la seule différence étant que clusterRoles s'applique à l'ensemble du cluster tandis que les rôles normaux s'appliquent à leur espace de noms). Les autorisations sont limitées aux ressources API et aux objets sous les ressources API. Les verbes contrôlent les opérations pouvant être effectuées par chaque rôle. Les rôles peuvent être créés impérativement à l'aide de kubectl create role . Vous pouvez spécifier les ressources API et les verbes associés aux autorisations que le rôle accordera :
$ kubectl create role default-appmanager --resource pod,deploy,svc,ingresses --verb get,list,watch,create -o yaml
apiVersion : rbac.authorization.k8s.io/v1
genre : Rôle
métadonnées :
nom : default-appmanager
espace de noms : par défaut
règles:
- apiGroupes :
- ""
Ressources:
- les gousses
- prestations de service
verbes:
- avoir
- liste
- Regardez
- créer
- effacer
- apiGroupes :
- applications
Ressources:
- déploiements
verbes:
- avoir
- liste
- Regardez
- créer
- effacer
$
Les rôles et ClusterRoles sont attribués aux utilisateurs et aux processus à l'aide de RoleBindings et ClusterRoleBindings. Les RoleBindings associent un utilisateur, comme un compte de service, à un rôle. Toutes les autorisations accordées par un rôle sont transmises à l'utilisateur via le RoleBinding. Les liaisons de rôle peuvent également être créées impérativement à l'aide de kubectl create rolebinding . Les liaisons de rôles lient les rôles aux utilisateurs à l'aide de l'indicateur --user et serviceAccounts à l'aide de l'indicateur --serviceaccount. L'exemple suivant lie le rôle default-appmanager au compte de service par défaut de l'espace de noms par défaut :
$ kubectl create rolebinding default-appmanager-rb \
--serviceaccount default:default \
--role default-appmanager
rolebinding.rbac.authorization.k8s.io/default-appmanager-rb créé
$
Les mises à niveau de cluster impliquent la mise à jour de la version des composants du plan de contrôle Kubernetes et des kubelets qui s'exécutent sur chaque nœud du cluster. En général, le serveur d'API détermine la version du cluster Kubernetes. Le kubelet peut avoir deux versions mineures plus anciennes que le serveur API. Les autres composants du plan de contrôle peuvent être jusqu'à une version mineure plus ancienne que le serveur d'API. Le client kubectl peut être une version plus récente ou plus ancienne que le serveur API.
Les détails de la politique de prise en charge des versions sont détaillés sur la page de politique de décalage de version dans la documentation Kubernetes.
Pour mettre à niveau le nœud du plan de contrôle, nous devons procéder comme suit :
Voici un exemple de mise à niveau d'un nœud de plan de contrôle Kubernetes de Kubernetes v1.18.0 vers v.19.0 sur Ubuntu 18.04 :
Mettez à jour le dépôt apt :
Mettez à jour le dépôt apt :
$ sudo apt mise à jour
…
$
Installez la nouvelle version de kubeadm, par exemple v1.19.0 :
$ sudo apt install kubeadm = 1.19.0-00
…
$
Vider le nœud du plan de contrôle
$ kubectl drain --ignore-daemonsets
…
$
Exécutez le plan de mise à niveau de kubeadm avec sudo pour vérifier et récupérer les composants du plan de contrôle mis à jour :
$ plan de mise à niveau sudo kubeadm
…
Composants qui doivent être mis à niveau manuellement après avoir mis à niveau le plan de contrôle avec 'kubeadm upgrade apply' :
COMPOSANT COURANT DISPONIBLE
kubelet 1 x v1.18.0 v1.19.1
Passez à la dernière version stable :
COMPOSANT COURANT DISPONIBLE
cube-apiserver v1.18.0 v1.19.1
cube-controller-manager v1.18.0 v1.19.1
être-planificateur v1.18.0 v1.19.1
kube-proxy v1.18.0 v1.19.1
CoreDNS 1.6.7 1.7.0
etcd 3.4.3-0 3.4.9-1
Vous pouvez maintenant appliquer la mise à niveau en exécutant la commande suivante :
la mise à niveau de kubeadm s'applique à la v1.19.1
Remarque : avant de pouvoir effectuer cette mise à niveau, vous devez mettre à jour kubeadm vers la v1.19.1.
_____________________________________________________________________
Le tableau ci-dessous montre l'état actuel des configurations de composants telles qu'elles sont comprises par cette version de kubeadm.
Les configurations qui ont une marque « oui » dans la colonne « MISE À JOUR MANUELLE REQUISE » nécessitent une mise à niveau manuelle de la configuration ou
la réinitialisation aux valeurs par défaut de kubeadm avant qu'une mise à niveau réussie puisse être effectuée. La version à manuellement
la mise à niveau vers est indiquée dans la colonne « VERSION PRÉFÉRÉE ».
GROUPE API VERSION ACTUELLE VERSION PRÉFÉRÉE MISE À NIVEAU DU MANUEL REQUISE
kubeproxy.config.k8s.io v1alpha1 v1alpha1 non
kubelet.config.k8s.io v1beta1 v1beta1 non
_____________________________________________________________________
$
Notez que le kubelet doit être mis à niveau manuellement après la mise à niveau du plan de contrôle.
Nous voyons que la v1.19.1 est disponible mais passons à la v1.19.0 :
$ sudo kubeadm mise à niveau appliquer v1.19.0
…
[mise à niveau/réussie] SUCCÈS ! Votre cluster a été mis à niveau vers "v1.19.0". Prendre plaisir!
[upgrade/kubelet] Maintenant que votre plan de contrôle est mis à niveau, veuillez procéder à la mise à niveau de vos kubelets si vous ne l'avez pas déjà fait.
$
Installez les versions correspondantes de kubelet et kubectl :
$ sudo apt install kubelet = 1.19.0-00 kubectl = 1.19.0-00
…
Configuration de kubelet (1.19.0-00) ...
Configuration de kubectl (1.19.0-00) ...
$
Déconnectez le nœud du plan de contrôle :
$ kubectl uncordon
nœud / sans cordon
$
L'état d'un cluster Kubernetes est contenu dans la ou les instances etcd qui soutiennent le cluster. La sauvegarde d'un cluster Kubernetes consiste à sauvegarder la ou les instances etcd.
Une façon d'effectuer une sauvegarde consiste à utiliser la commande etcdctl :
$ ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/etcd/ca.crt --cert=/etc/etcd/server.crt --key=/etc/etcd/server.key \
sauvegarde d'instantané /var/lib/etcd/backup.db
$
Cette commande se connecte à un cluster etcd et enregistre son contenu dans un fichier de base de données. Ce fichier de base de données est ensuite utilisé pour restaurer l'intégralité du cluster sur un nouvel ensemble de nœuds.
Cette commande se connecte à un cluster etcd et enregistre son contenu dans un fichier de base de données. Ce fichier de base de données est ensuite utilisé pour restaurer l'intégralité du cluster sur un nouvel ensemble de nœuds.