Explication du fonctionnements des overlays networks dans Kubernetes par la pratique en prenant l'example d'un plugin CNI écrit en bash (https://github.com/s-matyukevich/bash-cni-plugin/blob/master/01_gcp/bash-cni)
Quelques commandes utiles pour diagnostiquer un problème sur un pod kubernetes.
Une cli pour créer des clusters AWS EKS en une ligne de commande
Quelques conseils pour mettre en place et gérer un cluster Kubernetes:
- Demander des retours d'expériences d'autres compagnies
- Ne pas hésiter à lire le code Kubernetes
- Faire des tests de charge
- Prioriser la mise en place et les tests HA du cluster ETCD
- Migrer les applications sur Kubernetes de façon incrémentale
- Investiguer et corriger les bugs Kubernetes rencontrés (ne pas hésiter à faire des PR sur le repo kubernetes)
- Tester la résilience sur les pannes de composants Kubernetes (kill ETCD node, API server, worker node, ...)
Une commandline interactive (REPL) pour gérer les clusters Kubernetes avec des commandes moins longues et plus simples que kubectl
Un nouveau projet de la fondation Jenkins qui permet d'automatiser une chaîne complète de CI/CD, de la création du repo à la promotion en prod avec Jenkins et Kubernetes. L’intégration semble s’approcher de ce que propose OpenShift en la matière.
3 méthodes différentes permettant de prendre le contrôle d'un cluster kubernetes à partir d'un pod avec une installation de kops par défaut et comment les sécuriser. Il faudrait vérifier si ces failles existent également par défaut avec les autres outils de provisioning kubernetes (kubespray...).
Kubetail permet d'agréger et d'afficher en temps réel les logs d'un ou plusieurs pods
Kubediff compare l'état réel d'un cluster kubernetes avec son état attendu (configuration yaml files) et remonte une alerte en cas de divergences
Synthèse des nouveaux services EKS et Fargate annoncés aux AWS Re-Invent Summit cette année.
EKS (AWS Kubernetes managed solution) permet de déployer un cluster Kubernetes sur AWS en ne gérant que les workers nodes (masters nodes managés par AWS).
Fargate va plus loin en fournissant une solution 100% managée (workers nodes managés) pour ECS dans un premier temps puis EKS en 2018. Cette solution permet de déployer des containers sans ce soucier des instances EC2 sur lesquels ils tourneront et de payer uniquement pour les containers déployés (facturation par container au lieu de la facturation par instances EC2 démarrées dans le cluster).
Une formation (gratuite) sur Kubernetes offerte par la Linux Fondation
Correspondances entre les noms des ressources dans Spinnaker et dans Kubernetes:
- regions (spinnaker) = namespace (k8s)
- accounts (spinnaker) = cluster (k8s)
- clusters (spinnaker) = replicaset (k8s)
- server groups (spinnaker) = deployment (k8s)
- load balancer (spinnaker) = service (k8s)
- security groups (spinnaker) = ingress (k8s)
Attention: au delà des nommages différents, d'autres subtilités existent et sont décrites plus en détails dans l'article.
Pour centraliser les logs des pods dans Cloudwatch Logs avec un cluster Kubernetes provisionné par KOPS:
$ kops edit cluster
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: kops/v1alpha2
kind: Cluster
spec:
...
additionalPolicies:
node: |
[
{
"Effect": "Allow",
"Action": ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"],
"Resource": ["*"]
}
]
master: |
[
{
"Effect": "Allow",
"Action": ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"],
"Resource": ["*"]
}
]
docker:
logDriver: awslogs
logOpt:
- awslogs-region=eu-west-1
- awslogs-group=k8s
...
$ kops update cluster --yes # used only to update additional iam policies
$ kops rolling-update --yes --force # used to recreate every k8s cluster members (docker logdriver and logopt will be added to /etc/sysconfig/docker at the first boot)Attention les noms des streams de logs dans cloudwatch correspondent aux id des containers, ce n'est pas très pratique...
EDIT: en utilisant cette méthode, les logs ne sont plus accessible via la commande kubectl logs. Du coup je ne recommande pas cette approche...
- Pour exporter la conf d'un cluster kubernetes provisonné avec kops:
kops get cluster ${CLUSTER_NAME} -o yaml --full > cluster.yml kops get ig nodes -o yaml > nodes.yml kops get ig masters -o yaml > master.yml - Pour recréer un cluster à partir de cette conf:
cat cluster.yml > cluster_spec.yml echo --- >> cluster_spec.yml cat nodes.yml >> cluster_spec.yml echo --- >> cluster_spec.yml cat master.yml >> cluster_spec.yml kops create -f cluster_spec.yml
route53-kubernetes permet d'automatiser la création d'enregistrement DNS quand on configure son Ingress.
C'est intégré sous forme d'addon à KOPS.
Attention: Après quelques tests, si route53-kubernetes gère bien la création des nouveaux enregistrements DNS, je n'ai pas l'impression qu'il gère la modification ou suppression des enregistrements créés précédemment. Il doit donc falloir faire du ménage manuellement de temps en temps.
A noter qu'il existe aussi ExternalDNS qui semble être la future méthode standard pour manipuler les DNS externes (Route53, Google Cloud DNS, ...) mais qui semble moins mature.
Quand on écrit des config Kubernetes, il faut jongler avec les versions d'api (paramètre apiVersion dans le yaml) qui diffèrent selon la version de Kubernetes et le type de ressources (principalement v1, apps/v1 et extensions/v1beta1).
La documentation de référence de l'API permet (entre autre) de connaître la bonne version à utiliser pour chaque resource.
$ source <(kubectl completion bash) # setup autocomplete in bash, bash-completion package should be installed first.
$ source <(kubectl completion zsh) # setup autocomplete in zshet plein d'autres tips bien pratiques...
Pour installer un cluster Kubernetes privé avec KOPS sur une infra AWS déjà existante (DNS, VPC, Subnets, ...)
EDIT
en complement un tuto qui permet de faire quasimment la même chose mais en utilisant KOPS pour exporter une configuration Terraform pour ceux qui utilisent déjà Terraform pour le reste de leur infrastructure:
https://ryaneschinger.com/blog/kubernetes-aws-vpc-kops-terraform/
Une présentation des avantages de Prometheus pour le monitoring de clusters Kubernetes