Dans ce court TP nous allons redéployer notre application demonstration
du TP1 mais cette fois en utilisant kubectl apply -f
et en visualisant le résultat dans Lens
.
N’hésitez pas aussi à observer les derniers évènements arrivés à votre cluster avec kubectl get events --watch
.
kubectl config use-context k3s
ou kubectl config use-context default
Lens
en cliquant à nouveau sur plus et en selectionnant k3s
ou default
demonstration
et demonstration-service
du TP1TP2_deploy_using_files_and_Lens
sur le bureau de la machine distante et ouvrez le avec VSCode
.Nous allons d’abord déployer notre application comme un simple Pod (non recommandé mais montré ici pour l’exercice).
demo-pod.yaml
avec à l’intérieur le code d’exemple suivant :rancher-demo-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: rancher-demo-pod
spec:
containers:
- image: monachus/rancher-demo:latest
name: rancher-demo-container
ports:
- containerPort: 8080
name: http
protocol: TCP
- image: redis
name: redis-container
ports:
- containerPort: 6379
name: http
protocol: TCP
kubectl apply -f <fichier>
rancher-demo
et réappliquez la configuration. Que se passe-t-il ?=> Kubernetes refuse d’appliquer le nouveau nom de conteneur car un pod est largement immutable. Pour changer d’une quelquonque façon les conteneurs du pod il faut supprimer (kubectl delete -f <fichier>
) et recréer le pod. Mais ce travail de mise à jour devrais être géré par un déploiement pour automatiser et pour garantir la haute disponibilité de notre application demonstration
.
Kubernetes fournit un ensemble de commande pour débugger des conteneurs :
kubectl logs <pod-name> -c <conteneur_name>
(le nom du conteneur est inutile si un seul)
kubectl exec -it <pod-name> -c <conteneur_name> -- bash
kubectl attach -it <pod-name>
Explorez le pod avec la commande kubectl exec -it <pod-name> -c <conteneur_name> -- bash
écrite plus haut.
Supprimez le pod.
demo-deploy.yaml
avec à l’intérieur le code suivant à compléter:apiVersion: apps/v1
kind: Deployment
metadata:
name: demonstration
labels:
nom-app: demonstration
partie: objet-deploiement
spec:
selector:
matchLabels:
nom-app: demonstration
partie: les-petits-pods-demo
strategy:
type: Recreate
replicas: 1
template:
metadata:
labels:
nom-app: demonstration
partie: les-petits-pods-demo
spec:
containers:
- image: <image>
name: <name>
ports:
- containerPort: <port>
name: demo-http
demo-svc.yaml
avec à l’intérieur le code suivant à compléter:apiVersion: v1
kind: Service
metadata:
name: demo-service
labels:
nom-app: demonstration
partie: le-fameux-service-demo
spec:
ports:
- port: <port>
selector:
nom-app: demonstration
partie: les-petits-pods-demo
type: NodePort
nom-app: demonstration
et partie: les-petits-pods-demo
à remplacer dans le fichier ) et réappliquez.None
)=> Les services kubernetes redirigent le trafic basés sur les étiquettes (labels) appliquées sur les pods du cluster. Il faut donc de même éviter d’utiliser deux fois le même label pour des parties différentes de l’application.
Le dépôt Git de la correction de ce TP est accessible ici : git clone -b correction_k8s_tp2 https://github.com/Uptime-Formation/corrections_tp.git