kubernetes-ops

Concernant ces supports de cours

Supports de cours réalisés par Osones

https://osones.com

Logo Osones
Logo Osones
Licence Creative Commons BY-SA 4.0
Licence Creative Commons BY-SA 4.0

Kubernetes : Installation

Installation de Kubernetes

  • De nombreuses ressources présentes pour le déploiement de Kubernetes dans un environnement de production

  • Un des outils est kubeadm utilisé pour rapidement démarrer un cluster kubernetes

Installation de Kubernetes

Installation de Kubernetes

  • Installer les composants Kubernetes (kubeadm, kubectl, kubelet) : https://kubernetes.io/docs/setup/independent/install-kubeadm/
  • Exécuter sudo kubeadm init sur le noeud master
  • Exécuter sudo kubeadm join sur les autres noeuds (avec le token fournir par la commande kubeadm init)
  • Copier le fichier de configuration généré par kubeadm init
  • Installer le plugin Réseau (Dans notre cas nous utiliserons Weave Net)

Installation de Kubernetes

Installation de Kubernetes

Introduction à Sonobuoy

Kubectl : Advanced Usage

  • Il est possible de mettre à jour un service sans incident grâce ce qui est appelé le rolling-update.
  • Avec les rolling updates, les resources qu'expose un objet Service se mettent à jour progressivement.
  • Seuls les objets Deployment, DaemonSet et StatefulSet support les rolling updates.
  • Les arguments maxSurge et maxUnavailabe définissent le rythme du rolling update.
  • La commande kubectl rollout permet de suivre les rolling updates éffectués.

Kubectl : Advanced Usage

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: frontend
  replicas: 2
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  template:
    metadata:
      name: nginx
      labels:
        app: frontend
    spec:
      containers:
        - image: nginx:1.9.1
          name: nginx

Kubectl : Advanced Usage

$ kubectl create -f nginx.yaml --record
deployment.apps/nginx created

Kubectl : Advanced Usage

  • Il est possible d'augmenter le nombre de pods avec la commande kubectl scale :
kubectl scale --replicas=5 deployment nginx
  • Il est possible de changer l'image d'un container utilisée par un Deployment :
kubectl set image deployment nginx nginx=nginx:1.15

Kubectl : Advanced Usage

  • Dry run. Afficher les objets de l'API correspondant sans les créer :

kubectl run nginx --image=nginx --dry-run

  • Démarrer un container en utiliser une commande différente et des arguments différents :
kubectl run nginx --image=nginx \
--command -- <cmd> <arg1> ... <argN>
  • Démarrer un Cron Job qui calcule π et l'affiche toutes les 5 minutes :
kubectl run pi --schedule="0/5 * * * ?" --image=perl --restart=OnFailure \
-- perl -Mbignum=bpi -wle 'print bpi(2000)'

Kubectl : Advanced Usage

  • Se connecter à un container:
kubectl run -it busybox --image=busybox -- sh
  • S'attacher à un container existant :
kubectl attach my-pod -i
  • Accéder à un service via un port :
kubectl port-forward my-svc 6000

Kubectl : Logging

  • Utiliser kubectl pour diagnostiquer les applications et le cluster kubernetes :
kubectl cluster-info
kubectl get events
kubectl describe node <NODE_NAME>
kubectl  logs (-f) <POD_NAME>

Kubectl : Maintenance

  • Obtenir la liste des noeuds ainsi que les informations détaillées :
kubectl get nodes
kubectl describe nodes

Kubectl : Maintenance

  • Marquer le noeud comme unschedulable (+ drainer les pods) et schedulable :
kubectl cordon <NODE_NAME>
kubectl drain <NDOE_NAME>
kubectl uncordon <NODE_NAME>

Monitoring

LimitRanges

  • l'objet LimitRange permet de définir les valeurs minimum et maximum pour les ressources utilisées par les containers et les pods
  • l'objet LimitRange ne s'applique dans un seul namespace mais peut être utilisé pour d'autres namespaces
  • les limites spécifiées s'appliquent à chaque pod/container créé dans le namespace
  • le LimitRange ne limite pas le nombre total de ressources disponibles dans le namespace

LimitRanges

apiVersion: v1
kind: LimitRange
metadata:
  name: limit-example
spec:
  limits:
  - default:
      memory: 512Mi
    defaultRequest:
      memory: 256 Mi
    type: Container

ResourceQuotas

  • un objet ResourceQuota limite le total des ressources de calcul consommées par les pods ainsi que le total de l'espace de stockage consommé par les PersistentVolumeClaims dans un namespace
  • il permet aussi de limiter le nombre de pods, PVC et autres objets qui peuvent être créés dans un namespace

ResourceQuotas

apiVersion: v1
kind: ResourceQuota
metadata:
  name: cpu-and-ram
spec:
  hard:
    requests.cpu: 400m
    requests.memory: 200Mi
    limits.cpu: 600m
    limits.memory: 500Mi

Kubernetes : Securité et Controle d'accès

Authentication & Autorisation

  • RBAC (Role Based Access Control)
  • ABAC (Attribute-based access control)
  • WebHook
  • Certificates
  • Token

RBAC

3 entités sont utilisées :

  • Utilisateurs représentés par les Users ou les ServiceAccounts
  • Resources représentées par les Deployments, Pods, Services, etc...
  • les différentes opérations possibles : create, list, get, delete, watch, patch

Service Accounts

  • Objet Kubernetes permettant d'identifier une application s'éxecutant dans un pod
  • Par défaut, un ServiceAccount par namespace
  • Le ServiceAccount est formatté ainsi : system:serviceaccount:<namespace>:<service_account_name>

Service Accounts

apiVersion: v1
kind: ServiceAccount
metadata:
    name: default
    namespace: default

Role

  • L'objet Role est un ensemble de règles permettant de définir quelle opération (ou verbe) peut être effectuée et sur quelle ressource
  • Le Role ne s'applique qu'à un seul namespace et les ressources liées à ce namespace

Role

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

RoleBinding

  • L'objet RoleBinding va allouer à un User, ServiceAccount ou un groupe les permissions dans l'objet Role associé
  • Un objet RoleBinding doit référencer un Role dans le même namespace.
  • L'objet roleRef spécifié dans le RoleBinding est celui qui crée le liaison

RoleBinding

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRole

  • L'objet ClusterRole est similaire au Role à la différence qu'il n'est pas limité à un seul namespace
  • Il permet d'accéder à des ressources non limitées à un namespace comme les nodes

ClusterRole

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

ClusterRoleBinding

 kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: salme-reads-all-pods
subjects:
- kind: User
  name: jsalmeron
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

RBAC

kubectl auth can-i get pods /
--namespace=default /
--as=spesnova@example.com

NetworkPolicies

  • La ressource NetworkPolicy est une spécification permettant de définir comment un ensemble de pods communiquent entre eux ou avec d'autres endpoints
  • Le NetworkPolicy utilisent les labels pour sélectionner les pods sur lesquels s'appliquent les règles qui définissent le trafic alloué sur les pods sélectionnés
  • Le NetworkPolicy est générique et fait partie de l'API Kubernetes. Il est nécessaire que le plugin réseau déployé supporte cette spécification

NetworkPolicies

NetworkPolicies

  • Exemple de NetworkPolicy permettant de blocker le trafic entrant :
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-deny-all
spec:
  podSelector:
    matchLabels:
      app: web
  ingress: []

PodSecurityPolicies

  • Nécessite d'être activés spécifiquement
  • Permet de définir ce qui est alloué pour l'éxecution
  • Il faut une PSP par défaut
  • A utiliser dans un contexte multitenant
  • Peut-être combiné avec le RBAC
  • Attention: Activer cette fonctionnalité peut endommager votre environnement

Admission Controllers

  • Interceptes les requêtes sur l'API Kubernetes
  • Peut effectuer des modifications si nécessaires
  • Conception personnalisée possible

Admission Controllers

  • DenyEscalatingExec
  • ImagePolicyWebhook
  • NodeRestriction
  • PodSecurityPolicy
  • SecurityContextDeny
  • ServiceAccount

Conclusion