Kubernetes(18)
-
[k8s] Pod 리소스 할당 (requests, limits)
컨테이너 리소스 할당 개론 - 쿠버네티스가 관리하는 리소스는 CPU와 Memory이다. - 기본적으로 컨테이너 단위로 리소스를 제한한다. 리소스를 제한하지 않을 경우 발생할 수 있는 문제 1) starvation 리소스를 제한하지 않으면 해당 노드에 할당된 컨테이너는 노드의 리소스를 전부 다 사용할 수 있다. 따라서 만약 리소스 제한을 두지 않고 특정 호스트에 Pod를 두 개 이상 띄웠을 경우, 하나의 Pod가 노드의 모든 리소스를 사용한다면 새로운 Pod가 스케줄링될 수 없다. 2) 보안 관련 이슈 만약 특정 Pod에 보안 관련 버그가 발생해서 해커가 해당 Pod에 디도스 공격을 주어 노드의 모든 리소스를 사용하게 된다면, 다른 Pod들은 스케줄링될 수 없다. ** 따라서 Pod 하나를 띄우더라도 해당..
2022.09.10 -
[k8s] livenessProbe기반의 Self-healing Pod (feat. 자동화)
쿠버네티스가 제공해주는 기능 10가지 쿠버네티스 공식 사이트에 들어가면 쿠버네티스가 제공해주는 10가지 기능에 대해 설명되어 있다. 이중에서도 자가 치유(Self-healing)에 대한 부분을 이번 포스팅에서 다루도록 한다. 자가 치유(Self-healing) 오류가 발생한 컨테이너를 재시작하고, 노드가 죽었을 때 컨테이너를 교체하기 위해 다시 스케줄 하고, 사용자 정의 상태 체크에 응답하지 않는 컨테이너를 제거하며, 서비스를 제공할 준비가 될 때까지 클라이언트에 해당 컨테이너를 알리지 않는다. 즉, 정상적인 컨테이너들만을 대상으로 애플리케이션을 운영해 주겠다는 의미이다. Self-handling 기능중에 포함된 것이 'livenessProbe'이다. livenessProbe는 컨테이너를 진단해서 정상적..
2022.09.05 -
[k8s] 쿠버네티스에서 컨테이너 동작 flow
쿠버네티스에서 컨테이너 동작 flow 새로운 컨테이너를 실행시키는 flow 1) kube-apiserver는 REST API Server로서 kubectl 커맨드나 yaml로 작성된 파일의 요청을 받고 처리한다. api-server는 우선 etcd에서 worker노드들의 상태 정보를 수집한 뒤 scheduler로 보낸다. 2) scheduler는 api-server로부터 요청을 받고 worker 노드의 상태를 확인한 뒤 어느 노드에 배치시키는 것이 가장 좋을지 결정 후 api-server로 응답한다. 3) api-server가 응답을 받고 해당하는 노드로 컨테이너 배치를 요청한다. 이때 해당 worker노드의 kubelet으로 요청을 보낸다. 4) worker노드의 kubelet이 컨테이너 런타임으로 요..
2022.09.04 -
[k8s] containerd, runC, CNI플러그인 설치하기(without Docker, cgroup 활성화)
cf. 설치할 버전 containerd 1.5.5 runC 1.1.1 * contianerd 및 runC는 컨테이너 동장을 위해 필요하기 때문에 쿠버네티스 클러스터 시작(kubeadm init) 전에 반드시 필요함. * CNI 플러그인은 Pod CIDR 및 서브넷을 구성하기 때문에 kubeadm init 전 또는 후에 필요함. * CNI 플러그인이 설치되지 않은 경우 CoreDNS가 제대로 동작할 수 없음. 1. containerd 1.5.5 설치 쿠버네티스 버전 1.22를 사용할 것이기 때문에 containerd는 1.5.5를 사용한다. 링크: https://www.itzgeek.com/how-tos/linux/ubuntu-how-tos/install-containerd-on-ubuntu-22-04.h..
2022.08.31 -
[container] 컨테이너 런타임 표준화(OCI 표준)
containerd 등장 배경 - OCI 표준 초기 docker engine은 Monolithic한 구조였고 이를 나누는 작업이 시작되었다. 이러한 Monolithic한 구조의 docker engine에는 API, CLI, 네트워크, 스토리지 등 여러 기능들이 한 곳에 담기게 되었고 Docker에 의존적이던 kubernetes에서는 docker 버전이 새로 나올 때마다 영향을 받을 수밖에 없었다. 이를 계기로 2015년에 Linux Foundation에서는 '컨테이너 기술에 대한 표준'을 정하는 프로젝트(OCI)가 시작되었다. 이 프로젝트는 2016년 12월에 Container Runtime에 대한 표준을 만들고 이를 실행할 수 있는 추상화된 인터페이스인 CRI(Container Runtime Inter..
2022.08.26 -
[kubernetes] kubectl Connection Refused 이슈 해결
1. 문제 설명 kubectl 커맨드가 정상적으로 실행되다가 어느 순간 다시 아래와 같이 connection이 refused 되는 문제가 발생했다. 약 3~5분 간격으로 API 서버가 죽고, controller-namager나 scheduler도 죽었다 살아나기를 반복한다. root@master:~# kubectl get nodes the connection to the server :6443 was refused - did you specify the right host or port 모든 kubectl 커맨드는 API 서버로 가기 때문에 API 서버에 문제가 있을 거라 생각했다. kubectl 커맨드가 정상적으로 실행되지 않았기 때문에 API 서버를 포함한 쿠버네티스 컴포넌트들이 잘 실행 중인지 확인..
2022.08.26 -
[Kubernetes] VM, 컨테이너, 멀티호스트, 오케스트레이션 발전과정
VM, 컨테이너, 멀티호스트 컨테이너 플랫폼, 컨테이너 오케스트레이션까지의 발전과정에 대한 포스팅이다. '가상화' 개념의 등장 가상화 개념이 처음 등장했던 1960년대에, 무어의 법칙에 의해 HW의 성능이 빠르게 발전하는데 SW는 이만큼 발전을 하지 못했던 상황이 발생했다. 즉, HW는 빠르게 발전하는데 SW가 이를 제대로 활용하지 못하는 상황이 발생한 것이다. 또한 그 당시 컴퓨터 HW 자원의 가격은 매우 비싼 편이었다. 여러 대의 비싼 컴퓨터를 사용해서 애플리케이션을 띄우는 것은 매우 비효율적이라는 문제가 있었던 것이다. 이러한 문제점을 해결하고자 등장한 것이 '가상화'이다. 한 대의 컴퓨터의 자원을 가상화해 여러 대인 것처럼 보이게 하자는 것이다. 하나의 물리적인 컴퓨터 위에 여러 대의 OS가 구동..
2022.04.10 -
[용어] MSA, DevOps, SRE 기초개념 + 연관관계
Microservice - 기존 모놀리틱 구조에서 모든 도메인과 기능이 하나의 시스템에 담겨있고 서비스가 방대해짐에 따라 복잡성이 커졌다. - Microservice는 기존 모놀리틱 구조에서 방대한 시스템을 적절하게 나눈 구조로 설명된다. - 'API Gateway'를 두고 기능별/도메인별로 요청이 '분기'하도록 구성된다. 특징 [장점] - 기존 모놀리틱 구조에서는 장애 발생 시 서비스 전체가 마비될 것이다. Microservice는 분리한 서비스 단위로 배포가 가능하기 때문에 자유롭게, 가볍게 배포가 가능하며 확장도 용이하다.(서비스 간 의존도가 떨어지기 때문) - 애플리케이션 재기동 시간이 크게 단축된다. (보통 모놀리틱은 한번 빌드하는데 엄청난 시간이 소요) - 다른 서비스와는 API로 연동되기 때..
2021.10.29