Kubernetes - Historique des versions

Justine : /* CertManager */

2022-09-24T09:02:22Z

CertManager

← Version précédente		Version du 24 septembre 2022 à 09:02
Ligne 990 :		Ligne 990 :
	- secretName: gitea-tls		- secretName: gitea-tls
	hosts:		hosts:
	- ~~git~~.~~rznet~~.fr		- wiki.squi.fr
	ingressClassName: nginx		ingressClassName: nginx
	rules:		rules:

Justine : /* CertManager */

2022-09-24T09:01:30Z

CertManager

← Version précédente		Version du 24 septembre 2022 à 09:01
Ligne 956 :		Ligne 956 :
	Une fois fait, un ingress passerait de:		Une fois fait, un ingress passerait de:

	<nowiki>		<nowiki>
	apiVersion: networking.k8s.io/v1		apiVersion: networking.k8s.io/v1
	kind: Ingress		kind: Ingress

Justine : /* Ingress */

2022-09-24T09:00:26Z

Ingress

@@ Ligne 486 : / Ligne 486 : @@
 = Ingress =
 Le principe est le suivant:
 * On a un ingress controller : c'est en somme un ensemble de pods, rassemblés dans leur propre namespace, qui vont jouer le rôle de rp pour nos applications. C'est relativement indispensable. Il en existe plusieurs : nginx, traefik, caddy...
@@ Ligne 584 : / Ligne 587 : @@
 J'ai les logs nginx.
 = Helm =

Justine : /* Chaos-mesh */

2022-08-26T15:44:59Z

Chaos-mesh

← Version précédente		Version du 26 août 2022 à 15:44
Ligne 1 172 :		Ligne 1 172 :
	Sources:		Sources:
	* [https://chaos-mesh.org/docs/production-installation-using-helm/ Install]		* [https://chaos-mesh.org/docs/production-installation-using-helm/ Install]
			* [https://github.com/chaos-mesh/chaos-mesh github]
			* [https://chaos-mesh.org/docs/run-a-chaos-experiment/ Experiments]

	Chaos-mesh est un utilitaire de "chaos engineering" pour k8s. Le chaos engineering est défini comme "Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system's capability to withstand turbulent conditions" : on teste les limites du système en lui imposant des failles et des erreurs pendant une durée déterminée.		Chaos-mesh est un utilitaire de "chaos engineering" pour k8s. Le chaos engineering est défini comme "Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system's capability to withstand turbulent conditions" : on teste les limites du système en lui imposant des failles et des erreurs pendant une durée déterminée.

	Chaos-mesh est assez simple à utiliser, dispose d'une interface web sympathique et semble être une des applications les plus populaires en la matière.		Chaos-mesh est assez simple à utiliser, dispose d'une interface web sympathique et semble être une des applications les plus populaires en la matière. Le principal défaut que j'ai pu y voir pour l'instant est un certain manque de "polish" : les messages d'erreurs sont peu clairs ou contiennent parfois des typos, par exemple.

	== Installation ==		== Installation ==
Ligne 1 221 :		Ligne 1 223 :
	== Token ==		== Token ==
	En arrivant sur le dashboard, on nous demande un token. Le dashboard propose des instructions pour l'obtenir (création d'un rbac, etc); dans mon cas, ça ne fonctionne pas. Peut-être parce que j'utilise le [https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/ dashboard k8s] qui fonctionne sur le même principe. Dans mon cas, j'ai simplement utilisé le token associé au dashboard k8s. Je ne rentre pas dans les détails.		En arrivant sur le dashboard, on nous demande un token. Le dashboard propose des instructions pour l'obtenir (création d'un rbac, etc); dans mon cas, ça ne fonctionne pas. Peut-être parce que j'utilise le [https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/ dashboard k8s] qui fonctionne sur le même principe. Dans mon cas, j'ai simplement utilisé le token associé au dashboard k8s. Je ne rentre pas dans les détails.

			== Utilisation ==
			A compléter / cf https://chaos-mesh.org/docs/run-a-chaos-experiment/

Justine le 26 août 2022 à 15:42

2022-08-26T15:42:02Z

← Version précédente		Version du 26 août 2022 à 15:42
Ligne 1 168 :		Ligne 1 168 :
	Ou la version		Ou la version
	curl -sfL https://get.k3s.io \| INSTALL_K3S_VERSION=vX.Y.Z-rc1 sh -		curl -sfL https://get.k3s.io \| INSTALL_K3S_VERSION=vX.Y.Z-rc1 sh -

			= Chaos-mesh =
			Sources:
			* [https://chaos-mesh.org/docs/production-installation-using-helm/ Install]

			Chaos-mesh est un utilitaire de "chaos engineering" pour k8s. Le chaos engineering est défini comme "Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system's capability to withstand turbulent conditions" : on teste les limites du système en lui imposant des failles et des erreurs pendant une durée déterminée.

			Chaos-mesh est assez simple à utiliser, dispose d'une interface web sympathique et semble être une des applications les plus populaires en la matière.

			== Installation ==
			L'installation passe par helm. Il faut, avant d'installer, savoir quel "container runtime" (en français, je ne sais pas : "environnement d'exécution de conteneurs", disons ?) est utilisé par nos nodes. On peut le savoir avec un:
			kubectl get nodes -o wide
			Dans mon cas, avec mon k3s de base, il s'agit de containerd. Cela pourrait aussi être docker, par exemple.

			Ensuite, l'installation passe par helm. La doc n'est pas ultime : il faut d'une part choisir le bon container runtime, et d'autre part on veut aussi le dashboard web. Donc, avec containerd dans mon cas:
			helm install chaos-mesh chaos-mesh/chaos-mesh --namespace=chaos-testing --create-namespace --set dashboard.create=true --set chaosDaemon.socketPath=/run/containerd/containerd.sock
			* --namespace : les élements vont s'installer dans un namespace nommé "chaos-testing" que l'on créée (--create-namespace)
			* --set dashboard.create=true : on veut le dashboard
			* --set chaosDaemon.socketPath=/run/containerd/containerd.sock : mon container runtime est containerd.
			Ne pas hésiter à voir la doc, cf les sources.

			== Ingress ==
			Helm va créer un service associé au dashboard, que l'on peut voir et décrire:
			k get svc -n chaos-testing
			k describe svc chaos-dashboard -n chaos-testing

			Je vais lui associer l'ingress suivant pour pouvoir y accéder facilement:
			<nowiki>
			apiVersion: networking.k8s.io/v1
			kind: Ingress
			metadata:
			name: chaos-ingr
			annotations:
			nginx.ingress.kubernetes.io/proxy-body-size: 500m
			spec:
			ingressClassName: nginx
			rules:
			- host: chaos.sq.lan
			http:
			paths:
			- pathType: Prefix
			backend:
			service:
			name: chaos-dashboard
			port:
			number: 2333
			path: /
			</nowiki>

			Le dashboard devrait être accessible.

			== Token ==
			En arrivant sur le dashboard, on nous demande un token. Le dashboard propose des instructions pour l'obtenir (création d'un rbac, etc); dans mon cas, ça ne fonctionne pas. Peut-être parce que j'utilise le [https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/ dashboard k8s] qui fonctionne sur le même principe. Dans mon cas, j'ai simplement utilisé le token associé au dashboard k8s. Je ne rentre pas dans les détails.

Justine : /* Ingress */

2022-08-22T15:52:03Z

Ingress

← Version précédente		Version du 22 août 2022 à 15:52
Ligne 511 :		Ligne 511 :
	--repo https://kubernetes.github.io/ingress-nginx \		--repo https://kubernetes.github.io/ingress-nginx \
	--namespace ingress-nginx --create-namespace \		--namespace ingress-nginx --create-namespace \
	--set controller.metrics.enabled=true		--set controller.metrics.enabled=true \
			--set controller.service.externalTrafficPolicy=Local
	</nowiki>		</nowiki>

			(Dans la deuxième version, controller.service.externalTrafficPolicy signifie que même sans le proxy protocol, on remonte les vraies IP des client, pas celle du cluster)

	La différence est que dans le premier car, on utilise [https://www.haproxy.com/fr/blog/using-haproxy-with-the-proxy-protocol-to-better-secure-your-database/ Proxy protocol v2], ce qui est utile pour bien remonter les IPs des clients. Si mon ingress est derrière un RP HAproxy, il faudra alors configurer les backends haproxy avec l'option send-proxy-v2 sur le haproxy qui se trouve devant l'ingress:		La différence est que dans le premier car, on utilise [https://www.haproxy.com/fr/blog/using-haproxy-with-the-proxy-protocol-to-better-secure-your-database/ Proxy protocol v2], ce qui est utile pour bien remonter les IPs des clients. Si mon ingress est derrière un RP HAproxy, il faudra alors configurer les backends haproxy avec l'option send-proxy-v2 sur le haproxy qui se trouve devant l'ingress:

Justine : /* CertManager */

2022-08-19T10:16:09Z

CertManager

← Version précédente		Version du 19 août 2022 à 10:16
Ligne 872 :		Ligne 872 :
	--create-namespace \		--create-namespace \
	--set installCRDs=true		--set installCRDs=true
			--set 'extraArgs={--acme-http01-solver-nameservers=9.9.9.9:53\,1.1.1.1:53}'
	</nowiki>		</nowiki>

			NB : ici, je change de DNS parce que ma config a un bug avec le serveur CoreDNS intégré à k3s. woohoo

	Ensuite il faut créer un issuer local/		Ensuite il faut créer un issuer local/

Justine le 7 juillet 2022 à 13:40

2022-07-07T13:40:41Z

@@ Ligne 951 : / Ligne 951 : @@
 * [https://rancher.com/docs/k3s/latest/en/upgrades/basic/#release-channels Source]
 * [https://rancher.com/docs/k3s/latest/en/upgrades/automated/ Source]
 Il est possible de mettre en place une upgrade automatisée de k3s. Cela passe par des "plans" : ce sont des objects spécifiques à k3s. Une fois en place, ceux-ci feront les upgrades régulières du cluster, node par node.
@@ Ligne 1 145 : / Ligne 1 151 : @@
 Et les maj en cours avec
   kubectl -n system-upgrade get jobs

Justine le 7 juillet 2022 à 13:35

2022-07-07T13:35:58Z

Voir les modifications

Justine : /* Déploiement d'une application (avec un fichier) */

2022-07-01T15:06:51Z

Déploiement d'une application (avec un fichier)

← Version précédente		Version du 1 juillet 2022 à 15:06
Ligne 457 :		Ligne 457 :

	Et voilà !		Et voilà !

			== NameSpaces ==
			Un namespace est une façon de découper nos applications : un objet dans un namespace X ne peut pas voir les objets du namespace Y.

			Le chart de création d'un NameSpace peut se faire de la façon suivante:
			<nowiki>
			apiVersion: v1
			kind: Namespace
			metadata:
			name: monitoring
			</nowiki>

			Ici, je créée un namespace "monitoring". Ensuite, pour que mes objets y aillent, il suffit de l'indiquer dans les métadonnées. Par exemple ici avec un PersistentVolumeClaim:

			<nowiki>
			apiVersion: v1
			kind: PersistentVolumeClaim
			metadata:
			name: grafana-conf
			namespace: monitoring
			spec:
			accessModes:
			[...]
			</nowiki>

			Ensuite, si je veux effectuer une opération dans un namespace, par exemple lister tous les pods, j'utilise -n :
			kubectl get pods -n monitoring

	= Ingress =		= Ingress =

Kubernetes - Historique des versions

Justine : /* CertManager */

Justine : /* CertManager */

Justine : /* Ingress */

Justine : /* Chaos-mesh */

Justine le 26 août 2022 à 15:42

Justine : /* Ingress */

Justine : /* CertManager */

Justine le 7 juillet 2022 à 13:40

Justine le 7 juillet 2022 à 13:35

Justine : /* Déploiement d'une application (avec un fichier) */

Justine : /* CertManager */

Justine : /* CertManager */

Justine : /* Ingress */

Justine : /* Chaos-mesh */

Justine : /* Ingress */

Justine : /* CertManager */

Justine : /* Déploiement d'une application (avec un fichier) */