diff --git a/docs/01-container-runtime.md b/docs/01-container-runtime.md index 0e02e2d..66b3495 100644 --- a/docs/01-container-runtime.md +++ b/docs/01-container-runtime.md @@ -1,6 +1,6 @@ # Container runtime -In this section, we will focus on the container runtime, as it is part of the Kubernetes which is responsible for running containers. +In this section, we will focus on the container runtime. ![image](./img/01_cluster_architecture_container_runtime.png "Container runtime") @@ -13,7 +13,7 @@ A thing like OCI can help us here. As we can see from the description - OCI is a standard that tells us what is a container image and how to run it. -But it is only a standard, obviously there is some tool that implements this standard. And it is true, runc is a reference implementation of the OCI runtime specification. +But it is only a standard, obviously, there is some tool that implements this standard. And it is true, runc is a reference implementation of the OCI runtime specification. So let's install it and run some container with the usage of runc @@ -24,7 +24,7 @@ wget -q --show-progress --https-only --timestamping \ https://github.com/opencontainers/runc/releases/download/v1.0.0-rc93/runc.amd64 ``` -After download process complete, we need to move runc binaries to proper folder +After the download process is complete, we need to move runc binaries to proper folder ```bash { @@ -49,7 +49,7 @@ sed -i 's/"sh"/"echo","Hello from container runned by runc!"/' config.json } ``` -On this step we downloaded the busybox immage, unarchived it and created proper files, required by runc to run the container (including container confguration and files which will be accesible from container). So, lets run our container +In this step, we downloaded the busybox image, unarchived it, and created the proper files, required by runc to run the container (including container configuration and files that will be accessible from the container). So, let's run our container ```bash runc run busybox @@ -60,7 +60,7 @@ Output: Hello from container runned by runc! ``` -Great, we create our first container in this tutorial. Now we will clean up our workspace. +Great, we created our first container in this tutorial. Now we will clean up our workspace. ```bash { cd ~ @@ -72,12 +72,12 @@ rm -r busybox-container As we can see, runc can run containers, but runc interface is something unknown for kubernetes. -There is another standert defined which is used by kubelet to communicate with container runtime - CRI +There is another standard defined which is used by kubelet to communicate with container runtime - CRI > The CRI is a plugin interface which enables the kubelet to use a wide variety of container runtimes, without having a need to recompile the cluster components. -In this tutorial we will use [containerd](https://github.com/containerd/containerd) as tool which is compattible with CRI. +In this tutorial, we will use [containerd](https://github.com/containerd/containerd) as a tool which is compattible with CRI. -To deploy containerd, first of all we need to download it. +To deploy containerd, first of all, we need to download it. ```bash wget -q --show-progress --https-only --timestamping \ @@ -94,7 +94,7 @@ After download process complete, we need to unzip and move containerd binaries t } ``` -In comparison to the runc, containerd is a service works like a service which can be called by someone to run container. It means that we need to run it, before we can start comminucate with it. +In comparison to the runc, containerd is a service that works like a service that can be called by someone to run a container. It means that we need to run it before we can start communicating with it. We will configure containerd as a service. @@ -156,7 +156,7 @@ To ensure that our service successfully started, run sudo systemctl status containerd ``` -The output should be similar to +Output: ``` ● containerd.service - containerd container runtime Loaded: loaded (/etc/systemd/system/containerd.service; enabled; vendor preset: enabled) @@ -173,14 +173,14 @@ The output should be similar to Now, we have containerd service running. It means that we can try to create some container. -To do that, we need the tool called [ctr](https://github.com/projectatomic/containerd/blob/master/docs/cli.md), which is distributed as part of containerd (means that we already installed it during installation of containerd). +To do that, we need the tool called [ctr](https://github.com/projectatomic/containerd/blob/master/docs/cli.md), which is distributed as part of containerd (which means that we already installed it during the installation of containerd). -First of all we will pull busybox image +First of all, we will pull busybox image ```bash sudo ctr images pull docker.io/library/busybox:latest ``` -After pull process complete - check our image +After the pull process is complete - check our image ```bash ctr images ls ``` @@ -191,19 +191,17 @@ REF TYPE docker.io/library/busybox:latest application/vnd.docker.distribution.manifest.list.v2+json sha256:b5d6fe0712636ceb7430189de28819e195e8966372edfc2d9409d79402a0dc16 2.5 MiB linux/386,linux/amd64,linux/arm/v5,linux/arm/v6,linux/arm/v7,linux/arm64/v8,linux/mips64le,linux/ppc64le,linux/riscv64,linux/s390x - ``` -Now, lets start our container. +Now, let's start our container ```bash ctr run -t --rm --detach docker.io/library/busybox:latest busybox-container sh -c 'echo "Hello from container runned by containerd!"' ``` -Our container successfully started, - Output: ```bash Hello from container runned by containerd! ``` -As we can see we successfully started container, now we can check it status +As we can see we successfully started the container, now we can check its status ```bash ctr containers ls ``` @@ -214,7 +212,7 @@ CONTAINER IMAGE RUNTIME busybox-container docker.io/library/busybox:latest io.containerd.runc.v2 ``` -But there is not info about the status, we can see it by reviewing tasks (hope that I will write something about it). +But there is no info about the status, we can see it by reviewing tasks ```bash ctr task ls ``` @@ -225,9 +223,9 @@ TASK PID STATUS busybox-container 2862580 STOPPED ``` -As we can see our container is in stoped state (because command successfully executed and container stopped). +As we can see our container is in the stopped state (because the command was successfully executed and the container stopped). -Now, lets clean-up our workspace and go to the next section. +Now, let's clean up our workspace and go to the next section. ```bash ctr containers rm busybox-container ``` diff --git a/docs/02-kubelet.md b/docs/02-kubelet.md index e25c2df..0872d1f 100644 --- a/docs/02-kubelet.md +++ b/docs/02-kubelet.md @@ -1,8 +1,8 @@ # Kubelet -In this part of tutorial we will configure (it is better to say that we will partially configure) kubelet on our server. +In this part of the tutorial, we will configure (it is better to say that we will partially configure) kubelet on our server. -But before we will configure kubelet, lets talk a bit about it. +But before we will configure kubelet, let's talk a bit about it. As mentioned in the official kubernetes documentation: > An agent that runs on each node in the cluster. It makes sure that containers are running in a Pod. @@ -11,20 +11,20 @@ As mentioned in the official kubernetes documentation: ![image](./img/02_cluster_architecture_kubelet.png "Kubelet") As we can see, in this section we will work with the next layer of kubernetes components (if I can say so). -Previously we worked with containers, but on this step we will work with other afteraction kubernetes has - pod. +Previously we worked with containers, but on this step, we will work with other abstraction kubernetes has - pod. -As you remember at the end, kubernetes usually start pods. So now we will try to create it. But it a bit not usual way, instead of using kubernetes api (which we didn't configured yet), we will create pods with the usage of kubelet only. +As you remember at the end, kubernetes usually start pods. So now we will try to create it. But it is a bit not the usual way, instead of using kubernetes api (which we didn't configure yet), we will create pods with the usage of kubelet only. To do that we will use the [static pods](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/) functionality. -So, lets begin. +So, let's begin. -First of all we need to download kubelet. +First of all, we need to download kubelet. ```bash wget -q --show-progress --https-only --timestamping \ https://storage.googleapis.com/kubernetes-release/release/v1.21.0/bin/linux/amd64/kubelet ``` -After download process complete, muve kubelet binaries to the proper folder +After download process complete, move kubelet binaries to the proper folder ```bash { chmod +x kubelet @@ -32,7 +32,7 @@ After download process complete, muve kubelet binaries to the proper folder } ``` -As kubelet is a service which is used to manage pods running on the node, we need to configure that service +As kubelet is a service that is used to manage pods running on the node, we need to configure that service ```bash cat < /etc/kubernetes/manifests/static-pod.yml apiVersion: v1 @@ -120,7 +120,7 @@ spec: EOF ``` -Now lets use the ctr tool we already know to list the containers created +Now, let's use the ctr tool we already know to list the containers created ```bash ctr containers ls ``` @@ -130,10 +130,10 @@ Output: CONTAINER IMAGE RUNTIME ``` -Looks like containerd didn't created any containrs yet? -Of course it may be true, but based on the output of ctr command we can't confirm that. +Looks like containerd didn't create any containers yet. +Of course, it may be true, but based on the output of ctr command we can't confirm that. -Containerd has namespace feature. Namespace is a mechanism used to provide isolation and separation between different sets of resources. +Containerd has a namespace feature. Namespace is a mechanism used to provide isolation and separation between different sets of resources. We can check containerd namespaces by running ```bash @@ -171,17 +171,17 @@ e75eb4ac89f32ccfb6dc6e894cb6b4429b6dc70eba832bc6dea4dc69b03dec6e 1524 RUNN 33d2725dd9f343de6dd0d4b77161a532ae17d410b266efb31862605453eb54e0 1472 RUNNING ``` -But it is not what we expected, we expected to see container named busybox. Of course there is no majic, all anformation about pod to which this container belongs to, kubernetes containername, etc are located in the metadata on the container, and can be easilly extracted with the usage of other crt command (like this - ctr --namespace k8s.io containers info a597ed1f8dee6a43d398173754fd028c7ac481ee27e09ad4642187ed408814b4). but we want to see it in a bit more readable format, this is why, we will use different tool - [crictl](http://google.com/crictl). +But it is not what we expected, we expected to see a container named busybox. Of course, there is no magic, all information about the pod to which this container belongs, kubernetes container name, etc are located in the metadata on the container, and can be easily extracted with the usage of other crt commands (like this - ctr --namespace k8s.io containers info a597ed1f8dee6a43d398173754fd028c7ac481ee27e09ad4642187ed408814b4). but we want to see it in a bit more readable format, this is why, we will use a different tool - [crictl](http://google.com/crictl). -In Comparison to the ctr (which can work with containerd only), crictl is a tool which interracts with any CRI compliant runtime, containerd is only runtime we use in this tutorial. Also, cri ctl provide information in more "kubernetes" way (i mean it can show pods and containers with names like in kubernetes). +In comparison to the ctr (which can work with containerd only), crictl is a tool that interacts with any CRI-compliant runtime, containerd is the runtime we use in this tutorial. Also, crictl provides information in more "kubernetes" way (I mean it can show pods and containers with names like in kubernetes). -So, lets download crictl binaries +So, let's download crictl binaries ```bash wget -q --show-progress --https-only --timestamping \ https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.21.0/crictl-v1.21.0-linux-amd64.tar.gz ``` -After download process complete, move crictl binaries to the proper folder +After the download process is complete, move crictl binaries to the proper folder ```bash { tar -xvf crictl-v1.21.0-linux-amd64.tar.gz @@ -200,9 +200,9 @@ debug: false EOF ``` -As already mentioned, crictl can be configured to use any CRI complient runtime, in our case we configured containerd (by providing containerd socket path). +As already mentioned, crictl can be configured to use any CRI-compliant runtime, in our case we configured containerd (by providing containerd socket path). -And we can finaly get the list of pods running on our server +And finally, we can get the list of pods running on our server. ```bash crictl pods ``` @@ -226,8 +226,8 @@ CONTAINER IMAGE CREATED STATE 912487fb63f9e 7cfbbec8963d8 10 minutes ago Running busybox 0 16595e954ab3e ``` -Looks like our container is in running state. -Lets check its logs. +Looks like our container is in a running state. +Let's check its logs. ```bash crictl logs $(crictl ps -q) ``` @@ -242,12 +242,12 @@ Hello from static pod Great, now we can run pods on our server. -Now, lets clean up our worspace and continue with the next section +Now, let's clean up our workspace and continue with the next section ```bash rm /etc/kubernetes/manifests/static-pod.yml ``` -It takes some time to remove the pods, we can ensure that pod are deleted by running +It takes some time to remove the pods, we can ensure that pods are deleted by running ```bash { crictl pods @@ -255,6 +255,6 @@ crictl ps } ``` -The output shuld be empty. +The output should be empty. Next: [Pod networking](./03-pod-networking.md) \ No newline at end of file