필터:#LoadBalancer×

[Kubernetes] Pod, 리소스, Ingress 정리

Pod란? 한 개 이상의 컨테이너로 구성된 쿠버네티스의 기본 단위 같은 Pod면 IP가 같다 같은 Pod 내 컨테이너들은 포트로 구분한다 Pod도 결국 컨테이너로 구성되어 있으며, 이 컨테이너를 실행하기 위해 docker, containerd, CRIO 같은 CRI(컨테이너 런타임)가 필요하다. 1\. kubeapiserver 내/외부의 모든 요청을 주고받는 서버. contoller나 scheduler,proxy의 주시대상. 호텔지배인. 2\. kubescheduler 생성될 리소스들을 어떤 노드에 '배치'할지 결정(스케쥴링) 호텔 로비 직원 3\. kubecontroller 다양한 리소스에 대한 여러가지 컨트롤러들이 존재한다. 원하는 상태(Desired state)에 현재 상태(current state)가 수렴하도록 지속적으로 모니터링. 문제가 생기면 고치거나 리소스를 재생성. ex) 하우스키퍼 4\. etcd 클러스터 및 모든 리소스에 대한 정보를 key:value 형태로 저장하는 일종의 데이터베이스. ex) 장부 모든 노드에 존재하는 컴포넌트 1\. kubelet 노드 관리자. 실질적으로 각 노드에 존재하는 리소스 관리 2\. kubeproxy 노드 안과 밖을 넘나드는 수직트래픽을 관리. 매니페스트 (yml 파일) 매니페스트란 내가 원하는 상태를 적어둔 명세서다. bash vi testpod.yml yml apiVersion: v1 kind: Pod metadata: name: test spec: containers: image: public.ecr.aws/docker/library/httpd:latest name: testcon bash kubectl apply f testpod.yml kubectl apply f는 docker compose up, docker stack deploy와 비슷하다. 내가 원하는 상태(Desired State)가 미리 정의된 매니페스트 파일을 구성해놓고 apply해서 반영한다. 매니페스트 수정 후 다시 apply하면 바로 변경사항을 반영시킬 수 있다. bash kubectl delete f testpod.yml 앞으로는 명령어로 직접 리소스를 생성하거나 지우지 말고 매니페스트 파일을 f 옵션을 통해 apply하거나 delete하도록 하자. label 중요 bash vi labels.yml yml apiVersion: v1 kind: Pod metadata: name: testlabelpod labels: app: myweb spec: containers: image: public.ecr.aws/docker/library/httpd:alpine name: testlabelcon label은 여러 개를 쓸 수 있다. bash kubectl apply f labels.yml 생성. bash kubectl describe pod testlabelpod 조회. label은 리소스를 컨트롤(원하는 상태, 현재 상태)하고 찾아가기 위한 용도다. 쿠버네티스의 다양한 리소스들 1\. pod 한 개 이상의 컨테이너로 구성된 쿠버네티스의 기본 배포 단위. 2\. replicaset Pod의 복제본 수를 유지해주는 리소스. 지정한 수만큼 Pod가 항상 실행되도록 보장한다. 3\. Deployment ReplicaSet을 관리하며 롤링 업데이트, 롤백 등을 지원하는 리소스. 실무에서 가장 많이 사용한다. 4\. namespace 클러스터 내에서 리소스를 논리적으로 분리하는 단위. 팀이나 프로젝트별로 격리된 환경을 만들 수 있다. 5\. Service (너무 중요!) 작은 로드밸런서라고도 할 수 있다. Pod에 접근하기 위한 고정된 엔드포인트를 제공하는 리소스이다. Pod는 재생성될 때마다 IP가 바뀌기 때문에 Service를 통해 안정적으로 접근한다. 서비스라는 리소스를 생성 시 하나의 접속지점이 생성된다. 이 서비스를 통해 모든 노드에 존재하는 pod에 트래픽을 인가할 수 있다. 인가하는 기준은 labels 를 통해 해당 pod를 특정하면 된다. 서비스는 다양한 종류(type)이 존재한다. 51. ClusterIP 타입 (svc의 default 타입) 클러스터 내부에서만 유효한 IP 내부 테스트 용도, 외부로 배포를 안하는 경우. 내부에 존재하는 서비스들끼리만 통신할 때. bash vi dep.yml yml apiVersion: apps/v1 kind: Deployment metadata: name: mydep spec: replicas: 3 selector: matchLabels: app: myweb template: metadata: labels: app: myweb spec: containers: image: public.ecr.aws/docker/library/httpd:alpine name: mywebcon bash kubectl apply f dep.yml svc를 연결할 deployment 생성. bash vi depsvc.yml 서비스 매니페스트 정의. yml apiVersion: v1 kind: Service metadata: name: svcmyweb spec: selector: app: myweb ports: port: 80 targetPort: 80 bash kubectl apply f depsvc.yml svc 생성. bash kubectl describe svc svcmyweb 자세한 정보 확인. Endpoint에 뜨는 pod들은 건강한 pod만 뜬다. 52. NodePort 타입 노드의 포트 서비스를 제공받는 사용자 입장에서 내부로 진입하여 pod에 접근하려면 노드 포트로 진입해야 한다. bash mkdir svc cd svc vi svcnodeport.yml yml apiVersion: v1 kind: Service metadata: name: svcdep spec: selector: app: mydep type: NodePort ports: nodePort: 30001 port: 80 targetPort: 80 apiVersion: apps/v1 kind: Deployment metadata: name: mydep spec: replicas: 1 selector: matchLabels: app: mydep template: metadata: labels: app: mydep spec: containers: image: public.ecr.aws/docker/library/httpd:alpine name: depcon bash kubectl apply f svcnodeport.yml bash kubectl describe svc svcdep 3개의 포트(NodePort, Port, TargetPort)가 각각 어떤 대상인지 구분할 수 있어야 한다. Port 서비스 포트 TargetPort pod NodePort Node 외부에서 노드로 통신만 된다면 노드 포트를 통해 pod로 접속 가능하다. 어떤 노드로 들어가는지는 중요하지 않고, NodePort로 접근하면 동일한 공간(오버레이 네트워크가 구성된 podnetwork)으로 들어간다는 사실을 인지하자. pod가 어떤 노드에 존재하는지는 신경 쓸 필요도 없고 중요하지도 않다. pod가 worker1에 띄워져 있어도 worker2의 노드 포트를 통해 접근 가능하다. 53. LoadBalancer 타입 클러스터 관리자의 도움이 필요한 서비스 타입. 쿠버네티스 외부 네트워크 대역의 IP를 자동으로 할당하고 관리해 주는 사설 로드밸런서 관리자가 MetalLB다. EKS 같은 쿠버네티스 클러스터의 경우 클라우드 서비스 제공자(AWS)가 LB를 제공해줄 수 있지만, 온프레미스에 구성한 클러스터는 그렇지 않다. 따라서 svc를 LoadBalancer 타입으로 만들었을 때 누군가는 LB를 생성하면서 노드 대역대의 IP를 할당해줘야 한다. 그 기능을 활성화하기 위해 MetalLB가 필요하다. bash vi configmetal.yml LB가 생성됐을 때 뿌려줄 IP 범위 설정. yml apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: firstpool namespace: metallbsystem spec: addresses: 211.183.3.200211.183.3.240 안겹치게 수정. LB가 부여받을 IP 범위 apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: example namespace: metallbsystem bash kubectl apply f configmetal.yml vi lbtom.yml yml apiVersion: v1 kind: Service metadata: name: svctom spec: selector: app: tom type: LoadBalancer ports: port: 80 targetPort: 8080 apiVersion: apps/v1 kind: Deployment metadata: name: deptom spec: replicas: 1 selector: matchLabels: app: tom template: metadata: labels: app: tom spec: containers: image: public.ecr.aws/docker/library/tomcat:10.1.40jre11 name: tomcon svc의 타입으로 LoadBalancer 타입을 지정해준다. nodePort는 삭제한다. bash kubectl apply f lbtom.yml 생성된 LB는 svc의 포트를 따라간다. Ingress (제일 중요!) path 기반 라우팅 (/board로 가면 board 앱으로, /login으로 가면 login 앱으로) 일반적인 svc는 path 기반 라우팅이 불가능하다. (LoadBalancer, NodePort, ClusterIP) 서비스는 한 종류의 라벨만 품을 수 있기 때문에 이런 한계가 발생한다. 합칠 수 없다 = 같은 주소가 될 수 없다. 여러 개의 컨테이너에 각 기능들을 구현하면 path로 라우팅이 가능해야 한다. 일반적인 svc는 path 기반 라우팅이 불가능하기 때문에 Ingress라는 리소스가 필요하다. Ingress를 구성하면 path 기반 라우팅이 가능하다. ex) www.naver.com/board 로 오면 svcboard라는 svc로 보내줘. ex) www.naver.com/login 으로 오면 svclogin이라는 svc로 보내줘. → 하나의 접속지점(www.naver.com)을 통해 여러 개의 svc를 구성할 수 있다. Ingress를 구성하기 위해서는 Ingress Controller가 필요하다. (AWS EKS에서는 Ingress Controller를 LoadBalancer Controller라고 부른다.) Ingress Controller 설치 bash vi deploy.yaml 필요한 부분 수정. (type 을 NodePort에서 LoadBalancer로 수정한다.) bash kubectl apply f deploy.yaml kubectl get svc n ingressnginx Ingress 매니페스트 작성 bash cp ../svc/ip.yml . vi ip.yml yml apiVersion: v1 kind: Service metadata: name: svcipnginx spec: selector: app: myipnginx ports: port: 80 targetPort: 80 apiVersion: apps/v1 kind: Deployment metadata: name: ipdep spec: replicas: 2 selector: matchLabels: app: myipnginx template: metadata: labels: app: myipnginx spec: containers: image: public.ecr.aws/docker/library/httpd:alpine name: ipcon bash kubectl apply f ip.yml kubectl describe svc svcipnginx 서비스가 정상인지 확인. bash vi ingip.yml yml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingip annotations: nginx.ingress.kubernetes.io/rewritetarget: / spec: ingressClassName: "nginx" rules: host: rapa.com http: paths: path: /httpd pathType: Prefix backend: service: name: svcipnginx port: number: 80 annotation : 추가적인 정보. labels와 비슷하지만 주로 부가적인 기능 명시. ingressClassName : ingresscontroller의 종류 중에 nginx 방식을 사용. rewritetarget: / → 비록 /httpd라는 경로로 들어왔더라도 실제 pod에서는 /라는 경로로 바꿔주는 기능. host : 영문주소. IP는 안됨. DNS 기능이 필요하다. 인증서가 있다면 https 통신도 가능하다. path : 한 종류의 앱. pathType: Prefix → /httpd로 접근하는 애들 전부. 서비스의 이름을 마치 주소처럼 사용하고 있다. bash kubectl apply f ingip.yml ingress를 describe 했을 때 endpoint들(pod들)이 잘 떠있는 것만 봐도 ingresssvcpod가 잘 연결되어 있는 걸 어느정도 확인할 수 있다. 원래는 DNS를 통해서 rapa.com에 해당하는 IP를 매핑시켜줘야 하지만, 미니 DNS인 /etc/hosts 파일을 사용하자. bash vi /etc/hosts Ingress 트래픽 흐름 쿠버네티스에서 외부 사용자가 도메인 이름(rapa.com)을 치고 들어와서 실제 앱(pod)까지 도달하는 ingress 트래픽 흐름. rapa.com → ingresscontroller의 svc ExternalIP(DNS) → ingress(path 기반 라우팅) → svc → pod

May 12, 2026kubernetes

[Docker] Compose 파일 작성법과 주요 옵션 총정리

Docker compose 도커(docker run)의 경우에는 단일 컨테이너를 실행한다. 도커 컴포즈는 여러 종류의 컨테이너를 한번에 띄울 수 있다. ex) 도커로 3tier를 구성한다면, docker run 을 3번 해서 webwasdb 컨테이너를 각각 구성해야 하고 —link도 구성해줘야 한다. 하지만 docker compose의 경우엔 3종류의 컨테이너를 컴포즈 파일 하나에 서 동시에 구성이 가능하다. 컨테이너를 띄우는 목적은 뭘까? 서비스를 제공하고 싶기 때문이다. 컨테이너 안에 앱, 애플리케이션이 들어있다. 도커 컴포즈에서는 이런 한 종류의 컨테이너를 service라고 지칭한다. mkdir /com cd /com vi dockercompose.yml dockercompose.yml 이라는 파일명 = 디폴트값 한 개의 서비스로 구성된 도커 컴포즈 파일 편집 services: 내가 띄울 다양한 종류의 컨테이너들 webserver: 서비스의 이름. 내가 원하는대로 정하면 됨. image: nginx ports: '8787:80' publish 기능 networks: webnet 아직 만들진 않았다. 밑에서 만들예정. 놓여질 네트워크 networks: webnet: webnet이라는 이름의 네트워크 생성. 샘플 코드. docker compose up 잘 동작한다. docker compose down 도커 컴포즈 삭제 docker compose up d docker run 과 비슷하게 d (detach) 백그라운드로 동작할 수 있다. 볼륨 구성 호스트의 현재 디렉토리에 vtest라는 디렉토리를 구성한 후 간단한 인덱스 파일을 생성하여 컨테이너에 볼륨 구성을 통해 웹루트디렉토리에 넣어주고 싶다. mkdir ./vtest 경로 생성. echo composevolumetest vtest/index.html 인덱스 파일 생성. vi dockercompose.yml services: 내가 띄울 다양한 종류의 컨테이너들 webserver: 서비스의 이름. 내가 원하는대로 정하면 됨. image: nginx ports: '8787:80' publish 기능 networks: webnet 아직 만들진 않았다. 밑에서 만들예정. 놓여질 네트워크 volumes: ./vtest:/usr/share/nginx/html 호스트의 ./vtest를 컨테이너의 /usr/share/nginx/html에 마운트 networks: webnet: webnet이라는 이름의 네트워크 생성. docker compose up d 마운트가 잘 되었다. dockercompose.yml 옵션들에 대해 알아보자. networks: 네트워크 정의 및 선택 ports: \p, publish 옵션 volumes: \v, 호스트와 컨테이너 마운트 command: CMD environment: \e, 환경변수 dependson: 의존성 설정(컨테이너 띄울 순서)도 가능. ex) node.js 앱(todo, weather, chat)의 경우 몽고디비가 연동이 안되면 앱 자체가 죽어버린다. node.js 서비스를 정의하면서 몽고디비를 depends\on 으로 걸어줘야 한다. /com의 ubun 이라는 경로에서 위 명령어를 활용하여 ubuntu:latest를 동작시키는 compose 파일을 만들어 보자. 네트워크 : ubun\net mkdir ubun cd ubun/ vi dockercompose.yml services: ubun: image: ubuntu:latest networks: ubunnet command: "sleep infinity" networks: ubunnet: docker compose up d docker compose down environment: ENVTEST=test ubun 서비스에 환경변수 추가. docker compose up d docker exec it ubunubun1 bash 환경변수가 잘 들어있다. 도커 컴포즈에서는 —link 를 굳이 명시하지 않아도 서비스의 이름으로 찾아갈 수 있다. wordpress 구성하기! mysql:8, wordpress:latest를 베이스 이미지로 하여, Dockerfile은 쓰지않고, dockercompose.yml 파일을 구성해보자. publish 포트는 wordpress는 1234로 하고, mysql는 따로 publish 하지 않는다. mkdir wp cd wp vi dockercompose.yml services: wp: image: wordpress:latest ports: '1234:80' environment: WORDPRESSDBHOST=dbdb WORDPRESSDBNAME=wpdb WORDPRESSDBUSER=wpuser WORDPRESSDBPASSWORD=1234 networks: wpnet dependson: dbdb dbdb: image: mysql:8 environment: MYSQLROOTPASSWORD: '1234' MYSQLUSER: 'wpuser' MYSQLPASSWORD: '1234' MYSQLDATABASE: 'wpdb' networks: wpnet networks: wpnet: 성공! 기존에 존재하는 네트워크를 사용하고 싶을 때 docker network create mynet driver=bridge 네트워크 생성. vi dockercompose.yml 172.19.0.0 대역에 생성됐다. 빌드한 이미지로 서비스 구성 mkdir build cd build/ vi Dockerfile FROM httpd:latest 도커 파일 생성. vi dockercompose.yml services: myweb: build: . dockercompose.yml 파일이 있는 경로(.)의 Dockerfile을 빌드 도커 컴포즈 파일 생성. docker compose up d echo buildtest index.html index.html 파일 생성. vi Dockerfile 위에서 생성한 index.html 파일을 넣어보자. FROM httpd:latest WORKDIR /usr/local/apache2/htdocs COPY index.html index.html docker compose up d curl localhost:5959 기본 페이지가 뜨고 dockercompose up d 를 했지만 이미지가 빌드되지 않았다. 이미 빌드를 한 적이 있어서 빌드된 이미지가 존재하면 다시 빌드하지 않는다. docker compose down 컨테이너 종료. docker compose up d build —build 옵션을 명시해야 계속 빌드한다. 다시 curl을 찍어보면, 수정한 Dockerfile 대로 다시 빌드가 되었다. docker compose down 컨테이너 종료. 이번엔 빌드를 하 되, 도커파일을 지정해줘보자. vi dockercompose.yml services: myweb: build: dockercompose.yml 파일이 있는 경로(.)의 Dockerfile을 빌드 context: . 디렉토리 지정 dockerfile: Dockerfile 도커파일의 이름 지정. image: myimg:1 빌드해서 나온 이미지의 이름. 단독으로 쓰일때와는 의미가 좀 다르다. ports: '5959:80' context: 도커가 빌드를 시작할 때 참고할 작업 폴더의 위치. context: . 으로 되어있으면 도커는 현재 폴더에 있는 Dockerfile, 소스코드, package.json 등을 모두 빌드 컨텍스트 라는 임시 공간에 담는다. 위 코드 중 context, build 부분 해석 → Dockerfile 란 이름의 도커파일로 빌드를 하는데, 지정한 디렉토리(현재 디렉토리)의 모든 내용을 빌드해라. docker compose scaling —scaling = 로 서비스를 구성하는 컨테이너의 수를 변경할 수 있다. dockercompose.yml 파일에 포트 범위를 명시해준다. 하나의 접속 지점을 통해 로드밸런싱이 됐으면 좋겠지만 docker compose 에서는 그게 불가능하다. 서비스를 구성하는 컨테이너마다 호스트의 포트를 1:1 로 맵핑시켜야 한다. 왜? 도커 컴포즈에서 scale 옵션을 통해 컨테이너 개수를 늘리는 것은 동일한 서비스를 여러 개 복제하여 실행하는 기능에 불과하다. 이 방식은 단순히 물리적인 숫자를 늘려줄 뿐, 외부에서 들어오는 트래픽을 각 컨테이너의 상태나 부하 정도에 맞춰 지능적으로 분산해주는 전문적인 로드밸런싱 기능을 포함하지 않는다. 따라서 여러 개의 컨테이너를 띄우더라도 특정 컨테이너에만 요청이 몰리거나, 장애가 발생한 컨테이너로 접속이 시도되는 등의 한계가 존재한다. 이를 해결하기 위해서는 Nginx나 HAProxy와 같은 별도의 로드밸런서 서비스를 도커 컴포즈 설정에 추가하여 앞단에 배치해야 한다. 전문 로드밸런서는 들어오는 모든 요청을 단일 지점에서 받아 각 컨테이너로 골고루 전달하고, 컨테이너의 생존 여부를 실시간으로 확인하여 정상적인 곳으로만 트래픽을 보내는 가이드 역할을 수행한다. 결과적으로 효율적인 트래픽 분산과 안정적인 서비스 유지를 위해서는 단순한 개수 확장보다는 로드밸런서를 통한 체계적인 관리가 필수적이다.

May 12, 2026Docker