Difference between revisions of "Kubernetes"

From Zombi Wiki
Jump to navigation Jump to search
(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.

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

k9s