$ kubectl create deploy webserver --image nginx

deploy.apps/webserver créé

$ kubectl expose déployer le serveur Web --port 80

service/serveur Web exposé

$ kubectl obtenir svc

NOM TYPE CLUSTER-IP EXTERNE-IP PORT(S) AGE

Gouverneurs ClusterIP 10.96.0.1 443 / TCP 33d

serveur web ClusterIP 10.103.175.171 80/TCP 4s $

Les services sélectionnent les pods à l'aide d'étiquettes et, pour chaque pod, créent une ressource de point de terminaison. La ressource de point de terminaison décrit toutes les cibles réseau actives (pods) vers lesquelles le service achemine le trafic. Chaque objet de point de terminaison dans un cluster place une règle iptables supplémentaire avec l'adresse IP d'un pod cible. Les EndpointSlices constituent une alternative aux points de terminaison. Les EndpointSlices sont conceptuellement et fonctionnellement similaires aux points de terminaison, mais sont limités à 100 points de terminaison pour améliorer la gestion à grande échelle.

$ kubectl obtient le serveur Web des points de terminaison

NOM VALEURS TERMINALES ÂGE

serveur Web 10.32.0.8:80 43s

$ kubectl get pods -o wide -l app=webserver

NOM ÉTAT PRÊT REDÉMARRAGE ÂGE NUD IP NUD NOMINÉ PORTES DE PRÉPARATION

webserver-d698d7bd6-ktxvn 1/1 Exécution 0 83s 10.32.0.8 ubuntu

$

Les entrées sont une autre ressource qui interagit avec les services. Les entrées lient les services aux points de terminaison externes qu'un contrôleur d'entrée sur le cluster expose ensuite au monde extérieur. Les entrées référencent les services directement dans leurs manifestes, comme indiqué ici :

apiVersion : networking.k8s.io/v1beta1

genre : entrée

métadonnées :

nom : entrée du serveur Web

annotations :

spécification :

règles:

- http:

chemins :

- chemin : /testpath

arrière-plan :

nom du service : serveur Web

port de service : 80

Contrôleurs d'entrée et ressources d'entrée

La ressource Ingress gère l'accès externe aux services Kubernetes via des routes HTTP et HTTPS. Un contrôleur d'entrée est requis pour satisfaire une entrée. Le contrôleur Ingress lit et implémente les règles de la ressource Ingress. Utilisez la commande suivante pour configurer un contrôleur d'entrée dans votre cluster Kubernetes :

$ kubectl s'applique -f https://rx-m-k8s.s3-us-west-2.amazonaws.com/ingress-drill-setup.yaml

espace de noms/nginx-ingress créé

serviceaccount/nginx-ingress créé

clusterrole.rbac.authorization.k8s.io/nginx-ingress créé

service/nginx-ingress créé

clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress créé

secret/default-server-secret créé

deploy.apps/nginx-ingress créé

$

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.Créez le déploiement suivant du serveur Web Apache qui expose le port de conteneur 80 :

$ kubectl create deploy apache-webserver --image=httpd --port=80

deploy.apps/apache-webserver créé

$

Créez un service NodePort pour exposer le déploiement apache-webserver sur le port de nœud 30111 et mapper le port 80 sur le ClusterIP au port 80 sur le conteneur :

$ kubectl create service nodeport apache-webserver --tcp=80:80 --node-port=30111

service/serveur web apache créé

$

Créez la ressource Ingress suivante pour le service apache-webserver qui contrôle le trafic vers le domaine hôte www.example.com, expose un chemin de préfixe http vers /, achemine tout le trafic envoyé vers www.example.com:30111/ vers apache-webserver Service sur le port 80:ner :

$ nano apache-webserver-ingress.yaml && apache-webserver-ingress.yaml

apiVersion : networking.k8s.io/v1

genre : entrée

métadonnées :

nom : apache-weberver-ingress

spécification :

règles:

- hébergeur : www.exemple.com

http:

chemins :

- pathType : Préfixe

chemin: /

arrière-plan :

service:

nom : serveur web apache

Port:

nombre : 80

$ kubectl applique -f apache-webserver-ingress.yaml

ingress.networking.k8s.io/apached-webserver-ingress créé

$

Testez les règles d'entrée avec curl --resolve www.example.com:30111: http://www.example.com:30111/ :

$ curl --resolve www.example.com:30111: http://www.example.com:30111

Ça marche!

$

Découverte de services avec CoreDNS

Kubernetes utilise CoreDNS pour la découverte de services basée sur DNS. CoreDNS est flexible et des modifications peuvent être apportées dans le ConfigMap pour CoreDNS. Chaque service se voit attribuer un nom DNS dans la syntaxe : . .svc.cluster.local . Les pods se voient attribuer un enregistrement DNS A dans la syntaxe suivante : . .pod.cluster.local . Confirmons l'entrée DNS d'un service avec une recherche de serveur de noms avec nslookup depuis un pod. Créez un service ClusterIP pour tester son entrée DNS et récupérer son ClusterIP :

$ kubectl create service clusterip my-service --tcp=8080:8080

service/mon-service créé

$ kubectl obtenir un service

NOM TYPE CLUSTER-IP EXTERNE-IP PORT(S) AGE

Gouverneurs ClusterIP 10.96.0.1 443 / TCP 10d

mon-service ClusterIP 10.109.165.220 8080/TCP 5m31s

$

Exécutez un pod avec l'image busybox et exécutez un nslookup sur l'IP du service :

$ kubectl lance busybox --image=busybox -it -- /bin/sh

Si vous ne voyez pas d'invite de commande, essayez d'appuyer sur Entrée.

/ # nslookup 10.109.165.220

Serveur : 10.96.0.10

Adresse : 10.96.0.10:53

220.165.109.10.in-addr.arpa name = my-service.default.svc.cluster.local

/ # sortir

$

Gérer les certificats TLS pour les composants de cluster

Tous les composants du cluster qui doivent communiquer avec le serveur d'API doivent s'authentifier à l'aide d'un certificat signé par le certificat CA du cluster. Chaque certificat CA doit contenir l'utilisateur en tant que nom de sujet et un groupe en tant qu'organisation. Le certificat CA qui signe tous les certificats de composants d'un cluster kubeadm se trouve sous /etc/kubernetes/pki. Les clusters Kubeadm distribuent automatiquement les certificats signés CA de cluster à tous les composants du plan de contrôle au démarrage. Les certificats de cluster sont temporairement stockés dans le cluster en tant que secrets jusqu'à 2 heures après le démarrage. Pour recharger les certificats de cluster afin de créer un nouveau nœud maître, kubeadm peut réexécuter la phase upload-certs :

$ sudo kubeadm phase d'initialisation upload-certs --upload-certs

[upload-certs] Stockage des certificats dans Secret "kubeadm-certs" dans l'espace de noms "kube-system"

[upload-certs] Utilisation de la clé de certificat :

7d42b0fbecf1f12597591513e6b1e1009fd46bd617f33679c050abe30310b006

$

Ensuite, créez une commande de jointure sur le nœud maître à l'aide de la clé de certificat pour générer une commande de jointure pour des nœuds de plan de contrôle supplémentaires :

$ sudo kubeadm token create --print-join-command --certificate-key 7d42b0fbecf1f12597591513e6b1e1009fd46bd617f33679c050abe30310b006

kubeadm rejoindre 192.168.229.134:6443 \

--token yrl04z.14yaclt7m8hljjpw \

--discovery-token-ca-cert-hash sha256:50fecf38c50b760131e7ff3ae6c80d89aa01243e9c6c1d634077eedeb4940929 \

--avion de contrôle \

--certificate-key 7d42b0fbecf1f12597591513e6b1e1009fd46bd617f33679c050abe30310b006

$

Cette commande de jointure indique à kubeadm de demander aux nouveaux nœuds de travail de télécharger les certificats. Pour les nœuds de travail, le processus est le même ; l'utilisation de kubeadm join indique au kubelet du nœud cible d'effectuer une amorce TLS pour demander automatiquement un nouveau certificat au cluster.

Travaillez avec des images en toute sécurité

La sécurité des images est gérée de différentes manières. Une façon consiste à contrôler l'accès aux référentiels privés à l'aide d'imagePullSecret , qui contient les informations d'identification nécessaires pour accéder à un référentiel. Un secret d'extraction d'image est basé sur le fichier config.json de Docker, qui est créé après avoir utilisé docker login . Vous pouvez créer une imagePullSecret impérativement en fournissant vos identifiants à :

$ kubectl create secret docker-registry myregistry \

--docker-server=https://my.image.registry \

--docker-username=mon-utilisateur --docker-password=mon-pw \

--docker-email=myacc@image.registry

$

Les images de conteneur qui doivent être extraites du registre privé my.image.registry récupèrent ces informations d'identification à l'aide de la clé imagePullSecret dans leur spécification : :

apiVersion : v1

genre: Pod

métadonnées :

creationTimestamp : null

Étiquettes:

exécuter : fluentbitcommandpod

nom: fluentbitcommandpod

spécification :

conteneurs :

- commande :

- /bit-fluent/bin/bit-fluent

- -je

- meme

- -O

- sortie standard

image: monregistre/mon-bit-fluent

nom: fluentbitcommandpod

imagePullSecrets :

- nom : monregistre

Les images de conteneurs peuvent être référencées à l'aide du hachage sha256 de l'image. Cela indique au runtime du conteneur d'utiliser une version exacte de l'image à tout moment. Voici un exemple de mise à jour d'un déploiement Kubernetes à l'aide d'une image SHA spécifique :

kubectl set image deploy nginx-prod nginx=myregistry/nginx@sha256:2397b05f8a7df1cf48d51314a5e2c249f1e83a4211cd78ceb58e8372bf087f07 --record=true

Contextes de sécurité

Les contextes de sécurité définissent les paramètres de privilège et de contrôle d'accès pour un pod ou un conteneur. Un tableau securityContext dans une spécification de conteneur sous un pod permet un contrôle granulaire sur l'utilisateur ou le groupe avec lequel un conteneur s'exécute, les autorisations accordées à ces utilisateurs et d'autres options telles que l'accès au système de fichiers ou la possibilité de s'exécuter en tant que root. Pour spécifier un securityContext, incluez la clé securityContext dans un manifeste de pod ou de conteneur :

apiVersion : v1

genre: Pod

métadonnées :

nom : cka-security-context

spécification :

conteneurs :

- nom : sec-ctx-demo

image : boîte occupée

commande : [ "sh", "-c", "sommeil 1h" ]

securityContext :

allowPrivilegeEscalation : false

securityContext :

runAsUser : 1000

Les contextes de sécurité permettent d'ajuster la posture et la capacité de sécurité des pods et des conteneurs. Par exemple, le pod de la spécification ci-dessus s'exécute en tant qu'utilisateur non root et le conteneur n'est pas autorisé à utiliser l'élévation des privilèges (mécanismes comme sudo).

Stockage sécurisé de valeur de clé persistante

Le magasin clé-valeur persistant dans Kubernetes est etcd. Seul le serveur d'API a accès à l'instance etcd s'exécutant dans un cluster. L'accès à etcd est limité aux principaux porteurs d'un certificat signé par l'autorité de certification etcd. Dans les clusters kubeadm, les certificats etcd se trouvent sous /etc/kubernetes/pki/etcd. Un client doit fournir le certificat CA ainsi qu'une clé et un certificat client pour contacter l'instance etcd depuis l'extérieur du cluster Kubernetes. Un moyen infaillible d'y parvenir est d'imiter l'accès du serveur API :

$ ps-ef | poignée "cube-apiserver"

racine 3288 3219 1 fév25? 00:23:11 être apiserver

…

--etcd-cafile = /etc/kubernetes/pki/etcd/ca.crt

--etcd-certfile = / etc / kubernetes / pki / apiserver-etcd-client.crt

--etcd-keyfile = / etc / kubernetes / pki / apiserver-etcd-client.key

--etcd-servers=https://127.0.0.1:2379

...

$

Etcd utilise son propre certificat CA ; tous les clients qui doivent se connecter à etcd doivent avoir un certificat signé par cette autorité de certification pour communiquer avec etcd. En fournissant ces certificats, vous pouvez utiliser un client externe comme etcdctl pour interagir avec le cluster etcd :

$ liste des membres sudo etcdctl \

--endpoints 127.0.0.1:2379 \

--cacert /etc/kubernetes/pki/etcd/ca.crt \

--cert /etc/kubernetes/pki/apiserver-etcd-client.crt \

--key /etc/kubernetes/pki/apiserver-etcd-client.key

f093f1e641b93448, démarré, ubuntu, https://192.168.229.134:2380, https://192.168.229.134:2379, faux

$

Exercice d'entraînement

Exécutez la commande suivante : kubectl run --generator run-pod/v1 --image nginx nginx-drill Créez un service NodePort qui vous permet d'envoyer une requête curl au pod nginx-drill sur le port 80 via l'adresse IP de votre machine.

Exercice d'entraînement : réponse

$ Tout d'abord, exécutez la commande pour créer le pod :

$ kubectl exécuter nginx-drill --image nginx

pod/nginx-drill créé

$

Ensuite, utilisez kubectl expose avec le drapeau --type NodePort pour créer impérativement un service nodePort. Assurez-vous d'exposer le pod, car il a été créé par la commande run initiale :

$ kubectl expose --type NodePort --port 80 pod nginx-drill

service/nginx-drill exposé

$

Après avoir exposé le pod, répertoriez les services. Vous verrez que le service nginx-drill NodePort mappe le port 80 sur un port compris dans la plage de 30 000 :

$ kubectl obtenir svc

NOM TYPE CLUSTER-IP EXTERNE-IP PORT(S) AGE

Gouverneurs ClusterIP 10.96.0.1 443 / TCP 33d

nginx-drill NodePort 10.101.103.201 80:32402/TCP 10s

$

Enfin, essayez d'envoyer une requête curl au pod nginx en utilisant l'adresse IP de votre machine :

$ ip en tant que | diriger

1 : voici : mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1

lien/bouclage 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

valid_lft pour toujours prefer_lft pour toujours

inet6 ::1/128 champ hôte

valid_lft pour toujours prefer_lft pour toujours

2 : ens33 : mtu 1500 qdisc pfifo_fast état groupe UP par défaut qlen 1000

lien/éther 00 : 0c : 29 : b3 : d9 : 13 brd ff : ff : ff : ff : ff : ff

inet 192.168.229.134/24 brd 192.168.229.255 portée globale ens33

valid_lft pour toujours prefer_lft pour toujours

$ boucle 192.168.229.134:32402

corps {

largeur : 35em ;

marge : 0 automatique ;

famille de polices : Tahoma, Verdana, Arial, sans-serif ;

}

Bienvenue à Nginx!

Si vous voyez cette page, le serveur Web nginx est installé avec succès et

travail. Une configuration supplémentaire est requise.

Pour la documentation et l'assistance en ligne, veuillez vous référer à

nginx.org.

Une assistance commerciale est disponible sur

nginx.com.

Merci d'avoir utilisé nginx.

$

Comme autre exercice, créez un service ClusterIP appelé other-svc à l'aide de kubectl create et utilisez un sélecteur d'étiquette pour l'associer au déploiement nginx-drill créé ci-dessus.