효팍이의 프로그래밍

포드를 사용하는 상위 오브젝트에는 디플로이먼트 외에도 몇 가지가 더 있는데 상황에 따라서 필요할 수 있는 몇 가지 상위 오브젝트를 공부해봅시다. 잡(Job) 잡은 특정 동작을 수행하고 종료해야 하는 작업을 위한 오브젝트입니다. 포드를 생성해 원하는 동작을 수행한다는 점에서는 디플로이먼트와 같지만, 잡에서 원하는 최종 상태는 '특정 개수의 포드가 실행 중인 것'이 아닌 '포드가 실행되어 정상적으로 종료되는 것'이라는 점에서 차이가 있습니다. 따라서 잡에서는 포드의 컨테이너가 종료 코드로서 0을 반환해 Completed 상태가 되는 것을 목표로 합니다. apiVersion: batch/v1 kind: Job metadata: name: job-hello-world spec: template: spec: re..

이전글입니다. -> 애플리케이션 배포를 위한 고급 설정 기본적인 리소스 외에도 직접 리소스의 종류를 정의해 사용할 수도 있는데, 이를 커스텀 리소스라고 부른다. 커스텀 리소스를 제대로 사용하려면 컨트롤러라고 하는 별도의 컴포넌트를 이해하고 구현할 수 있어야 한다. 쿠버네티스 컨트롤러의 개념과 동작 방식 명령형(Imperative) vs. 선언적(Declarative) 특정 명령을 처리하는 주체와 통신해 그 작업을 수행하고 그 결괏값을 돌려받는 방식을 명령형이라고 말합니다(kubectl run ~). 쿠버네티스는 이와 반대되는 선언형 방식을 지향합니다. 선언형 방식은 최종적으로 도달해야 하는 바람직한 상태를 정의한 뒤, 현재 상태가 바람직한 상태와 다를 경우 이를 일치하도록 만드는 방법입니다. 명령형 방식..

여러 명의 개발자가 쿠버네티스에 접근할 수 있고, 각 개발자가 kubectl 같은 명령어를 통해 애플리케이션을 동시에 배포할 수 있어서 보안이 매우 중요합니다. 자주 사용되는 것은 RBAC(Role Based Access Control)를 기반으로 하는 서비스 어카운트 기능입니다. 서비스 어카운트는 사용자 또는 애플리케이션 하나에 해당하며, RBAC라는 기능을 통해 특정 명령을 실행할 수 있는 권한을 서비스 어카운트에 부여합니다. 권한을 부여받은 서비스 어카운트는 해당 권한에 해당하는 기능만 사용할 수 있습니다. 지금까지 kubectl 명령어를 사용해왔던 권한은 사실 최상위에 해당하는, 마치 리눅스의 root 사용자와 같은 권한을 가지고 있습니다. 쿠버네티스의 API에 접근하는 애플리케이션을 운영 환경에..

실습 환경 [k8s]kubeadm, kubelet, kubectl을 설치하여 쿠버네티스(kubernetes) 클러스터 구축하기 모니터링 기본 구조 CAdvisor는 컨테이너에 관련된 모니터링 데이터를 확인할 수 있는 모니터링 도구입니다. 하지만 CAdvisor가 제공하는 웹 UI에서는 단기간의 메트릭만 제공할 뿐, 체계적으로 데이터를 저장하고 분석하지는 않습니다. CAdvisor 같은 모니터링 에이전트 부류의 도구들은 /metrics라고 하는 경로를 외부에 노출시켜 제공합니다. 이 /metrics 경로로 요청을 보내면 CAdvisor는 키-값 쌍으로 구성된 메트릭 데이터의 목록을 반환하는데, 이 메트릭 데이터를 프로메테우스 같은 시계열 데이터베이스에 저장할 수 있습니다. 프로메테우스는 CAdvisor의 ..

kubeadm 설치 방법을 정리해둡니다.. 개발 환경 OS : WIndows 11 pro 가상화 프로그램 : VMware Workstation 16 Player 가상화 OS : Ubuntu Server 20.04.3 LTS 쿠버네티스 클러스터 master 1대, worker 3대 4대 전부 CPU 2core, RAM 4GB, VOLUME 64GB Network Adapter : Bridged(Connected directly to the physical network) 리눅스 설치시에 고정 IP 설정 잘 안될 때는 맨 밑의 참고한 사이트를 확인해주세요!! kubeadm, kubelet, kubectl로 Kubernetes 클러스터 구축 - Master Node 사전 환경 구성 # apt update, u..

들어가기전에 앞서 블로깅에서 사용해왔던 디프롤이먼트는 모두 상태가 없는(stateless) 애플리케이션이었습니다. 즉, 디플로이먼트의 각 포드는 별도의 데이터를 가지고 있지 않았으며, 단순히 요청에 대한 응답만을 반환했습니다. 하지만 데이터베이스처럼 포드 내부에서 특정 데이터를 보유해야 하는, 상태가 있는(stateful) 애플리케이션의 경우에는 데이터를 어떻게 관리할지 고민해야 합니다. 도커의 볼륨처럼 쿠버네티스도 자체에서 호스트에 위치한 디렉터리를 각 포드와 공유함으로써 데이터를 보존하는 것이 가능합니다. 그렇지만 여러 개의 서버로 구성된 쿠버네티스와 같은 클러스터 환경에서는 이 방법이 적합하지 않을 수 있습니다. 쿠버네티스는 워커 노드 중 하나를 선택해 포드를 할당하는데, 특정 노드에서만 데이터를 ..

kops 명령어 설치 $ wget -O kops https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64 $ chmod +x ./kops $ sudo mv ./kops /usr/local/bin/ $ kops version kubectl 명령어 설치 $ curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" ..

쿠버네티스 고급 기능 활용 네트워크 7계층에서 가상 호스트를 이용해 서비스 요청을 처리 애플리케이션의 영속적인 데이터를 보관하기 위한 외부 볼륨이 필요 여러 명의 개발자 또는 애플리케이션이 함께 사용하는 쿠버네티스 클러스터에서는 보안을 위해 권한을 관리 특정 포드가 컴퓨팅 자원을 독차지하는 것을 막기 위해 메모리, CPU 사용량의 제한을 위한 체계적인 시스템이 필요 들어가기전에 인그레스는 일반적으로 외부에서 내부로 향하는 것을 지칭하는 단어입니다. 예를 들어 인그레스 트래픽은 외부에서 서버로 유입되는 트래픽을 의미하며, 인그레스 네트워크는 인그레스 트래픽을 처리하기 위한 네트워크를 의미합니다. 인그레스는 외부 요청을 어떻게 처리할 것인지 네트워크 7계층 레벨에서 정의하는 쿠버네티스 오브젝트입니다. 인그레..

이번 블로깅에서는 효율적으로 애플리케이션을 관리하기 위해 자주 사용되는 네임스페이스(Namespace), 컨피그맵(ConfigMap), 시크릿(Secret)의 사용 방법을 알아봅시다. 네임스페이스(Namespace): 리소스를 논리적으로 구분하는 장벽 쿠버네티스에서는 리소스를 논리적으로 구분하기 위해 네임스페이스(Namespace)라는 오프젝트를 제공합니다. 간단히 생각해 네임스페이스는 포드, 레플리카셋, 디플로이먼트, 서비스 등과 같은 쿠버네티스 리소스들이 묶여 있는 하나의 가상 공간 또는 그룹이라고 이해할 수 있습니다. 여러 개의 네임스페이스를 사용하면 마치 하나의 클러스터에서 여러 개의 가상 클러스터를 동시에 사용하는 것처럼 느껴질 것 입니다. 네임스페이스 기본 개념 이해 네임스페이스는 namesp..

서비스(Service): 포드에 연결하고 외부에 노출 디플로이먼트를 통해 생성된 포드에 어떻게 접근할 수 있을까요? 이전 까지는 kubectl describe 명령어로 포드의 내부 IP를 직접 확인한 뒤 포드로 직접 접근할 수는 있었지만, 이 방법은 로컬 개발 환경 또는 쿠버 클러스터 내부에서만 사용할 수 있었습니다. 게다가 도커 컨테이너와 마찬가지로 포드의 IP는 영속적이지 않아 항상 변할 수 있다는 점도 유의해야 합니다. 여러 개의 디플로이먼트를 하나의 완벽한 애플리케이션으로 연동하려면 포드 IP가 아닌, 서로를 발견할 수 있는 다른 방법이 필요합니다. 도커 사용 방법을 되살펴 보면 도커 컨테이너는 -p 옵션으로 손쉽게 컨테이너를 외부로 노출할 수 있었습니다. 즉, 컨테이너가 생성됨과 동시에 외부로 ..

디플로이먼트(Deployment): 레플리카셋, 포드의 배포를 관리 디플로이먼트 사용하기 실제 쿠버네티스 운영 환경에서 레플리카셋을 YAML 파일에서 사용하는 경우는 거의 없고, 대부분 레플리카셋과 포드의 정보를 정의하는 디플로이먼트(Deployment)라는 이름의 오브젝트를 YAML 파일에 정의해 사용한다. 디플로이먼트는 레플리카셋의 상위 오브젝트이기 때문에 디플로이먼트를 생성하면 해당 디플로이먼트에 대응하는 레플리카셋도 함께 생성된다. # vi deployment-nginx.yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-nginx-deployment spec: replicas: 3 selector: matchLabels: app: my-n..

레플리카셋(Replica Set): 일정 개수의 포드를 유지하는 컨트롤러 레플리카셋을 사용하는 이유 쿠버네티스의 기본 단위인 포드는 여러 개의 컨테이너를 추상화해 하나의 애플리케이션으로 동작하도록 만드는 컨테이너 묶음이다. 실제로 외부 사용자의 요청을 처리해야 하는 마이크로 서비스 구조의 포드라면 스웜 모드처럼 여러 개의 동일한 컨테이너를 생성한 뒤 외부 요청이 각 컨테이너에 적절히 분배될 수 있어야 한다. 쿠버네티스에서는 기본 단위가 포드이기 때문에 동일한 여러 개의 포드를 생성해 외부 요청을 각 포드에 분배하는 방식을 사용해야 한다. apiVersion: v1 kind: Pod metadata: name: my-nginx-pod-a spec: containers: - name: my-nginx-con..

쿠버네티스를 시작하기 전에 도커 스웜 모드와 비교해서 쿠버네티스만이 가지는 고유한 특징들을 살펴보자. 모든 리소스는 오브젝트 형태로 관리된다. 도커 스웜 모드에서 컨테이너의 묶음을 표현하기 위해 서비스라는 것을 사용했는데 이것도 컨테이너 리소스의 집합을 정의한 것이기 때문에 일종의 오브젝트라고 볼 수 있다. 그러나 쿠버네티스는 이러한 개념을 더욱 폭넓고 세밀한 단위로 사용한다. 예를 들어 쿠버네티스에서는 컨테이너의 집합(Pods), 컨테이너의 집합을 관리하는 컨트롤러(Replica Set), 심지어 사용자(Service Account), 노드(Node)까지도 하나의 오브젝트로 사용할 수 있다. 쿠버네티스에서 사용할 수 있는 오브젝트는 kubectl api-resources 명령어를 사용해 확인할 수 있다..

가장 기초가 되는 도커 컨테이너를 다루기 위해 도커 엔진을 공부했고, 여러 대의 도커 엔진을 효율적으로 관리하기 위해 도커 스윔의 개념과 사용 방법을 다뤘다. 그리고 여러 종류의 컨테이너를 YAML 파일로 선언적으로 정의해 생성할 수 있는 도커 컴포즈의 사용 방법 또한 알아봤다. 이러한 프로젝트들의 개념을 한군데로 모아 사용할 수 있는 더욱 훌륭한 프로젝트가 바로 쿠버네티스다. 그리스어로 조타수라는 뜻의 쿠버네티스는 오늘날 사실상 표준으로 사용되고 있는 컨테이너 오케스트레이션 도구이다. 쿠버네티스는 도커 스웜 모드처럼 여러 대의 도커 호스트를 하나의 클러스터로 만들어 준다는 점은 같지만, 세부적인 기능을 더욱 폭넓게 제공하고 있다. 쿠버네티스의 장점 서버 자원 클러스터링, 마이크로서비스 구조의 컨테이너 ..