Difference between revisions of "Kubernetes"
(Created page with "As we ran into several problems with the deployment of docker-compose, when we introduced our second root server Stratholme, we want to migrate to wikipedia:Kubernetes|K...") |
|||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
As we ran into several problems with the deployment of docker-compose, when we introduced our second root server [[Stratholme]], we want to migrate to [[wikipedia:Kubernetes|Kubernetes]], or more precisely to k3s, a lightweight Kubernetes-distribution. We have a Jour fixe to work on this every monday at 7pm CEST/CET. | As we ran into several problems with the deployment of docker-compose, when we introduced our second root server [[Stratholme]], we want to migrate to [[wikipedia:Kubernetes|Kubernetes]], or more precisely to k3s, a lightweight Kubernetes-distribution. We have a Jour fixe to work on this every monday at 7pm CEST/CET. | ||
| + | = resources = | ||
| + | == pod == | ||
| + | pods are more-or-less equivalent to containers | ||
| + | |||
| + | the simplest way to start a pod is to create a temporary file | ||
| + | |||
| + | <syntaxhighlight lang="yaml"> | ||
| + | apiVersion: v1 | ||
| + | kind: Pod | ||
| + | metadata: | ||
| + | name: shell-debug | ||
| + | spec: | ||
| + | containers: | ||
| + | - name: debian | ||
| + | image: debian | ||
| + | command: ['bash', '-c', 'sleep infinity'] | ||
| + | </syntaxhighlight> | ||
| + | |||
| + | and apply it with | ||
| + | <code>kubectl apply -f file.yaml</code>. you can also apply it directly from stdin using | ||
| + | <syntaxhighlight lang="bash"> | ||
| + | kubectl apply -f - <<EOF | ||
| + | kind: Pod | ||
| + | metadata: | ||
| + | ... | ||
| + | EOF | ||
| + | </syntaxhighlight> | ||
| + | |||
| + | == deployment == | ||
| + | A deployment creates a replica-set, that can consist out of several pods. Deployments can be used for stateless services, e.g. our website. Services that are not stateless can be deployed with [[#statefulset|statefulsets]] | ||
| + | == StatefulSet == | ||
| + | ''Statefulsets'' will start [[#pod|pods]], similar to [[#deployment|deployments]], but will also create a new volume for each new pod and automatically mount the respective volumes on pods that have been restarted. | ||
| + | |||
| + | == DaemonSet == | ||
| + | == persistentvolume == | ||
| + | ''persistentvolume''s are usually automatically created, when a [[#persistentvolumeclaim|persistentvolumeclaim]] is being created. | ||
| + | == persistentvolumeclaim == | ||
| + | ''Persistentvolumeclaim''s relate [[#pod|pods]] to [[#persistentvolume|persistentvolumes]]. They are usually automatically created when a pod needs a volume. | ||
| + | |||
| + | = files = | ||
| + | == kubeconfig.yml == | ||
| + | k9s tools read a configuration file that has to be specified via the environment variable <code>KUBECONFIG</code>. | ||
| + | |||
| + | Each cluster requires an own ''kubeconfig.yml'' | ||
| + | |||
| + | == manifest files == | ||
| + | ''manifest files'' can be yml or json, but yml is preferred by us and generally are more common. | ||
| + | a manifest file defines one or more [[#resource|resources]]. If you want to declare more than one resource in a single manifest yaaml, you can use multiple yaml ''documents'' , that can be split via <code>---</code>. | ||
| + | You could for instance declare a [[#persistentvolumeclaim|persistentvolumeclaim]] and a [[#deployment|deployment]] in the same file. | ||
| + | Each resource requires at least the following attributes: | ||
| + | === apiVersion === | ||
| + | As of June 2020, this should always be <code>apps/v1</code> | ||
| + | |||
| + | === kind === | ||
| + | The kind attribute specifies, which kind of [[#resource|resource]] is being declared. | ||
| + | |||
| + | === metadata === | ||
| + | Within the metadata attribute there should at least be a <code>name</code> attribute, that gives the resource a meaningful name. | ||
| + | === spec === | ||
| + | Additional Specs of the [[#resource|resource]] can be specified within the ''spec'' attribute. | ||
| + | = tools = | ||
| + | |||
| + | == kubectl == | ||
| + | kubectl is the tool to apply changes to | ||
| + | |||
| + | == k9s == | ||
| + | |||
| + | |||
[[author::user:cpp| ]] | [[author::user:cpp| ]] | ||
| − | [[Date::2020-06-22 19:00 CEST]] | + | [[Date::2020-06-22 19:00 CEST| ]] |
[[Category:Documentation]] | [[Category:Documentation]] | ||
Latest revision as of 11:40, 20 June 2021
As we ran into several problems with the deployment of docker-compose, when we introduced our second root server Stratholme, we want to migrate to Kubernetes, or more precisely to k3s, a lightweight Kubernetes-distribution. We have a Jour fixe to work on this every monday at 7pm CEST/CET.
Contents
resources
pod
pods are more-or-less equivalent to containers
the simplest way to start a pod is to create a temporary file
apiVersion: v1
kind: Pod
metadata:
name: shell-debug
spec:
containers:
- name: debian
image: debian
command: ['bash', '-c', 'sleep infinity']
and apply it with
kubectl apply -f file.yaml. you can also apply it directly from stdin using
kubectl apply -f - <<EOF
kind: Pod
metadata:
...
EOF
deployment
A deployment creates a replica-set, that can consist out of several pods. Deployments can be used for stateless services, e.g. our website. Services that are not stateless can be deployed with statefulsets
StatefulSet
Statefulsets will start pods, similar to deployments, but will also create a new volume for each new pod and automatically mount the respective volumes on pods that have been restarted.
DaemonSet
persistentvolume
persistentvolumes are usually automatically created, when a persistentvolumeclaim is being created.
persistentvolumeclaim
Persistentvolumeclaims relate pods to persistentvolumes. They are usually automatically created when a pod needs a volume.
files
kubeconfig.yml
k9s tools read a configuration file that has to be specified via the environment variable KUBECONFIG.
Each cluster requires an own kubeconfig.yml
manifest files
manifest files can be yml or json, but yml is preferred by us and generally are more common.
a manifest file defines one or more resources. If you want to declare more than one resource in a single manifest yaaml, you can use multiple yaml documents , that can be split via ---.
You could for instance declare a persistentvolumeclaim and a deployment in the same file.
Each resource requires at least the following attributes:
apiVersion
As of June 2020, this should always be apps/v1
kind
The kind attribute specifies, which kind of resource is being declared.
metadata
Within the metadata attribute there should at least be a name attribute, that gives the resource a meaningful name.
spec
Additional Specs of the resource can be specified within the spec attribute.
tools
kubectl
kubectl is the tool to apply changes to
