À partir de l’adresse <https://stackoverflow.com/questions/41509439/whats-the-difference-between-clusterip-nodeport-and-loadbalancer-service-types>
https://devopscube.com/kubernetes-architecture-explained/
Kubernetes Install and Your First Pods
Kubernetes Local Install
katacoda.com
minikube
minikube-installer.exe
minikube start
microk8s
microk8s.kubectl
microk8s.enable dns
alias kubectl=microk8s.kubectl
Kubectl run, create and apply
kubectl run
kubectl create
kubectl apply
Our First Pod With Kubectl run
kubectl version
kubectl run my-nginx —image nginx
kubectl get pods
kubectl get all
kubectl delete deployment my-nginx
kubectl get all
Scaling ReplicaSets
kubectl run my-apache —image httpd
kubectl get all
kubectl scale deploy/my-apache —replicas2
kubectl scale deployment my-apache —replicas2
kubectl get all
Inspecting Kubernetes Objects
kubectl get pods
kubectl logs deployment/my-apache
kubectl logs deployment/my-apache —follow —tail 1
kubectl logs -l run=my-apache
kubectl get pods
kubectl describe pod/my-apache-
kubectl get pods -w
kubectl delete pod/my-apache-
kubectl get pods
kubectl delete deployment my-apache
Exposing containers
# Exposing Kubernetes Ports
kubectl expose
kubectl get pods -w
kubectl create deployment httpenv —image=bretfisher/httpenv
kubectl scale deployment/httpenv —replicas=5
kubectl expose deployment/httpenv —port 8888
kubectl get service
kubectl run —generator run-pod/v1 tmp-shell —rm -it —image bretfisher/netshoot — bash
kubectl run tmp-shell —rm -it —image bretfisher/netshoot — bash
curl httpenv:8888
curl [ip of service]:8888
kubectl get service
Creating a NodePort and LoadBalancer Service
kubectl get all
kubectl expose deployment/httpenv —port 8888 —name httpenv-np —type NodePort
kubectl get services
curl localhost:32334
kubectl expose deployment/httpenv —port 8888 —name httpenv-lb —type LoadBalancer
kubectl get services
curl localhost:8888
kubectl delete service/httpenv service/httpenv-np
kubectl delete service/httpenv-lb deployment/httpenv
curl
kubectl get namespaces
curl
Kubernetes Management Techniques
Kubernetes Management Techniques
Run, Expose and Create Generators
kubectl create deployment sample —image nginx —dry-run -o yaml
kubectl create deployment test —image nginx —dry-run
kubectl create deployment test —image nginx —dry-run -o yaml
kubectl create job test —image nginx -dry-run -o yaml
kubectl expose deployment/test —port 80 —dry-run -o -yaml
kubectl create deployment test —image nginx
kubectl expose deployment/test —port 80 —dry-run -o -yaml
kubectl delete deployment test
kubectl run test —image nginx —dry-run
kubectl run test —image nginx —port 80 —expose —dry-run
kubectl run test —image nginx —restart OnFailure —dry-run
kubectl run test —image nginx —restart Never —dry-run
kubectl run test —image nginx —scheduled ”*/1 * * * *” —dry-run
kubectl apply -f my-resources.yaml
kubectl run
# Moving to Declarative Kubernetes YAML
Kubectl Apply
kubectl apply -f filename.yml
kubectl apply -f myfile.yaml
kubectl apply -f myyaml/
kubectl apply -f https://bret.run/pod.yml
curl -L https://bret.run/pod
start https://bret.run/pod.yml
Building Your YAML Files
kubectl api-resources
kubectl api-versions
Dry Runs and Diffs
kubectl apply -f app.yml —dry-run=client
kubectl apply -f app.yml —dry-run=server
kubectl diff -f app.yml
Labels and Label Selectors
kubectl get pods -l app=nginx
kubectl apply -f myfile.yaml -l app=nginx
kubectl get all
kubectl delete
kubectl rollout status deployments nginx
kubectl rollout pause deployments nginx
kubectl rollout resume deployments nginx
kubectl rollout history deployment nginx
Debug ⇒ kubectl logs <pod_name>
Run command inside running container ⇒ kubectl exec -it <pod_name> — bash
kubectl provides the —watch flag (-w for short) to save you having to do this. For
example:
kubectl get pods —watch
kubectl get pods -l environment=staging
[Public] Kubernetes application management tools - Google Sheets
DaemonSets ⇒ A DaemonSet ensures a copy of a Pod is running across a set of nodes in a Kubernetes cluster. DaemonSets are used to deploy system daemons such as log collectors and monitoring agents, which typically must run on every node. DaemonSets share similar functionality with ReplicaSets; both create Pods that are expected to be long-running services and ensure that the desired state and the observed state of the cluster match.
spec.minReadySeconds, which determines how long a Pod must be “ready” before the rolling update proceeds to upgrade subsequent Pods spec.updateStrategy.rollingUpdate.maxUnavailable, which indicates how many Pods may be simultaneously updated by the rolling update Jobs ⇒ A Job creates Pods that run until successful termination (i.e., exit with 0). In contrast, a regular Pod will continually restart regardless of its exit code. Jobs are useful for things you only want to do once, such as database migrations or batch jobs. If run as a regular Pod, your database migration task would run in a loop, continually repopulating the database after every exit
Config Maps and Secrets ⇒ kubectl create secret generic or kubectl create configmap
One way to think of a ConfigMap is as a Kubernetes object that defines a small filesystem. Another way is as a set of variables that can be used when defining the environment or command line for your containers. The key thing is that the ConfigMap is combined with the Pod right before it is run. This means that the container image and the pod definition itself can be reused across many apps by just changing the ConfigMap that is used.
While ConfigMaps are great for most configuration data, there is certain data that is extra-sensitive. This can include passwords, security tokens, or other types of private keys. Collectively, we call this type of data “secrets.” Kubernetes has native support for storing and handling this data with care. Secrets enable container images to be created without bundling sensitive data. This allows containers to remain portable across environments. Secrets are exposed to pods via explicit declaration in pod manifests and the Kubernetes API. In this way the Kubernetes secrets API provides an application-centric mechanism for exposing sensitive configuration information to applications in a way that’s easy to audit and leverages native OS isolation primitives
You can create a ConfigMap directly from a YAML file as follows:
==kubectl create configmap demo-config —namespace=demo —from-file=config.yaml==
configmap "demo-config" created
To export the manifest file that corresponds to this ConfigMap, run:
==kubectl get configmap/demo-config —namespace=demo —export -o yaml >demo-config.yaml==
Node Affinities
Hard affinity
For example, Google Kubernetes Engine preemptible nodes carry the label cloud.goo
gle.com/gke-preemptible. To tell Kubernetes to never schedule a Pod on one of
these nodes, add the following to the Pod or Deployment spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: cloud.google.com/gke-preemptible
operator: DoesNotExist
Soft affinity
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- preference:
matchExpressions: - key: cloud.google.com/gke-preemptible
operator: Exists
weight: 100
Pod Affinities
The overall effect of this affinity is to ensure that the server Pod is scheduled, if pos‐
sible, on a node that is also running a Pod labeled cache. If there is no such node, or if
there is no matching node that has sufficient spare resources to run the Pod, it will
not be able to run
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
labelSelector:
- matchExpressions:
- key: app
operator: In
values: [“cache”]
topologyKey: kubernetes.io/hostname
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
labelSelector:
- matchExpressions:
- key: app
operator: In
values: [“server”]
topologyKey: kubernetes.io/hostname
PodPresets
PodPresets are an experimental alpha feature in Kubernetes that allow you to inject
information into Pods when they’re created. For example, you could create a PodPre‐
set that mounts a volume on all Pods matching a given set of labels.
Run a busybox container for debugging :
==kubectl run busybox —image=busybox:1.28 -n
TLS secret :
kubectl create secret tls toolserafr-certificate -n traefik-staging —cert=toolserafr_cloudflare_origin.crt —key=toolserafr_cloudflare_origin.key