#1. 왜 AWS EC2 에 kubernetes 를 깔아야 하는가?
돈을 아끼려고 EC2에 다 깔아서 docker 컨테이너를 다 꽉꽉 채워서 돌리면 좋겠다.
심지어 graviton 2~3 같은 효율 좋은 코어를 쓴다면!!!
#2. 깔아보자 kubernetes
설치 고민을 안하려고 ubuntu OS를 골라서 복붙만해서 깔아본다.
공식 홈페이지 링크 kubeadm, kubelet, kubectl 다 깔자
sudo apt-get update
# apt-transport-https may be a dummy package; if so, you can skip that package
sudo apt-get install -y apt-transport-https ca-certificates curl gpg
# If the folder `/etc/apt/keyrings` does not exist, it should be created before the curl command, read the note below.
# sudo mkdir -p -m 755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
# This overwrites any existing configuration in /etc/apt/sources.list.d/kubernetes.list
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.29/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
초기화를 해본다.
sudo kubeadm init
안된다. 공홈에도 써있지만 CRI 가 설치되어 있어야, 뭐라도 진행된다. containerd CRI 설치하자.
[init] Using Kubernetes version: v1.29.2
[preflight] Running pre-flight checks
error execution phase preflight: [preflight] Some fatal errors occurred:
[ERROR IsPrivilegedUser]: user is not running as root
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
To see the stack trace of this error execute with --v=5 or higher
#3. 개념 잡기
Nginx 를 호스팅 해보자
kubectl create deployment nginx --image nginx
출력
error: failed to create deployment: Post "http://localhost:8080/apis/apps/v1/namespaces/default/deployments?fieldManager=kubectl-create&fieldValidation=Strict": dial tcp 127.0.0.1:8080: connect: connection refused
kubeadm 등등 환경설정이 안되서 안된다. 안되는 거 확인할라고 돌려본거다.
쿠버네티스도 모른다는 소리가 나오겠지….
옛날 생각을 다시 끄집어내어가면서 다시 공홈을 뒤진다.
Kubeadm 으로 컨트롤 환경을 설정한다.
2024년 말까지 t4g.micro arm aarch가 무료라고해서 쓰려는데 RAM이 1gb이라서 안된다는데 일단 한다.
Linux memory swap을 지원안하는데 1.28 group v2 만 지원한 다니까 그 이후 버전은 될 것같다. 안되면 다시 한다.
1. kubernetes 설정하기
Kubernetes(k8s)는 Control panel 을 설정하고 work node 컴퓨터를 설정하여 통합 컴퓨팅 환경을 구축하는 것에서 시작한다.
구축 된 환경에서 control panel 에 API를 이용하여 pod 같은 execution들을 관리한다.
high availability 설정을 하기 위해서는 control panel의 load-balance와 auto-failover를 설정해야 한다.
그냥 그런 설정없이 control panel을 한개만 둬도 되고, AWS나 Google이 제공하는 EKS 등을 사용해도 되겠지…
돈을 아끼기 위해서 EC2 하나로 해결하기 위해서는 k8s의 ingress(reverse proxy, API Gateway, whatever)는 사치이다.
sudo kubeadm init --v=5
안된댄다. 다시해야 한다.
[preflight] Some fatal errors occurred:
[ERROR Mem]: the system RAM (917 MB) is less than the minimum 1700 MB
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
그냥 포기하고 kubelet만 쓰는 방법이 있다는데 무슨 소리일까.
kubeadm 설정, kubernetes control panel 없이 돌릴 수 있다는 말 같은데,
내가 개념적으로 re-load가 필요하다.
2. Kubernetes 구성 요소 개념 확인
kubeadm 을 수행하는 과정에서 깔라고 하던데
cgroup 은 뭐냐…
Kubernetes에서 cgroup은 컨테이너의 리소스 제한과 관리를 위해 사용되는 리눅스 커널 기능 중 하나입니다. cgroup은 "Control Groups"의 줄임말로, 리소스를 그룹화하고 제한하는 데 사용됩니다.
cgroup은 컨테이너가 사용할 수 있는 CPU, 메모리, 디스크 I/O 및 네트워크 대역폭과 같은 리소스를 제어합니다. 이를 통해 Kubernetes는 각 컨테이너에 할당된 리소스 양을 관리하고, 리소스 사용량을 제한하거나 조절하여 클러스터의 안정성과 성능을 유지합니다.
예를 들어, Kubernetes에서는 사용자가 각 Pod 또는 컨테이너에 대해 CPU 및 메모리 리소스 제한을 설정할 수 있습니다. 이러한 제한은 cgroup을 통해 구현되며, cgroup은 리소스 제한을 적용하고 컨테이너가 그 제한을 초과하지 않도록 관리합니다.
따라서 cgroup은 Kubernetes에서 컨테이너의 리소스 사용을 제한하고 관리하는 데 중요한 역할을 합니다. 이를 통해 각 컨테이너가 필요한 만큼의 리소스를 사용할 수 있고, 다른 컨테이너에 영향을 미치지 않으면서 안정적으로 운영될 수 있습니다.
kubernetes control panel을 이용하지 않을 계획이므로, cgroup driver 를 설치할 필요가 없나?
왜 cgroup 이야기는 없고 CNI, CRI 설치와 kubelet만 다룰까…
한국어 번역본으로 봐서 그렇지 그냥 container runtime을 control 하려면 적당한 cgroup driver 를 설정해 두어라. 그래서 CRI 설치를 하고 잘 설정하면 kubelet을 쓸 수 있을거야 라는 뜻인가보다.
Configuring a cgroup driver
Both the container runtime and the kubelet have a property called "cgroup driver", which is important for the management of cgroups on Linux machines.
Warning:
Matching the container runtime and kubelet cgroup drivers is required or otherwise the kubelet process will fail.
See Configuring a cgroup driver for more details.
cgroup 설정 잘해, 안그러면 kubelet 이 안 돈다. 라고 써있구나….
1) CNI 가 뭐냐….
Kubernetes CNI는 "Container Network Interface"의 약자로, Kubernetes 클러스터 내에서 컨테이너 간 및 컨테이너와 외부 네트워크 간 통신을 관리하기 위한 표준 인터페이스입니다.
Kubernetes 클러스터는 여러 호스트(노드)에서 컨테이너가 실행되는 분산 시스템입니다. 이러한 컨테이너는 서로 통신하고 외부와 통신해야 합니다. 이를 가능하게 하는 것이 CNI입니다.
CNI는 네트워크 플러그인을 통해 Kubernetes에서 네트워크를 설정하고 관리합니다. 각 노드에는 이러한 CNI 플러그인이 설치되어 있어야 합니다. 이 플러그인은 다양한 네트워킹 솔루션을 사용할 수 있도록 하며, 플러그인의 종류에 따라 다양한 네트워킹 기능과 특성을 제공할 수 있습니다.
일반적으로 CNI 플러그인은 다음과 같은 작업을 수행합니다:
네트워크 인터페이스 설정: 컨테이너에 대한 가상 네트워크 인터페이스를 생성하고 구성합니다.
IP 주소 할당: 컨테이너에 IP 주소를 할당하고 네트워크 구성을 관리합니다.
루팅 및 포워딩 설정: 컨테이너 간 통신 및 외부와의 통신을 위한 라우팅 및 포워딩 설정을 구성합니다.
보안 및 정책 적용: 네트워크 보안 및 정책을 적용하여 컨테이너 간 통신을 제한하거나 보호합니다.
CNI를 통해 Kubernetes 클러스터는 유연하고 다양한 네트워킹 솔루션을 사용하여 네트워크를 구성할 수 있습니다. 예를 들어, Flannel, Calico, Weave 등의 다양한 CNI 플러그인이 있으며, 각각의 특성과 장단점을 고려하여 선택할 수 있습니다.
kubernetes control panel을 이용하지 않을 계획이므로, CNI를 직접 설치해야 하나보다.
2) CRI 는 뭐냐…
CRI는 "Container Runtime Interface"의 약어로, Kubernetes와 같은 컨테이너 오케스트레이션 시스템과 컨테이너 런타임 간의 표준화된 인터페이스입니다. CRI는 컨테이너 오케스트레이션 시스템이 컨테이너를 관리하고 실행하는 데 사용하는 API를 정의합니다.
기존에는 Kubernetes가 컨테이너를 관리하기 위해 Docker와 같은 특정 컨테이너 런타임에 직접 의존했습니다. 그러나 이는 Kubernetes가 다양한 컨테이너 런타임과 통합하기 어려웠고, 다른 컨테이너 런타임을 사용하고자 할 때 유연성이 부족했습니다.
CRI의 등장으로 Kubernetes는 컨테이너 런타임과의 통신을 표준화하고, 런타임을 변경하거나 대체할 때의 복잡성을 줄일 수 있게 되었습니다. 즉, CRI는 컨테이너 런타임과 Kubernetes 사이의 표준 인터페이스를 제공하여 오케스트레이션 시스템과 컨테이너 런타임 간의 결합을 느슨하게 만듭니다.
이를 통해 Kubernetes는 다양한 컨테이너 런타임을 지원하고, 개발자 및 운영자는 컨테이너 런타임을 선택하거나 변경할 수 있습니다. Containerd, CRI-O, Docker와 같은 다양한 컨테이너 런타임이 CRI를 구현하여 Kubernetes와 통합될 수 있습니다.
요약하면, CRI는 Kubernetes와 컨테이너 런타임 간의 표준화된 인터페이스로, Kubernetes가 다양한 런타임과 통합하고 유연성을 제공하는 데 중요한 역할을 합니다.
kubernetes control panel을 이용하지 않을 계획이므로, CRI를 직접 설치해야 하나보다.
3) Docker 와 Containerd 의 관계 – 좋은 참고 자료
Containerd는 컨테이너 실행을 관리하는 데 사용되는 오픈 소스 컨테이너 런타임입니다. 이는 Docker의 핵심 기능 중 하나이며, Docker에서 분리되어 개발된 프로젝트입니다. Containerd는 Kubernetes와 같은 컨테이너 오케스트레이션 시스템에서 컨테이너 실행을 관리하는 데 널리 사용됩니다.
따라서 "containerd를 사용해서 저것을 돌린다"는 말은 Kubernetes나 다른 컨테이너 오케스트레이션 시스템을 통해 컨테이너를 실행할 때, 실제로 컨테이너를 관리하고 실행하는 데 containerd가 사용된다는 의미입니다.
그렇다면 이미지는 도커(Docker)에서 가져오더라도, 컨테이너를 실행하는 데 containerd를 사용할 수 있습니다. 이는 도커(Docker)가 이미지를 가져오고 저장하는 데 사용되지만, containerd가 실제로 컨테이너를 관리하고 실행하는 데 사용될 수 있기 때문입니다.
간단히 말해서, 도커 이미지를 가져오더라도, Kubernetes 또는 다른 컨테이너 오케스트레이션 시스템을 통해 실행될 때 containerd가 컨테이너를 실행하는 데 사용될 수 있습니다. 이것은 이미지와 컨테이너를 관리하는 데 사용되는 도구와 컨테이너를 실행하는 데 사용되는 런타임이 분리될 수 있다는 유연성을 제공합니다.
결국은 Containerd 를 쓰건 말건 이미지는 docker 를 쓰건 말건 상관이 없단 말 이렸다….
CNI, CRI를 설치한다는 얘기는 cgroup도 설치해야 한다는 이야기 아닐까?
CRI를 설정해도, worker에서 pod 가 도는 것에 한계를 매겨야 하니까?
아 그냥 work의 resource 통제를 안하려면 cgroup driver는 설치하지 않아도 되나?
To set systemd as the cgroup driver, edit the KubeletConfiguration option of cgroupDriver and set it to systemd. For example:
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
cgroupDriver: systemd
Note: Starting with v1.22 and later, when creating a cluster with kubeadm, if the user does not set the cgroupDriver field under KubeletConfiguration, kubeadm defaults it to systemd.
In Kubernetes v1.28, with the KubeletCgroupDriverFromCRI feature gate enabled and a container runtime that supports the RuntimeConfig CRI RPC, the kubelet automatically detects the appropriate cgroup driver from the runtime, and ignores the cgroupDriver setting within the kubelet configuration.
1.28 부터는 cgroupDriver default 가 systemd 라고 하고, 거기서 cgroup driver for the container runtime 으로,
이 2가지를 예를 들 수 있다고 한다.
그냥 저걸 깔면 cgroup-driver가 구성된다는 거구나…
3. CGROUP 설정
1) 사전 설정
Forwarding IPv4 and letting iptables see bridged traffic
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF
# Apply sysctl params without reboot
sudo sysctl --system
Verify that the br_netfilter
, overlay
modules are loaded by running the following commands:
lsmod | grep br_netfilter
lsmod | grep overlay
Verify that target – 확인할 대상 목록
- net.bridge.bridge-nf-call-iptables,
- net.bridge.bridge-nf-call-ip6tables,
- net.ipv4.ip_forward net.bridge.bridge-nf-call-iptables,
- net.bridge.bridge-nf-call-ip6tables,
- net.ipv4.ip_forward
system variables are set to 1
in your sysctl
config by running the following command:
sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.ipv4.ip_forward
2) 일단 containerd 설치 – 링크
나는 ubuntu apt, dnf 로 설치하기 옵션을 활용하겠다. CNI plugin은 안깔린다고 함. 그럼 official binary로 깔면 깔린다는 말 이렸다….
# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
# Add the repository to Apt sources:
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
# sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
# docker에서 깔라고 알려주는거라 다 깔라는데.... 난.... compose는 깔지 않을래....
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin -y
3) default containerd 설정
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
일단 default config 가 적용된 모양이다. 일단 설정하고 k8s 공홈에서 본 내용을 점검 해보자.
Configuring the systemd cgroup driver
To use the systemd cgroup driver in /etc/containerd/config.toml with runc, set
disabled_plugins = []
...
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
...
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
containerd config default | sudo tee /etc/containerd/config.toml의 수행결과인
/etc/containerd/config.toml 의 설정에서 SystemdCgroup의 설정은 false 이다.
이거 true로 바꿔서도 도나 해봐야 겠다.
관련된 문제가 kubeadm 과정에서 CRI 의 문제로 에러메시지가 발생한다.
아래에 기록된 대로 따라서 해보면 버그 내용도 적혀있다.
- (SystemdCgroup 를 true 안해도 kubeadm init은 되더라 다른 옵션이 중요하다. 버그해결 솔루션 링크)
The systemd
cgroup driver is recommended if you use cgroup v2.
cgroup v2 쓰면 systemd 를 쓰라고 권장한다. 근데 그럼 나는?
근거 자료 링크에 따르면 ubuntu 22.04+ 에서도 권장한다고 한다.
Identify the cgroup version on Linux Nodes
The cgroup version depends on the Linux distribution being used and the default cgroup version configured on the OS. To check which cgroup version your distribution uses, run the stat -fc %T /sys/fs/cgroup/
command on the node:
stat -fc %T /sys/fs/cgroup/
For cgroup v2, the output is cgroup2fs
.
For cgroup v1, the output is tmpfs.
쳐보니 난 cgroup2fs 였다….. 해야되네….
Note:
If you installed containerd from a package (for example, RPM or .deb), you may find that the CRI integration plugin is disabled by default.
You need CRI support enabled to use containerd with Kubernetes. Make sure that cri is not included in thedisabled_plugins list within /etc/containerd/config.toml; if you made changes to that file, also restart containerd.
If you experience container crash loops after the initial cluster installation or after installing a CNI, the containerd configuration provided with the package might contain incompatible configuration parameters. Consider resetting the containerd configuration with containerd config default > /etc/containerd/config.toml as specified in getting-started.md and then set the configuration parameters specified above accordingly.
disabled_plugins 에 아무것도 없었는데도 안됬다. 바꾸니까 뭐가 좀 돈다…
4) containerd 서비스 실행
sudo systemctl daemon-reload
# sudo systemctl start containerd
# start로 했다가 변경 사항이 반영되지 않아서, 안되더라 꼭 restart 를 하라
sudo systemctl stop containerd
sudo systemctl restart containerd
sudo systemctl enable --now containerd
5) CNI 설정
왜 갑자기 CNI 설정을 더 하라고 적혀있는지 이해가 되지 않아서
최종적으로 돌리는 서비스를 직접 호출해 보았다.
(1) Kubelet standalone 서비스 설정
다른 곳에서 찾은 예제인데 서비스 등록 이전에 테스트를 해봤다.
내 환경과는 맞지 않고 옵션도 잘못되었다고 한다.
/usr/bin/kubelet --container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock --pod-manifest-path=/etc/kubernetes/manifests
이게 실행되고 서비스로 유지가 되어야 kubelet standalone 이 된다는 것인데…
kubelet option 문서에서는 default 라는데 구지 선언해야 되나….
뿐만 아니라 내 환경과는 맞지 않고 옵션도 잘못되었다고 한다.
--container-runtime-endpoint string Default: "unix:///run/containerd/containerd.sock"
뭘 해야 kubelet standalone이 되나 공식문서나 예제를 찾아봐야 겠다.
/etc/kubernetes/admin.conf 를 활용해서 초기설정을 한다고 한다.
이것도 Kubeadm init이 성공해야 생기나본데…. 아 일단 금방 확인되는 건 별로 없네….
Reference를 위해 EC2 다수 사용하여 실제 동작 tirgger를 찾아내도록 한다. 작업이 더디다….
sudo kubeadm init
[init] Using Kubernetes version: v1.29.2
[preflight] Running pre-flight checks
error execution phase preflight: [preflight] Some fatal errors occurred:
[ERROR CRI]: container runtime is not running: output: time="2024-02-26T00:18:17Z" level=fatal msg="validate service connection: validate CRI v1 runtime API for endpoint \"unix:///var/run/containerd/containerd.sock\": rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial unix /var/run/containerd/containerd.sock: connect: no such file or directory\""
, error: exit status 1
[ERROR FileContent--proc-sys-net-bridge-bridge-nf-call-iptables]: /proc/sys/net/bridge/bridge-nf-call-iptables does not exist
[ERROR FileContent--proc-sys-net-ipv4-ip_forward]: /proc/sys/net/ipv4/ip_forward contents are not set to 1
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
To see the stack trace of this error execute with --v=5 or higher
CRI 부터 깔고 Kubeadm init 이구나…
다시 containerd 깔라는 대로 다 깔고, 서비스 스타트 다 시키고 실행하면,
[init] Using Kubernetes version: v1.29.2
[preflight] Running pre-flight checks
error execution phase preflight: [preflight] Some fatal errors occurred:
[ERROR CRI]: container runtime is not running: output: time="2024-02-26T00:45:43Z" level=fatal msg="validate service connection: validate CRI v1 runtime API for endpoint \"unix:///var/run/containerd/containerd.sock\": rpc error: code = Unimplemented desc = unknown service runtime.v1.RuntimeService"
, error: exit status 1
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
To see the stack trace of this error execute with --v=5 or higher
연결 했는데, 이게 뭐냐는 것같다…. 명시화 해야되나보다.
아래의 음영 부분은 시도한 것이지만 의미는 없었다. kubeadm 초기화의 문제는 contanderd 의 설정에서 CRI 로 사용하겠다는 옵션이 중요했다.
CNI 설정을 더 찾아본다
– containerd cni 설정 – https://github.com/containerd/containerd/blob/main/script/setup/install-cni
wget https://github.com/containernetworking/plugins/releases/download/v1.4.0/cni-plugins-linux-arm64-v1.4.0.tgz
mkdir -p /opt/cni/bin
tar Cxzvf /opt/cni/bin cni-plugins-linux-arm64-v1.4.0.tgz
– calico 설치 및 cni 설정 – https://docs.tigera.io/calico/latest/getting-started/kubernetes/hardway/install-cni-plugin
curl -L -o /opt/cni/bin/calico https://github.com/projectcalico/cni-plugin/releases/download/v3.14.0/calico-arm64
chmod 755 /opt/cni/bin/calico
curl -L -o /opt/cni/bin/calico-ipam https://github.com/projectcalico/cni-plugin/releases/download/v3.14.0/calico-ipam-arm64
chmod 755 /opt/cni/bin/calico-ipam
6) CNI 설치 버그 해결
/etc/containerd/config.toml 에 있었던 옵션
disabled_plugins = [] 라는 부분을 바꾸어야 한다.
enabled_plugins = ["cri"]
됬다그래라. 이젠 걍 다시 돌아가서 containerd 와 kubelet으로만 구동하도록 가련다. 2G RAM 쓰면 공짜가 아니거든.
sudo systemctl daemon-reload
# sudo systemctl start containerd
# start로 했다가 변경 사항이 반영되지 않아서, 안되더라 꼭 restart 를 하라
sudo systemctl stop containerd
sudo systemctl restart containerd
sudo systemctl enable --now containerd
4. kubelet 서비스를 실행하여, test pod를 올리고 테스트한다.
1) 테스트 도구 설치
Name | Community | API | Target | Web site |
---|---|---|---|---|
ctr | containerd | Native | For debugging only | (None, see ctr --help to learn the usage) |
nerdctl | containerd (non-core) | Native | General-purpose | https://github.com/containerd/nerdctl |
crictl | Kubernetes SIG-node | CRI | For debugging only | https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md |
crictl 이 가장 쓸만하다고 한다. debugging 테스트 용도로 받아서 검사하자. 다운로드 해야하니까 걍 wget 한다.
VERSION="v1.29.0" # check latest version in /releases page
wget https://github.com/kubernetes-sigs/cri-tools/releases/download/$VERSION/crictl-$VERSION-linux-arm64.tar.gz
sudo tar zxvf crictl-$VERSION-linux-arm64.tar.gz -C /usr/local/bin
rm -f crictl-$VERSION-linux-amd64.tar.gz
ubuntu@ip-10-0-145-244:~$ crictl
NAME:
crictl - client for CRI
USAGE:
crictl [global options] command [command options] [arguments...]
VERSION:
v1.29.0
crictl 설정
cat << "EOF" | sudo tee /etc/crictl.yaml
runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
timeout: 10
debug: false
EOF
2) Test 용도의 Pod 를 실행
cat << EOF | sudo tee /etc/kubernetes/manifests/web.yaml
apiVersion: v1
kind: Pod
metadata:
name: static-web
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
hostPort: 8080
protocol: TCP
EOF
3) kubelet 실행
sudo /usr/bin/kubelet --container-runtime-endpoint=unix:///run/containerd/containerd.sock --pod-manifest-path=/etc/kubernetes/manifests
E0226 07:03:44.971905 6463 pod_workers.go:1298] "Error syncing pod, skipping" err="network is not ready: container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized" pod="default/static-web-ip-10-0-136-250" podUID="103f5f5baab872f8bf4f0d41fb78b05a"
4) CNI plugin 초기화 안됬다. 이제 드디어 CNI plugin 까지 온건가…..
CNI 설정에서 cni-plugins-linux-arm64-v1.4.0.tgz 를 통해서 설치하는 것은 이미 설치가 되어있더라.
플러그인도 잘 설치되어있고, kubernetes가 사용할 서비스 공간에 대한 network 환경 설정이 필요하다. VPC도 CIDR로 설정한 것처럼 같은 이치이다.
– containerd cni 설정 – https://github.com/containerd/containerd/blob/main/script/setup/install-cni
wget https://github.com/containernetworking/plugins/releases/download/v1.4.0/cni-plugins-linux-arm64-v1.4.0.tgz
mkdir -p /opt/cni/bin
tar Cxzvf /opt/cni/bin cni-plugins-linux-arm64-v1.4.0.tgz
설치되어있는 execution들을 봐라
ubuntu@ip-10-0-136-250:~$ /opt/cni/bin/b
bandwidth bridge
ubuntu@ip-10-0-136-250:~$ /opt/cni/bin/b
bandwidth bridge
ubuntu@ip-10-0-136-250:~$ /opt/cni/bin/bandwidth
CNI bandwidth plugin v1.3.0
CNI protocol versions supported: 0.3.0, 0.3.1, 0.4.0, 1.0.0
ubuntu@ip-10-0-136-250:~$
그럼 plugin은 안깔아도 될 것 같다.
10-containerd-net.conflist 만 깔아보자….
sudo cat << EOF | sudo tee /etc/cni/net.d/10-containerd-net.conflist
{
"cniVersion": "1.0.0",
"name": "containerd-net",
"plugins": [
{
"type": "bridge",
"bridge": "cni0",
"isGateway": true,
"ipMasq": true,
"promiscMode": true,
"ipam": {
"type": "host-local",
"ranges": [
[{
"subnet": "10.88.0.0/16"
}],
[{
"subnet": "2001:4860:4860::/64"
}]
],
"routes": [
{ "dst": "0.0.0.0/0" },
{ "dst": "::/0" }
]
}
},
{
"type": "portmap",
"capabilities": {"portMappings": true}
}
]
}
EOF
crictl ps 로 pod 상태 좀 보자
sudo systemctl daemon-reload
# sudo systemctl start containerd
# start로 했다가 변경 사항이 반영되지 않아서, 안되더라 꼭 restart 를 하라
sudo systemctl stop containerd
sudo systemctl restart containerd
sudo systemctl enable --now containerd
다른 탭에서 검사해본다.
sudo crictl pods
ubuntu@ip-10-0-136-250:~$ sudo crictl pods
POD ID CREATED STATE NAME NAMESPACE ATTEMPT RUNTIME
9e0988cda0127 About a minute ago Ready static-web-ip-10-0-136-250 default 0 (default)
PODID=$(sudo crictl pods | awk /static-web/{'print $1'})
PODIP=$(sudo crictl inspectp -o go-template --template '{{.status.network.ip}}' ${PODID})
curl $PODIP:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
드디어 된다…..
마지막 테스트 ㄱㄱ
ROUTABLE_NODE_IP=$(ip -o r g 1 | awk '{print $7}')
curl $ROUTABLE_NODE_IP:8080
이것도 잘됨. 다행.
4. kubelet 만으로 돌리기(kubelet standalone)
/etc/cni/net.d/10-containerd-net.conflist 에 CNI 설정을 마무리 해주면, CNI plugin 과 CNI containerd 를 설치한 내용을 기반으로 CNI 설정이 완성된다. 아래의 설정만으로도 말이다.
# /etc/containerd/config.toml
disabled_plugins = [] -> enabled_plugins = ["cri"]
SystemdCgroup = false
/etc/kubernetes/manifests/ 폴더에 서비스 할 pod를 설정하여 넣는 것만으로도 서비스를 유지할 수 있다.
이 부분에 wordpress와 persistance volume 을 설정하여 다수의 wordpress host를 완성하고 API gateway에 배정할 것이다.
5. Kubelet standalone 서비스 구축
결국 실패했다. 참고하라
실패한 내용 블로그: aws-ec2-kubernetes-wordpress-hosting
끝
전체 과정 블로그 /aws-ec2-mariadb-환경-설정