GitLab

2018-12-06T22:17:17Z

136.159.160.201: /* Docker Registry Runners */

== Docker Registry Runners ==

* https://angristan.xyz/build-push-docker-images-gitlab-ci/

{{highlight|lang=terminal|code=
# docker-compose run --rm gitlab-runner register -n --url https://git.steamr.com/ --registration-token z276ujRTK69qD8xb-aNH --executor docker --docker-image "docker:stable"
Runtime platform arch=amd64 os=linux pid=7 revision=3afdaba6 version=11.5.0
Running in system-mode.

Registering runner... succeeded runner=z276ujRT
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

root@docker:/root/docker/running/gitlab# cat /var/volumes/gitlab/runner-config/config.toml
concurrent = 1
check_interval = 0

[session_server]
session_timeout = 1800

[[runners]]
name = "3b70de49f826"
url = "https://git.steamr.com/"
token = "1dbe4535e5aaa49d6582d374a29c28"
executor = "docker"
[runners.docker]
tls_verify = false
image = "docker:stable"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/cache"]
shm_size = 0
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]

root@docker:/root/docker/running/gitlab# cat docker-compose.yml /root/docker/running/gitla
version: '3.3'

services:

gitlab:
#build:
# context: ./gogs
# dockerfile: Dockerfile
# letsencrypt['enable'] = false
image: gitlab/gitlab-ce:latest
container_name: gitlab
environment:
GITLAB_OMNIBUS_CONFIG: {{!}}
external_url 'https://git.steamr.com'
nginx['listen_port'] = '80'
nginx['listen_https'] = false
nginx['proxy_set_headers'] = { 'X-Forwarded-Proto' => 'https', 'X-Forwarded-Ssl' => 'on' }
registry_external_url 'https://registry.steamr.com'
registry['enable'] = true
gitlab_rails['registry_enabled'] = true
registry_nginx['listen_port'] = 5001
registry_nginx['listen_https'] = false
registry_nginx['proxy_set_headers'] = { 'X-Forwarded-Proto' => 'https', 'X-Forwarded-Ssl' => 'on' }
volumes:
- /var/volumes/gitlab/config:/etc/gitlab
- /var/volumes/gitlab/logs:/var/log/gitlab
- /var/volumes/gitlab/data:/var/opt/gitlab
restart: always
expose:
- "80"
- "5001"
ports:
- "10.1.2.54:22:22"
labels:
- "traefik.enable=true"
- "traefik.docker.network=traefik"
- "traefik.web.port=80"
- "traefik.web.frontend.rule=Host:git.steamr.com"
- "traefik.registry.port=5001"
- "traefik.registry.frontend.rule=Host:registry.steamr.com"
networks:
- traefik
healthcheck:
disable: true

gitlab-runner:
image: gitlab/gitlab-runner:latest
container_name: gitlab-runner
restart: always
volumes:
- /var/volumes/gitlab/runner-config:/etc/gitlab-runner
- /var/run/docker.sock:/run/docker.sock

networks:
traefik:
external:
name: traefik

}}

Kubernetes

2018-12-06T22:14:43Z

136.159.160.201: /* Namespaces */

This article goes over concepts as I try to understand everything about Kubernetes.

== Installing ==
* https://www.linuxtechi.com/install-kubernetes-1-7-centos7-rhel7/

=== Master Node ===
{{highlight|lang=terminal|code=
# firewall-cmd --permanent --add-port=6443/tcp
# firewall-cmd --permanent --add-port=2379-2380/tcp
# firewall-cmd --permanent --add-port=10250/tcp
# firewall-cmd --permanent --add-port=10251/tcp
# firewall-cmd --permanent --add-port=10252/tcp
# firewall-cmd --permanent --add-port=10255/tcp
# firewall-cmd --reload
## Kubernetes does not handle memory evictions, disable swap. remember to remove it from /etc/fstab too.
# swapoff -a
# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
# yum -y install kubeadm docker
# systemctl enable docker kubelet
# systemctl start docker kubelet
# kubeadm init

# export kubever=$(kubectl version {{!}} base64 {{!}} tr -d '\n')
# kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$kubever"
}}

Once everything finishes running, it may take a few more minutes before the node becomes ready as the WeaveWorks network containers get pulled and started.

==== Dashboard ====
To get the Web UI Dashboard working, see:
* https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/#deploying-the-dashboard-ui
* https://docs.aws.amazon.com/eks/latest/userguide/dashboard-tutorial.html

It boils down to:
{{highlight|lang=terminal|code=
# kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml
# kubectl apply -f https://raw.githubusercontent.com/kubernetes/heapster/master/deploy/kube-config/influxdb/heapster.yaml
# kubectl apply -f https://raw.githubusercontent.com/kubernetes/heapster/master/deploy/kube-config/influxdb/influxdb.yaml
# kubectl apply -f https://raw.githubusercontent.com/kubernetes/heapster/master/deploy/kube-config/rbac/heapster-rbac.yaml

## Create a service account with permission:
# cat <<EOF > eks-admin-service-account.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: eks-admin
namespace: kube-system
EOF
# kubectl apply -f eks-admin-service-account.yaml
# cat <<EOF > eks-admin-cluster-role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: eks-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: eks-admin
namespace: kube-system
EOF
# kubectl apply -f eks-admin-cluster-role-binding.yaml

## Get the access token
# kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep eks-admin | awk '{print $1}')

## Proxy, and then navigate to http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/#!/login
# kubectl proxy
}}

=== Kubernetes (worker) Nodes ===

{{highlight|lang=terminal|code=
# firewall-cmd --permanent --add-port=10250/tcp
# firewall-cmd --permanent --add-port=10255/tcp
# firewall-cmd --permanent --add-port=30000-32767/tcp
# firewall-cmd --permanent --add-port=6783/tcp
# firewall-cmd --reload
## Kubernetes does not handle memory evictions, disable swap. remember to remove it from /etc/fstab too.
# swapoff -a
# modprobe br_netfilter
# for i in ip_vs ip_vs_sh ip_vs_rr ip_vs_wrr ; do modprobe $i ; done

# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

# yum -y install kubeadm docker
# systemctl enable docker kubelet
# systemctl start docker kubelet
}}

To join the worker to the cluster, obtain the join token as well as the discovery token CA cert hash. On the master node, run:

{{highlight|lang=terminal|code=
# openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt {{!}} openssl rsa -pubin -outform der 2>/dev/null {{!}} openssl dgst -sha256 -hex {{!}} sed 's/^.* //'
4c6ee8dd02afae0f9231c1002a4fca671622addc7ff4b522a70d68ed0b525445
# kubeadm token list
TOKEN TTL EXPIRES USAGES DESCRIPTION EXTRA GROUPS
a0mjyg.eiqvzbpwf2dgn9z3 <invalid> 2018-11-29T11:57:02-07:00 authentication,signing The default bootstrap token generated by 'kubeadm init'. system:bootstrappers:kubeadm:default-node-token
}}

Based on the values above, on the worker node, run:
{{highlight|lang=terminal|code=
# kubeadm join --token a0mjyg.eiqvzbpwf2dgn9z3 --discovery-token-ca-cert-hash sha256:4c6ee8dd02afae0f9231c1002a4fca671622addc7ff4b522a70d68ed0b525445 10.1.3.252:6443
}}

Alternatively, you could generate a new token on the master node:

{{highlight|lang=terminal|code=
# kubeadm token create --print-join-command
kubeadm join 10.1.3.252:6443 --token so4o6b.fyzvgwpgmpoq6mdm --discovery-token-ca-cert-hash sha256:4c6ee8dd02afae0f9231c1002a4fca671622addc7ff4b522a70d68ed0b525445
}}

== Quick Start ==

=== Get an application running ===
What you want to do to get an application running as a service:
* Create a deployment which defines how many replicas should exist, the container to use, and exposed ports.
** This will create a Pod. Each replica creates an additional Pod (that ideally resides on different nodes).
** {{code|kubectl get deployments}} to see deployments
** {{code|kubectl get pods}} to see pods
* Create a service which defines the name of the service and the port the service is exposed on
** {{code|kubectl get service}}

== Concepts ==
See the Kubernetes documentation at https://kubernetes.io/docs/concepts/

In summary:
* A '''Deployment''' defines the desired state for pods and ReplicaSets.
* A '''ReplicaSets''' creates or destroys Pods (depending on scaling?).
* A '''Pod''' is a collection of container(s) all residing on one node.
* A '''Service''' is an abstraction that defines the logical set of Pods. The Pods could be turned off or migrated without affecting the overall Service.
* A '''Master Node''' is responsible for maintaining the state of the Kubernetes cluster.
* A '''Kubernetes (Worker) Node''' is responsible for running the actual applications managed by Kubernetes.

Each concept will be covered in more detail below.

=== Pods ===
A pod is:
* A collection of application containers
* Guaranteed to land on the same kubernetes cluster machine
* Shares the same cgroup, IP address, hostname (hence, runs in the same execution environment)

A pod should provide one individual component of an application that can:
* Be scaled independently of all other components in the application (eg. Database with respect to the frontend web server)
* Work even if placed (ie. orchestrated) on a different machine

{{Quote|text=In general, the right question to ask yourself when designing Pods is, “Will these containers work correctly if they land on different machines?” If the answer is “no,” a Pod is the correct grouping for the containers. If the answer is “yes,” multiple Pods is probably the correct solution. In the example at the beginning of this chapter, the two containers interact via a local filesystem. It would be impossible for them to operate correctly if the containers were scheduled on different machines.|cite=Thinking with Pods, Kubernetes: Up and Running}}

Pods are defined in text file as a manifest. The Kubernetes API server processes the manifest, then stores it in persistent storage (etcd). A scheduler then finds pods that need to be scheduled and deploys the pods on the appropriate resource that satisfies any constraints defined in the manifest.

A Pod can be created by invoking a command: {{code|1=kubectl run kuard --image=registry/something/something:tag}}. However, using a manifest (aka. an object definition in yaml) to define the Pod is more manageable. A manifest looks something like this:
{{highlight|lang=text|
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Pod
metadata:
name: kuard
spec:
containers:
- image: gcr.io/kuar-demo/kuard-amd64:1
name: kuard
ports:
- containerPort: 8080
name: http
protocol: TCP
env:
- value: something
resources:
requests:
cpu: 100m
cpu: 100Mi
}}

A few things to note from the definition above (and this applies to all manifests)
# Kind: Specifies the kind of Kubernetes resource this manifest defines
# Metadata: Helpful data to uniquely identify the object. Eg. name, UID, optionally namespace
# Spec: Object data; for Pods, it should be an array of containers (including container image, name, ports, environment variables, resources, etc).
For more information on the spec, see https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md.

* Create using {{code|kubectl apply -f pod-manifest.yml}}
* See it using {{code|kubectl get pods}}
* Detailed information about it using {{code|kubectl describe pods pod-name}}
* Delete it using {{code|kubectl delete pods/pod-name}} or {{code|kubectl delete -f pod-manifest.yml}}

Pods that are set for deletion will cease to have new requests sent to it. After a 30 second termination grace period, the pods are then terminated. This extra time allows for the pod to reliably finish active requests.

=== Deployments ===
Deployments defines the state of Pods or ReplicaSets.

The manifest's spec should contain a template that contains the information about a new Pod.

Example Deployment manifest:
{{highlight|lang=text|text=
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: frontend
labels:
app: guestbook
spec:
selector:
matchLabels:
app: guestbook
tier: frontend
replicas: 3
template:
*** Pod's metadata and spec ***
}}

* Create using {{code|kubectl apply -f frontend-deployment.yml}}
* See it using {{code|kubectl get deployments}}
* Pods that this deployment creates can be seen using the label selector.
** This example manifest has 2 labels applied: app, and tier
** See it using {{code|1=kubectl get pods -l app=guestbook -l tier=frontend}}

You can change the scale of a deployment:
{{highlight|lang=terminal|code=
[root@kube guestbook]# kubectl get deployment frontend
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
frontend 3 3 3 3 44m
[root@kube guestbook]# kubectl scale deployment frontend --replicas=5
deployment.extensions/frontend scaled
[root@kube guestbook]# kubectl get deployment frontend
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
frontend 5 5 5 5 45m
[root@kube guestbook]# kubectl get pods
NAME READY STATUS RESTARTS AGE
frontend-654c699bc8-5ngzj 1/1 Running 0 45m
frontend-654c699bc8-77b58 1/1 Running 0 45m
frontend-654c699bc8-ll7cr 1/1 Running 0 22s
frontend-654c699bc8-pqzvp 1/1 Running 0 22s
frontend-654c699bc8-sq682 1/1 Running 0 45m
}}

=== Service ===
An application may depend on a service that is provided by one or more Pods. While it is possible to hard code the Pod's IP address, it is better to abstract these Pod's services as a Pod's Service which can be discovered (via Service Discovery). In addition, Pods providing the Service could be migrated, turned off, or scaled up without affecting the Service's availability (as the Service can automatically route traffic to available Pods).

A Service by default provides a single IP address for the set of pods (known as a ClusterIP) and are only accessible within the cluster. This can be changed so that a Service provides a load balanced port (LoadBalancer) or a port which is exposed on the node (NodePort).

An example manifest:
{{highlight|lang=terminal|code=
apiVersion: v1
kind: Service
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
# comment or delete the following line if you want to use a LoadBalancer
type: NodePort
# if your cluster supports it, uncomment the following to automatically create
# an external load-balanced IP for the frontend service.
# type: LoadBalancer
ports:
- port: 80
selector:
app: guestbook
tier: frontend
}}

* Apply the Service using {{code|kubectl apply -f frontend-service.yaml}}
* See Services using {{code|kubectl get services }}

If you use a NodePort and the service looks like this:
{{highlight|lang=terminal|code=
[root@kube guestbook]# kubectl get service frontend
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend NodePort 10.97.195.242 <none> 80:32764/TCP 10m
}}
You can get to your service by accessing the Node on port 32764.

=== Namespaces ===
A namespace organizes objects in the cluster. It is analogous to OU containers in Active Directory, folders in a filesystem, or classes in object oriented languages. By default, new objects are placed in the 'default' namespace. Objects cannot see other objects in different namespaces (this applies even to the default namespace). If you have secrets, ensure they match the namespace of the object using the secret for them to be of any use.

=== Contexts ===
Contexts are like a profile. A context can have different default namespace, or user credentials to manage different clusters.

Change the current context using {{code|kubectl config use-context my-context}}

=== Config File ===
Located in {{code|~/.kube/config}}. This file contains credentials to authenticate to the cluster.

It contains the default namespace and context values.

=== Kubernetes API ===
The Kubernetes API is a RESTful API, providing access to the Kubernetes backend.

Objects in the Kubernetes API are represented as JSON or Yaml files. Files can be used to create, update, or delete objects from the server.

{| class="wikitable"
|-
! Description !! Command
|-
| Create/Update || {{highlight|lang=terminal|code=
# kubectl apply -f obj.yaml
}}
|-
| Edit || {{highlight|lang=terminal|code=
# kubectl edit <resource-name> <object-name>
}}
|-
| Delete || {{highlight|lang=terminal|code=
# kubectl delete -f obj.yaml
## or
# kubectl delete <resource-name> <object-name>
}}
|}

All objects can be annotated or given a label.

{| class="wikitable"
|-
! Description !! Command
|-
| Label pod 'bar' {{code|1=color=red}} || {{highlight|lang=terminal|code=
# kubectl label pods bar color=red
## pass --overwrite if it already exists.
}}
|-
| Remove label {{code|color}} from pod 'bar' || {{highlight|lang=terminal|code=
# kubectl label pods bar -color
}}
|}

=== Master Node ===
A master node contains containers that provide the API server, scheduler, etc. that manages the cluster.

The master node should have the following components:
* {{code|controller-manager}}: Responsible for running controllers that regulate behavior int he cluster. Eg. ensure replicas for a service are available and healthy.
* {{code|scheduler}}: Places pods into different nodes in the cluster
* {{code|etcd}}: storage for cluster; stores API objects.

All components deployed by Kubernetes run under the kube-system namespace.

{{highlight|lang=terminal|code=
# kubectl describe nodes kube
...
Non-terminated Pods: (8 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
--------- ---- ------------ ---------- --------------- -------------
kube-system coredns-576cbf47c7-6mphw 100m (2%) 0 (0%) 70Mi (0%) 170Mi (2%)
kube-system coredns-576cbf47c7-75n6g 100m (2%) 0 (0%) 70Mi (0%) 170Mi (2%)
kube-system etcd-kube 0 (0%) 0 (0%) 0 (0%) 0 (0%)
kube-system kube-apiserver-kube 250m (6%) 0 (0%) 0 (0%) 0 (0%)
kube-system kube-controller-manager-kube 200m (5%) 0 (0%) 0 (0%) 0 (0%)
kube-system kube-proxy-cmdsn 0 (0%) 0 (0%) 0 (0%) 0 (0%)
kube-system kube-scheduler-kube 100m (2%) 0 (0%) 0 (0%) 0 (0%)
kube-system weave-net-swwgs 20m (0%) 0 (0%) 0 (0%) 0 (0%)
...
}}

The Kubernetes proxy is responsible for routing network traffic to services in the kubernetes cluster. (Question: Does it do the load balancing?). A proxy exists on every node.

{{highlight|lang=terminal|code=
# kubectl get daemonsets --namespace=kube-system
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
kube-proxy 1 1 1 1 1 <none> 26h
weave-net 1 1 1 1 1 <none> 28m
}}

Question: What is a DaemonSet?

Kubernetes also runs a DNS server that provides naming and discovery for services in the cluster.

{{highlight|lang=terminal|code=
# kubectl get deployments --namespace=kube-system
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
coredns 2 2 2 2 26h

# kubectl get services --namespace=kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 26h
}}

The DNS service for the cluster runs on 10.96.0.10. If you log into a container in the cluster, this server will be used as the primary DNS server.

Kubernetes Dashboard UI can be installed. Like the DNS service, it is both a deployment and a service:
{{highlight|lang=terminal|code=
# kubectl get deployments --namespace=kube-system kubernetes-dashboard
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
kubernetes-dashboard 1 1 1 1 2m26s

[root@kube ~]# kubectl get services --namespace=kube-system kubernetes-dashboard
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes-dashboard ClusterIP 10.108.158.128 <none> 443/TCP 2m36s
}}

Run {{code|kubectl proxy}} to proxy the server on {{code|localhost:8001}} and then access it in a web browser at {{code|http://localhost:8001/ui}}. If this is on a remote server, create a SSH tunnel.

=== Kubernetes Node ===

The scheduler will place containers on Kubernetes (worker) nodes. The scheduler does this by checking a node's taint and will not schedule pods on nodes that contain things like {{code|node-role.kubernetes.io/master:NoSchedule}}. Attempting to do so will result in a {{code|FailedScheduling}} status and a message of {{code|0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate.}} when looking at pod events using {{code|kubectl describe pods pod-name}}.

== Commands ==

The {{code|kubectl}} command line tool is the official kubernetes client for interacting with the Kubernetes API.

{| class="wikitable"
|-
! Description !! Command
|-
| Get all nodes
| {{highlight|lang=terminal|code=
# kubectl get nodes
}}
|-
| Get all pods
| {{highlight|lang=terminal|code=
# kubectl get pods --all-namespaces
}}
|-
| Get information about a node
| {{highlight|lang=terminal|code=
# kubectl describe nodes
}}
|-
| See components in the cluster
| {{highlight|lang=terminal|code=
# kubectl get componentstatuses
}}
|}

Tips:
When using {{code|kubectl get}}, pass
* {{code|--no-headers}} to remove headers for easier parsing
* {{code|-o json{{!}}yaml}} to format output in json/yaml.

{| class="wikitable"
|-
! Description !! Command
|-
| Create a pod
| {{highlight|lang=terminal|code=
# kubectl run kuard --image=gcr.io/kuar-demo/kuard-amd64:1
# kubectl apply -f kuard-pod.yaml
}}
|-
| Listing pods
| {{highlight|lang=terminal|code=
# kubectl get pods
## Filter by label with -l, can supply multiple of these.
# kubectl get pods -l label=something
}}
|-
| Delete pod
| {{highlight|lang=terminal|code=
# kubectl delete deployments/kuard
# kubectl delete -f kuard-pod.yaml
}}
|-
| Pod Details
| {{highlight|lang=terminal|code=
# kubectl describe pods kuard
}}
|-
| Pod Logs
| {{highlight|lang=terminal|code=
# kubectl logs kuard
}}
|-
| Enter a container
| {{highlight|lang=terminal|code=
# kubectl exec kuard cmd
# kubectl exec -it kuard sh
}}
|-
| Copy to/from container
| {{highlight|lang=terminal|code=
# kubectl cp podname:/src ./dst
# kubectl cp ./src podname:/dst
}}
|}

A pod manifest looks something like this:
{{highlight|lang=text|code=
apiVersion: v1
kind: Pod
metadata:
name: kuard
spec:
containers:
- image: gcr.io/kuar-demo/kuard-amd64:1
name: kuard
ports:
- containerPort: 8080
name: http
protocol: TCP
}}

== Questions ==
* What is involved in setting up a cluster on multiple VMs?
* What is the Kubernetes API?
* What is this persistent storage (etcd)?
* What is the WeaveWorks network and how does it work?

== See Also ==
* [https://kubernetes.io/docs/reference/kubectl/cheatsheet/ Command cheat sheet]
* Kubernetes: Up & Running
* CouchDB failover demo: https://blog.couchbase.com/databases-on-kubernetes/
* [https://medium.freecodecamp.org/learn-kubernetes-in-under-3-hours-a-detailed-guide-to-orchestrating-containers-114ff420e882?gi=f98022e78170 A Kubernetes Guide]
* https://kubernetes.io/docs/tutorials/stateless-application/guestbook/ Simple overview on deploying a guestbook application

* <s>MySQL on Kubernetes https://www.youtube.com/watch?v=J7h0F34iBx0</s> Not exactly beginner friendly. Goes over the MySQLOperator and Vitess

Leo's Notes - User contributions [en]

GitLab

Kubernetes