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
sudo kubeadm init
sur le noeud mastersudo kubeadm join
sur les autres noeuds (avec le token fournir par la commande kubeadm init
)kubeadm init
Service
se mettent à jour progressivement.Deployment
, DaemonSet
et StatefulSet
support les rolling updates.maxSurge
et maxUnavailabe
définissent le rythme du rolling update.kubectl rollout
permet de suivre les rolling updates éffectués.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 create -f nginx.yaml --record
deployment.apps/nginx created
kubectl scale
:kubectl scale --replicas=5 deployment nginx
kubectl set image deployment nginx nginx=nginx:1.15
kubectl run nginx --image=nginx --dry-run
kubectl run nginx --image=nginx \
--command -- <cmd> <arg1> ... <argN>
kubectl run pi --schedule="0/5 * * * ?" --image=perl --restart=OnFailure \
-- perl -Mbignum=bpi -wle 'print bpi(2000)'
kubectl run -it busybox --image=busybox -- sh
kubectl attach my-pod -i
kubectl port-forward my-svc 6000
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 get nodes
kubectl describe nodes
kubectl cordon <NODE_NAME>
kubectl drain <NDOE_NAME>
kubectl uncordon <NODE_NAME>
LimitRange
permet de définir les valeurs minimum et maximum pour les ressources utilisées par les containers et les podsLimitRange
ne s'applique dans un seul namespace
mais peut être utilisé pour d'autres namespaces
namespace
LimitRange
ne limite pas le nombre total de ressources disponibles dans le namespaceapiVersion: v1
kind: LimitRange
metadata:
name: limit-example
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256 Mi
type: Container
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 namespacepods
, PVC
et autres objets qui peuvent être créés dans un namespace
apiVersion: v1
kind: ResourceQuota
metadata:
name: cpu-and-ram
spec:
hard:
requests.cpu: 400m
requests.memory: 200Mi
limits.cpu: 600m
limits.memory: 500Mi
3 entités sont utilisées :
Users
ou les ServiceAccounts
Deployments
, Pods
, Services
, etc...create, list, get, delete, watch, patch
ServiceAccount
par namespace
ServiceAccount
est formatté ainsi : system:serviceaccount:<namespace>:<service_account_name>
apiVersion: v1
kind: ServiceAccount
metadata:
name: default
namespace: default
Role
est un ensemble de règles permettant de définir quelle opération (ou verbe) peut être effectuée et sur quelle ressourceRole
ne s'applique qu'à un seul namespace
et les ressources liées à ce namespace
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
RoleBinding
va allouer à un User
, ServiceAccount
ou un groupe les permissions dans l'objet Role
associéRoleBinding
doit référencer un Role
dans le même namespace
.roleRef
spécifié dans le RoleBinding
est celui qui crée le liaisonkind: 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
est similaire au Role
à la différence qu'il n'est pas limité à un seul namespace
namespace
comme les nodes
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]
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
kubectl auth can-i get pods /
--namespace=default /
--as=spesnova@example.com
NetworkPolicy
est une spécification permettant de définir comment un ensemble de pods
communiquent entre eux ou avec d'autres endpointsNetworkPolicy
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ésNetworkPolicy
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écificationNetworkPolicy
permettant de blocker le trafic entrant :kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: web-deny-all
spec:
podSelector:
matchLabels:
app: web
ingress: []
DenyEscalatingExec
ImagePolicyWebhook
NodeRestriction
PodSecurityPolicy
SecurityContextDeny
ServiceAccount