'cgroup'에 해당하는 글 3건



Linux 상에서의 Minikube 도 설치 방법이 여러가지이다. 우선 하이퍼바이저 상에서 Minikube 를 구동할 것인지, 호스트에서 직접 구동할 것인지를 선택해야 한다. 하이퍼바이저를 이용한다면 리소스를 더 알뜰히 사용할 수 있겠지만, 모든 리눅스에서 하이퍼바이저를 사용할 수는 없다. Widnows 편에서 말했듯이 CPU 의 가상화(VT-x/AMD-v) 지원과 Bios 에서 가상화 활성화 상태를 확인해야 하는데, 요즘 많이들 사용하는 클라우드 컴퓨팅 서비스(EC2, GCE) 등에서는 대부분 HVM 가상화를 사용하고 있고, 그 자체가 이미 VM 이므로 그들은 Bios 에 접근을 할 수 없다. 결국 클라우드 컴퓨팅에서는 하이퍼바이저를 사용할 수 없으므로 과감히 VM 사용을 포기한다.ㅠ 현재 상황이 Linux 에서 VM 을 돌리기 위해 멀쩡한 PC 들에 Linux 를 까기는 좀;; 아무튼 현재 상황에서는 Linux 에서 VM 없이 호스트에서 Minikube 를 직접 구동시켜는 방법을 사용해야 하며, VM 없이 Minikube 를 시작하는 명령은...


 # minikube start --vm-driver=none 


하지만 EC2 Linux 에서도 minikube 를 정상적으로 구동하기 위해 체크해야 할 것들이 있다.



Minikube 구동시 체크사항


  1. 2cpu, 2GB 메모리, 20GB 디스크 이상의 사양.
    EC2 에서 free-tier 인 t2.micro 는 1cpu, 1G 메모리로, minikube 를 구동할 수 없다. 최소 t2.medium 사양(2cpu, 4GB mem)이 필요하다.

  2. docker 설치(Container Runtime)와 cgroup driver 매칭
    docker 가 반드시 필요하며(docker.io 나 docker-ce), 설치 후 docker info | grep -i cgroup 명령으로 cgroup driver 가 cgroupfs 인지 systemd 인지 확인해야 한다. minikube 구동 후에 kubelet 의 cgroup driver 와 일치하지 않는 다면 관련을 참고하여 일치시킨다. VM 에서 구동시에는 docker 가 자동 설치되며 자동 매칭을 해준 부분이다.

  3. 구동 실패시 클러스터 삭제
    minikube start 로 클러스터가 생성되다가 에러가 발생하면 캐싱으로 인해 에러가 반복될 수 있다. 다시 구동하기 전에는 minikube delete 명령으로 생성된 클러스터를 제거해 준다.



EC2 에서 발생할 수 있는 에러 메시지


- virtualbox 미설치 메시지

# minikube start

o   minikube v0.35.0 on linux (amd64)

>   Creating virtualbox VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...

@   Downloading Minikube ISO ...

 184.42 MB / 184.42 MB [============================================] 100.00% 0s

!   Unable to start VM: create: precreate: VBoxManage not found. Make sure VirtualBox is installed and VBoxManage is in the path


- 가상화 비활성화 메시지

# minikube start

o   minikube v0.35.0 on linux (amd64)

>   Creating virtualbox VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...

!   Unable to start VM: create: precreate: This computer doesn't have VT-X/AMD-v enabled. Enabling it in the BIOS is mandatory


- docker 미설치 메시지

# minikube start --vm-driver=none

i   This can also be done automatically by setting the env var CHANGE_MINIKUBE_NONE_USER=true

>   Creating none VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...

!   Unable to start VM: create: precreate: exec: "docker": executable file not found in $PATH


- cgroup driver 불일치 메시지

# minikube start --vm-driver=none

This error is likely caused by:

- The kubelet is not running

- The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)



EC2 (ubuntu) 에서 minikube 구동 성공


# minikube start --vm-driver=none

o   minikube v0.35.0 on linux (amd64)

>   Configuring local host environment ...


!   The 'none' driver provides limited isolation and may reduce system security and reliability.

!   For more information, see:

-   https://github.com/kubernetes/minikube/blob/master/docs/vmdriver-none.md


!   kubectl and minikube configuration will be stored in /root

!   To use kubectl or minikube commands as your own user, you may

!   need to relocate them. For example, to overwrite your own settings:


    - sudo mv /root/.kube /root/.minikube $HOME

    - sudo chown -R $USER $HOME/.kube $HOME/.minikube


i   This can also be done automatically by setting the env var CHANGE_MINIKUBE_NONE_USER=true

>   Creating none VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...

-   "minikube" IP address is 10.0.1.121

-   Configuring Docker as the container runtime ...

-   Preparing Kubernetes environment ...

-   Pulling images required by Kubernetes v1.13.4 ...

-   Launching Kubernetes v1.13.4 using kubeadm ...

:   Waiting for pods: apiserver proxy etcd scheduler controller addon-manager dns

-   Configuring cluster permissions ...

-   Verifying component health .....

+   kubectl is now configured to use "minikube"

=   Done! Thank you for using minikube!

root@ip-10-0-1-121:~# minikube status

host: Running

kubelet: Running

apiserver: Running

kubectl: Correctly Configured: pointing to minikube-vm at 10.0.1.121




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

...

[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s

[kubelet-check] Initial timeout of 40s passed.


Unfortunately, an error has occurred:

        timed out waiting for the condition


This error is likely caused by:

        - The kubelet is not running

        - The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)


If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:

        - 'systemctl status kubelet'

        - 'journalctl -xeu kubelet'


Additionally, a control plane component may have crashed or exited when started by the container runtime.

To troubleshoot, list all containers using your preferred container runtimes CLI, e.g. docker.

Here is one example how you may list all Kubernetes containers running in docker:

        - 'docker ps -a | grep kube | grep -v pause'

        Once you have found the failing container, you can inspect its logs with:

        - 'docker logs CONTAINERID'

error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster


 kubeadm init  로 초기화 시에 발생한 오류이다. 에러 메시지와 달리 kubelet 은 running 상태여서 원인을 파악하기가 힘들었다. 포트 inbound, swap 등 괜한 것만 건드리다가 cgroup 에서 원인을 찾았다.


결론은 컨테이너 런타임(docker) 및 kubelet 의 cgroup-driver 가 일치하지 않아서 발생한 오류였다. 정확한 에러 메시지도 아니고, 이게 warning 이 아니라 설치가 중단될 정도의 문제라는 것이 이상했지만 어쨌든 cgroup-driver 를 systemd 로 통일하여 해결했으니... docker 의 기본 cgroup-driver 는 cgroupfs 이고, kubelet 의 기본 cgroup-driver 는 systemd 라서 두 개의 다른 cgroup 관리자가 존재하게 되어, 리소스 부족으로 시스템이 불안정해 진다고 한다.



Docker cgroup driver 변경


docker 를 아래와 같이 설치하고 kubeadm init 를 다시 실행해 본다.


# apt-get update


// Install https

# apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common


// Add Docker’s official GPG key

# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -


// Add docker apt repository

# add-apt-repository \

"deb [arch=amd64] https://download.docker.com/linux/ubuntu \

$(lsb_release -cs) \

stable"


// Install docker ce.

# apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu


// Setup daemon.

# cat > /etc/docker/daemon.json <<EOF

{

  "exec-opts": ["native.cgroupdriver=systemd"],

  "log-driver": "json-file",

  "log-opts": {

    "max-size": "100m"

  },

  "storage-driver": "overlay2"

}

EOF


# mkdir -p /etc/systemd/system/docker.service.d

# systemctl daemon-reload

# systemctl restart docker



Kubelet cgroup driver 변경


다른 방법으로 kubelet 의 cgroup driver 를 변경하는 방법도 있다.


# vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

...

[Service]

ExecStart=

ExecStart=/usr/bin/kubelet --fail-swap-on=false --authorization-mode=Webhook --client-ca-file=/var/lib/minikube/certs/ca.crt --kubeconfig=/etc/kubernetes/kubelet.conf --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --hostname-override=minikube --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true --cluster-dns=10.96.0.10 --cluster-domain=cluster.local --cgroup-driver=cgroupfs --container-runtime=docker

...




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

docker 설치 후 docker info 를 확인하자 마자 보이는 경고.


WARNING: No swap limit support


에러를 안나타나게 하려면, 시스템에서 cgroup 에 메모리와 스왑 메모리 관리를 사용할 수 있게 하면 된다.

메모리와 스왑 메모리를 사용 가능하게 하면 Docker 를 사용하지 않을 때도 메모리 오버헤드(약 1%), 성능 저하(약 10%)를 유발한다.

GNU GRUB(GRand Unified Bootloader)을 수정하여 cgroup 에 메모리와 스왑메모리를 가능하게 할 수 있다.


# vi /etc/default/grub

GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"


변경된 GRUB 을 적용하고 재부팅한다.


# update-grub

Generating grub configuration file ...

Found linux image: /boot/vmlinuz-3.13.0-74-generic

Found initrd image: /boot/initrd.img-3.13.0-74-generic

done


# shutdown -r now



여기까지가 문서에 있는 얘기고...

현재 커널이 cgroup swap 메모리 제한을 하고 있지 않다는 것인데.

이것을 가능하게 세팅하고 나면 성능 저하가 생긴다는게 말인가 방구인가.

Docker 를 위해서 시스템의 성능을 저하시킨하는게 말인가 방구인가.

Docker 돌리는데는 이러나 저러나 지장은 없지만 이게 무슨 말인지 정말 궁금하긴 하다.

이것때매 cgroup 까지 찾아보기는 좀...ㅜ



WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret