devops:docker:kubernetes
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| devops:docker:kubernetes [2023/11/19 11:40] – [Kubernetes Command line control] skipidar | devops:docker:kubernetes [2024/07/21 14:33] (current) – skipidar | ||
|---|---|---|---|
| Line 9: | Line 9: | ||
| K8s in 30 Min https:// | K8s in 30 Min https:// | ||
| + | |||
| + | |||
| + | {{youtube> | ||
| + | |||
| + | Glossary | ||
| + | |Pod|Smallest unit of K8s. Can contain multiple containers {{https:// | ||
| + | |ReplicaSet| **Orchestrated by deployments.** A ReplicaSet ensures that a **specified number of pod replicas are running at any given time**. However, a Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to Pods along with a lot of other useful features. {{https:// | ||
| + | |Deployments|Manages your Pods. The Deployment object not only creates the pods but also ensures the correct number of pods is always running in the cluster, handles scalability, | ||
| + | |Services|Write traffic to Pods. Visible inside the cluster {{https:// | ||
| + | |Ingress|Make Service visible over the internets {{https:// | ||
| + | |Secrets| Store SENSITIVE data and files to map those into the container {{https:// | ||
| Line 23: | Line 34: | ||
| + | # list clusterrole bindings for all namespaces | ||
| + | kubectl get clusterrolebindings system:node --all-namespaces -o json | ||
| + | |||
| + | { | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | }, | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | }, | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | }, | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | } | ||
| + | } | ||
| + | |||
| + | |||
| + | |||
| + | # cubeconfig is the config-file, | ||
| + | # generates a " | ||
| + | aws eks update-kubeconfig --name alf-dev-eks-auth0-eks --alias alf-dev-eks-auth0-eks | ||
| + | |||
| + | |||
| + | apiVersion: v1 | ||
| + | clusters: | ||
| + | - cluster: | ||
| + | certificate-authority-data: | ||
| + | server: https:// | ||
| + | name: arn: | ||
| + | contexts: | ||
| + | - context: | ||
| + | cluster: arn: | ||
| + | user: arn: | ||
| + | name: arn: | ||
| + | current-context: | ||
| + | kind: Config | ||
| + | preferences: | ||
| + | users: | ||
| + | - name: arn: | ||
| + | user: | ||
| + | exec: | ||
| + | apiVersion: client.authentication.k8s.io/ | ||
| + | args: | ||
| + | - --region | ||
| + | - eu-central-1 | ||
| + | - eks | ||
| + | - get-token | ||
| + | - --cluster-name | ||
| + | - alf-dev-eks-auth0-eks | ||
| + | - --output | ||
| + | - json | ||
| + | command: aws | ||
| Line 69: | Line 141: | ||
| ==== Vagrant environment ==== | ==== Vagrant environment ==== | ||
| Use the Vagrant environment for the experiments | Use the Vagrant environment for the experiments | ||
| - | https:// | + | <del>https:// |
| + | |||
| + | https:// | ||
| Line 78: | Line 152: | ||
| - | === On Windows - Dont deploy in minikube=== | + | === Prefered: |
| - | Why not Minukube: the **minikube** may only be started from disk C:\ Otherwise it will throw an error, that it does not recognize the path. | + | |
| + | - install " | ||
| + | - install | ||
| + | |||
| + | see | ||
| + | https:// | ||
| + | === Alternative: | ||
| - | === On Windows - Deploy in Linux-guest Vagrant VM - Minikube distribution === | + | Challenges: redirecting the minikube console etc. is challenging. |
| OS: Ubuntu | OS: Ubuntu | ||
| Line 904: | Line 985: | ||
| https:// | https:// | ||
| + | |||
| + | |||
| + | Generate deployment config with a service. | ||
| + | |||
| + | <sxh shell> | ||
| + | kubectl create deployment demo --image=springguides/ | ||
| + | echo --- >> deployment.yaml | ||
| + | kubectl create service clusterip demo --tcp=8080: | ||
| + | </ | ||
| + | |||
| + | |||
| + | Generated deployment config: | ||
| + | |||
| + | <sxh shell> | ||
| + | |||
| + | apiVersion: apps/v1 | ||
| + | kind: Deployment | ||
| + | metadata: | ||
| + | creationTimestamp: | ||
| + | labels: | ||
| + | app: demo | ||
| + | name: demo | ||
| + | spec: | ||
| + | replicas: 1 | ||
| + | selector: | ||
| + | matchLabels: | ||
| + | app: demo | ||
| + | strategy: | ||
| + | type: RollingUpdate | ||
| + | template: | ||
| + | metadata: | ||
| + | creationTimestamp: | ||
| + | labels: | ||
| + | app: demo | ||
| + | spec: | ||
| + | containers: | ||
| + | - image: springguides/ | ||
| + | name: demo | ||
| + | resources: {} | ||
| + | status: {} | ||
| + | </ | ||
| + | |||
| + | |||
| + | Lets go step by step through the config: | ||
| + | <sxh shell> | ||
| + | |||
| + | metadata: | ||
| + | creationTimestamp: | ||
| + | labels: | ||
| + | app: demo | ||
| + | name: demo | ||
| + | |||
| + | Assign label " | ||
| + | Labels help identify and categorize resources. By assigning specific labels, you can easily distinguish between different types or groups of resources within your cluster. | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | spec: | ||
| + | replicas: 1 | ||
| + | selector: | ||
| + | matchLabels: | ||
| + | app: demo | ||
| + | |||
| + | In the provided Kubernetes deployment specification, | ||
| + | |||
| + | selector: | ||
| + | This key signifies the start of the selector configuration within the deployment spec. | ||
| + | |||
| + | matchLabels: | ||
| + | This key specifies that the selector will use labels for matching. | ||
| + | |||
| + | app: demo: | ||
| + | This entry defines the actual matching criteria. It specifies that the selector will only consider Pods with a label named app and a value of demo. | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | spec: | ||
| + | replicas: 1 | ||
| + | spec: | ||
| + | containers: | ||
| + | - image: springguides/ | ||
| + | name: demo | ||
| + | resources: {} | ||
| + | |||
| + | This defines the name assigned to the container within the Pod. | ||
| + | |||
| + | </ | ||
| + | |||
devops/docker/kubernetes.1700394010.txt.gz · Last modified: by skipidar
