Update kubelet tutorial

pull/863/head
rsavchuk 2023-04-25 23:23:50 +02:00
parent 180ed492f0
commit f58bfe2a21
3 changed files with 74 additions and 202 deletions

View File

@ -29,4 +29,4 @@ Each worker node includes the following components:
During the tutorial, we will configure each component one by one (in a more or less logical way) and try to understand a bit more deeply the responsibilities of each component.
Next: [Container runtime](./docs/01-container-runtime.md)
Next: [Container runtime](./01-container-runtime.md)

View File

@ -201,166 +201,4 @@ Now, lets clean-up.
ctr task rm busybox-container
```
Next: [Kubelet](./docs/02-kubelet.md)
Ну раз так то доавайте його втановимо
Потрібо виключити свап і переконатись що він виключений
```bash
sudo swapon --show
```
```bash
sudo swapoff -a
```
Тепер давайте завантажимо всі необхідні бінарні файли для того щоб встановити наш кублєт
```bash
wget -q --show-progress --https-only --timestamping \
https://github.com/opencontainers/runc/releases/download/v1.0.0-rc93/runc.amd64 \
https://github.com/containerd/containerd/releases/download/v1.4.4/containerd-1.4.4-linux-amd64.tar.gz \
https://storage.googleapis.com/kubernetes-release/release/v1.21.0/bin/linux/amd64/kubelet
```
Тепер починаємо робиратись із тим що і для чього ми тільки що завантажували
1. runc - штука яка власне і запускаю контейнери, так давайте її перенесемо куда потрібно
```bash
{
sudo mv runc.amd64 runc
chmod +x runc
sudo mv runc /usr/local/bin/
}
```
2. containerd - штука яка використовується кублетом для запуску контейнерів, він рансі відрізняється тим що контейнерді уже вміє окрім запуску самих контейнерів отримувати образи, і робити ще всяких багато різних і цікавих речей, так давайте її відконфігуруємо
```bash
{
mkdir containerd
tar -xvf containerd-1.4.4-linux-amd64.tar.gz -C containerd
sudo mv containerd/bin/* /bin/
}
```
створимо директорію в якій буде лежати конфіг контейнерді
```bash
sudo mkdir -p /etc/containerd/
```
ну і сам конфіг, а у конфігу сказано що використовувати ми будемо рансі
```bash
cat << EOF | sudo tee /etc/containerd/config.toml
[plugins]
[plugins.cri.containerd]
snapshotter = "overlayfs"
[plugins.cri.containerd.default_runtime]
runtime_type = "io.containerd.runtime.v1.linux"
runtime_engine = "/usr/local/bin/runc"
runtime_root = ""
EOF
```
такс, контейнер ді уже готовий, можна створюватиюніт файл для запуску
```bash
cat <<EOF | sudo tee /etc/systemd/system/containerd.service
[Unit]
Description=containerd container runtime
Documentation=https://containerd.io
After=network.target
[Service]
ExecStartPre=/sbin/modprobe overlay
ExecStart=/bin/containerd
Restart=always
RestartSec=5
Delegate=yes
KillMode=process
OOMScoreAdjust=-999
LimitNOFILE=1048576
LimitNPROC=infinity
LimitCORE=infinity
[Install]
WantedBy=multi-user.target
EOF
```
ну тепер залишилось тільки запустити сам демон
```bash
{
sudo systemctl daemon-reload
sudo systemctl enable containerd
sudo systemctl start containerd
}
```
щоб переконатись що все запустилось і працює успішно, давайте перевіримо що наш сервіс працює
```bash
sudo systemctl status containerd
```
маємо отримати щось наприкладі
```
● containerd.service - containerd container runtime
Loaded: loaded (/etc/systemd/system/containerd.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2023-04-15 21:04:43 UTC; 59s ago
Docs: https://containerd.io
Process: 1018 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS)
Main PID: 1031 (containerd)
Tasks: 9 (limit: 2275)
Memory: 22.0M
CGroup: /system.slice/containerd.service
└─1031 /bin/containerd
...
```
що цікаво, так це то що у нас уже є енджін який вміє запускати контейнери, і мо мощемо щось запустити
так давайте не втрачати час і запустимо бізівокс (штука яка нас буде ще довго супроводжувати)
```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
```
для початку спулимо імедж
```bash
sudo ctr images pull docker.io/library/busybox:latest
```
ця команда має показати щось цікаве
```bash
ctr images ls
```
ну і тепер запустимо наш контейнер
```bash
sudo ctr run --rm --detach docker.io/library/busybox:latest busybox-container sh -c 'echo "Hello, World!"'
```
мали побачити що у консоль виелось хело волд
такс ну тереп давайте почистимо з собою
```bash
ctr task rm busybox-container
```
Next: [Kubelet](./02-kubelet.md)

View File

@ -1,16 +1,24 @@
# Static pods
# Kubelet
![image](./img/02_cluster_architecture_kubelet.png "Kubelet")
як бачимо контейнери запускаються все працює
прийшла пора розбиратись із kubectl
In this part of tutorial we will configure (let's say partially) configure kubelet on our server.
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.
> The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy.
So, lets set up kubelet and run some pod.
First of all we need to download kubelet binary
для початку його потрібно завантажити
```bash
wget -q --show-progress --https-only --timestamping \
https://storage.googleapis.com/kubernetes-release/release/v1.21.0/bin/linux/amd64/kubelet
```
Make file exacutable and move to the bin folder
```bash
{
chmod +x kubelet
@ -18,6 +26,8 @@ wget -q --show-progress --https-only --timestamping \
}
```
And the last part when configuring kubelet - create service to run kubelet.
```bash
cat <<EOF | sudo tee /etc/systemd/system/kubelet.service
[Unit]
@ -43,6 +53,12 @@ WantedBy=multi-user.target
EOF
```
The main configuration parameters here:
- --container-runtime-endpoint - linux soket on which containerd listed for the requests
- --file-check-frequency - how often kubelet will check for the updates of static pods
- --pod-manifest-path - directory where we will place our pod manifest files
Now, let's start our service
```bash
{
sudo systemctl daemon-reload
@ -51,10 +67,12 @@ EOF
}
```
And check service status
```bash
sudo systemctl status kubelet
```
Output:
```
● kubelet.service - kubelet: The Kubernetes Node Agent
Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: enabled)
@ -68,13 +86,20 @@ sudo systemctl status kubelet
...
```
# run static pod
знач нам потрбіно створити директорію для маніфестів
After kubelet service up and running, we can start creating our pods.
To do that we will use static pods feature of kubelet.
> Static Pods are managed directly by the kubelet daemon on a specific node, without the API server observing them.
Before we will create static pod manifests, we need to create folders where we will place our pods (as we can see from kibelet configuration, it sould be /etc/kubernetes/manifests)
```bash
{
mkdir /etc/kubernetes
mkdir /etc/kubernetes/manifests
}
```
After directory created, we can create static with busybox inside
```bash
cat <<EOF> /etc/kubernetes/manifests/static-pod.yml
@ -93,12 +118,27 @@ spec:
EOF
```
а тепепр поки він його знайде і запустить, ми встановимо crictl
We can check if containerd runned new container
```bash
ctr tasks ls
```
Output:
```bash
TASK PID STATUS
```
Looks like containerd didn't created any containrs yet?
Of course it may be true, but baed on the output of ctr command we can't answer that question. It is not true (of course it may be true, but based on the output of the ctr command we can't confirm that ////more about that here)
To see containers managed by kubelet lets install [crictl](http://google.com/crictl).
Download 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
```
Install (move to bin folder)
```bash
{
tar -xvf crictl-v1.21.0-linux-amd64.tar.gz
@ -106,8 +146,7 @@ wget -q --show-progress --https-only --timestamping \
sudo mv crictl /usr/local/bin/
}
```
трохи відконфігуруємо
And configure a bit
```bash
cat <<EOF> /etc/crictl.yaml
runtime-endpoint: unix:///run/containerd/containerd.sock
@ -117,64 +156,59 @@ debug: false
EOF
```
ну і тепер поки все встановлювалось то наш под мав піднятись
спробуємо подивитись
And we can finaly get the list of pods running on our server
```bash
crictl pods
```
тут є жжназва сервера
Outout:
```
POD ID CREATED STATE NAME NAMESPACE ATTEMPT RUNTIME
884c50605b546 9 minutes ago Ready static-pod-example-server default 0 (default)
POD ID CREATED STATE NAME NAMESPACE ATTEMPT RUNTIME
16595e954ab3e 8 minutes ago Ready static-pod-example-server default 0 (default)
```
і контейнери
As we can see our pod is up and running.
Also, we can check the containers running inside our pod
```bash
crictl ps
```
Output:
```
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
4cc95ba71e9d6 7cfbbec8963d8 10 minutes ago Running busybox 0 884c50605b546
912487fb63f9e 7cfbbec8963d8 10 minutes ago Running busybox 0 16595e954ab3e
```
ну і також можна глянути логи
Looks like our container is in running state.
Lets check its logs.
```bash
crictl logs $(crictl ps -q)
```
Output:
```
Hello from static hostNetwork pod
Hello from static hostNetwork pod
Hello from static hostNetwork pod
Hello from static hostNetwork pod
Hello from static hostNetwork pod
Hello from static hostNetwork pod
Hello from static hostNetwork pod
Hello from static hostNetwork pod
Hello from static hostNetwork pod
Hello from static hostNetwork pod
Hello from static pod
Hello from static pod
Hello from static pod
...
```
такс, ну на цьому нам потрібно почитити все після себе
Great, now we can run pods on our server.
Before we will continue, remove our pods running
```bash
rm /etc/kubernetes/manifests/static-pod.yml
```
тепер має видалитись контейнер, але потрібно трохи почекати
```bash
crictl ps
```
тут пусто
It takes some time to remove the pods, we can ensure that pod are deleted by running
```bash
{
crictl pods
crictl ps
}
```
і тут з часом також має стати пусто
The output shuld be empty.
ну всьо, на цьому на сьогодні все поки
далі будемо розбиратись із іншими компонентами кудетнетесу
Next: [Pod networking](./03-pod-networking.md)