초보를 위한 쿠버네티스 안내서를 수강하며 정리한 내용입니다.

개념

• ConfigMap과 유사하지만 보안 정보를 관리하기 위해 Secret을 별도로 제공
• 데이터가 base64로 저장된다는 것이 ConfigMap과의 차이점
• 주의사항으로 Secret이 보안 정보를 저장하기 위해 만들어졌지만 실제로 데이터가 암호화되지는 않음, etcd에 접근이 가능하다면 누구나 저장된 Secret을 확인할 수 있기 때문에 별도의 암호화 솔루션을 쓰는 것이 좋음

Secret 만들기

• 사용자명이 작성된 텍스트 파일 생성

admin

• 비밀번호가 작성된 텍스트 파일 생성

1q2w3e4r

• Secret을 만들고 확인

# Secret 생성
kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt

# Secret 상세 조회
kubectl describe secret/db-user-pass

# -o yaml로 상세 조회
kubectl describe secret/db-user-pass -o yaml

# 저장된 데이터를 base64 decode
echo 'MXEydzNlNHIK' | base64 --decode

Secret을 환경변수로 사용

• 설정한 Secret을 환경변수로 연결

apiVersion: v1
kind: Pod
metadata:
  name: alpine-env
spec:
  containers:
    - name: alpine
      image: alpine
      command: ["sleep"]
      args: ["10000"]
      env:
        - name: DB_USERNAME
          valueFrom:
            secretKeyRef:
              name: db-user-pass
              key: username.txt
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-user-pass
              key: password.txt

초보를 위한 쿠버네티스 안내서를 수강하며 정리한 내용입니다.

개념

• 컨테이너에서 설정 파일을 관리하는 방법은 이미지를 빌드할 때 복사하거나 컨테이너를 실행할 때 외부 파일을 연결하는 방법이 있음
• 쿠버네티스는 ConfigMap으로 설정을 관리

ConfigMap 만들기

파일을 ConfigMap으로 만들기

설정 파일

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: prometheus
    metrics_path: /prometheus/metrics
    static_configs:
      - targets:
        - localhost: 9090

• --from-file 옵션을 사용하여 파일을 설정으로 만듦

# ConfigMap 생성 configmap -> cm
kubectl create cm my-config --from-file=config-file.yaml

# ConfigMap 조회
kubectl get cm

# ConfigMap 내용 상세 조회
kubectl describe cm/my-config

• 생성한 ConfigMap을 /etc/config 디렉터리에 연결

apiVersion: v1
kind: Pod
metadata:
  name: alpine
spec:
  containers:
    - name: alpine
      image: alpine
      command: ["sleep"]
      args: ["10000"]
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config
  volumes:
    - name: config-vol
      configMap:
        name: my-config

env 파일

• env 형식을 사용해서 YAML 파일 생성

hello=world
haha=hoho

• --from-env-file 옵션을 사용하여 파일을 설정으로 만듦

# env 형식으로 생성
kubectl create cm env-config --from-env-file=config-env.yaml

# env-config 조회
kubectl describe cm/env-config

YAML 선언하기

• ConfigMap을 YAML 파일로 정의

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  hello: world
  kuber: netes
  multiline: |-
    first
    second
    thrid

# configmap 생성
kubectl apply -f config-map.yaml

ConfigMap을 환경변수로 사용

• ConfigMap을 Volume이 아닌 환경변수로 설정

apiVersion: v1
kind: Pod
metadata:
  name: alpine-env
spec:
  containers:
    - name: alpine
      image: alpine
      command: ["sleep"]
      args: ["10000"]
      env:
        - name: hello
          valueFrom:
            configMapKeyRef:
              name: my-config
              key: hello

초보를 위한 쿠버네티스 안내서를 수강하며 정리한 내용입니다.

개념

• Pod를 제거하면 컨테이너 내부에 저장했던 데이터도 모두 사라짐
• 데이터가 유실되지 않으려면 별도의 저장소에 데이터를 저장하고 컨테이너를 새로 만들 때 이전 데이터를 가져와야 함
• 쿠버네티스는 Volume을 이용하여 컨테이너의 디렉터리를 외부 저장소와 연결하고 다양한 플러그인을 지원하여 흔히 사용하는 대부분의 스토리지를 사용할 수 있음

empty-dir

• Pod 안에 속한 컨테이너 간 디렉터리를 공유하는 방법
• 보통 사이드카라는 패턴에서 사용, 예를 들어 특정 컨테이너에서 생성되는 로그 파일을 별도의 컨테이너(사이드카)가 수집할 수 있음

apiVersion: v1
kind: Pod
metadata:
  name: sidecar
spec:
  containers:
    - name: app
      image: busybox
      args:
        - /bin/sh
        - -c
        - >
          while true;
          do
            echo "$(date)\n" >> /var/log/example.log;
            sleep 1;
          done
        volumeMounts:
          - name: varlog
            mountPath: /var/log
      - name: sidecar
        image: busybox
        args: [/bin/sh, -c, "tail -f /var/log/example.log"]
        volumeMounts:
          - name: varlog
            mountPath: /var/log
  volumes:
    - name: varlog
      emptyDir: {}

hostpath

• 호스트(Node) 디렉터리를 컨테이너 디렉터리에 연결하는 방법

apiVersion: v1
kind: Pod
metadata:
  name: host-log
spec:
  containers:
    - name: log
      image: busybox
      args: ["/bin/sh", "-c", "sleep infinity"]
      volumeMounts:
        - name: varlog
          mountPath: /host/var/log
  volumes:
    - name: varlog
      hostPath:
        path: /var/log

초보를 위한 쿠버네티스 안내서를 수강하며 정리한 내용입니다.

개념

• Service는 서비스 하나당 하나의 포트만 오픈할 수 있어서 서비스가 늘어나면 관리가 어려워짐
• Ingress는 포트를 하나만 오픈하고 도메인이나 경로에 따라서 서비스를 분기

Ingress 만들기

• 첫 번째 서비스

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-v1
spec:
  rules:
    - host: v1.echo.192.168.64.5.sslip.io
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: echo-v1
                port:
                  number: 3000

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-v1
spec:
  replicas: 3
  selector:
    matchLables:
      app: echo
      tier: app
      version: v1
  template:
    metadata:
      lables:
        app: echo
        tier: app
        version: v1
    spec:
      containers:
        - name: echo
          image: ghcr.io/subicura/echo:V1
          livenessProbe:
            httpGet:
              path: /
              port: 3000

---
apiVersion: v1
kind: Service
metadata:
  name: echo-v1
spec:
  ports:
    - port: 3000
      protocol: TCP
  selector:
    app: echo
    tier: app
    version: v1

• 두 번째 서비스

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-v2
spec:
  rules:
    - host: v2.echo.192.168.64.5.sslip.io
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: echo-v2
                port:
                  number: 3000

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-v2
spec:
  replicas: 3
  selector:
    matchLables:
      app: echo
      tier: app
      version: v2
  template:
    metadata:
      lables:
        app: echo
        tier: app
        version: v2
    spec:
      containers:
        - name: echo
          image: ghcr.io/subicura/echo:V2
          livenessProbe:
            httpGet:
              path: /
              port: 3000

---
apiVersion: v1
kind: Service
metadata:
  name: echo-v2
spec:
  ports:
    - port: 3000
      protocol: TCP
  selector:
    app: echo
    tier: app
    version: v2

• IP 주소는 하나이지만 도메인에 따라 서로 다른 서비스에 접근

초보를 위한 쿠버네티스 안내서를 수강하며 정리한 내용입니다.

개념

• Pod는 자체 IP 주소를 가지고 다른 Pod와 통신할 수 있지만 쉽게 사라지고 생성되는 특징 때문에 직접 통신하는 방법은 권장하지 않음
• 쿠버네티스는 Pod와 직접 통신하는 방법 대신에 별도의 고정된 IP 주소를 가진 Service를 만들고 이를 통해 Pod에 접근하는 방식을 사용
• 노출 범위에 따라 ClusterIP, NodePort, LoadBalancer 유형으로 나뉨

ClusterIP 만들기

• 외부에서 Pod로 접속하는 것이 아니라 클러스터 내부에 있는 Pod가 또 다른 Pod에 접속하기 위해 만드는 Service
• ClusterIP는 클러스터 내부에서 새로운 IP 주소를 할당하고 여러 개의 Pod를 바라보는 로드밸런서 기능을 제공
• Service 이름을 내부 도메인 서버에 등록하여 Pod 간에 Service 이름으로 통신할 수 있음

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
spec:
  selector:
    metchLables:
      app: counter
      tier: db
  template:
    metadata:
      labels:
        app: counter
        tier: db
    spec:
      containers:
        - name: redis
          image: redis
          ports:
            - containerPorts: 6379
              protocol: TCP

---
apiVersion: v1
kind: Service
metadata:
  name: redis
spec:
  ports:
    - port: 6379
      protocol: TCP
  selector:
    app: counter
    tier: db

• 같은 클러스터에서 생성된 Pod라면 redis라는 도메인으로 redis Pod에 접근할 수 있음
• spec.ports.port: Service가 생성할 Port
• spec.ports.targetPort: Service가 접근할 Pod의 Port (기본값: port와 동일)
• spec.selector: Service가 접근할 Pod의 label 조건

apiVersion: apps/v1
kind: Deployment
metadata:
  name: counter
spec:
  selector:
    matchLables:
      app: counter
      tier: app
  template:
    metadata:
      labels:
        app: counter
        tier: app
    spec:
      containers:
        - name: counter
          image: ghcr.io/subicura/counter:latest
          env:
            - name: REDIS_HOST
              value: "redis"
            - name: REDIS_PORT
              value: "6379"

• Redis에 접근하는 Counter 앱에서 REDIS_HOST의 값을 redis로 주었음

NodePort 만들기

• 클러스터 외부에서 접근할 때 필요한 Service는 NodePort

apiVersion: v1
kind: Service
metadata:
  name: counter-np
spec:
  type: NodePort
  ports:
    - port: 3000
      protocol: TCP
      nodePort: 31000
  selector:
    app: counter
    tier: app

• spec.ports.nodePort: Node에 오픈할 Port (미지정 시 30000-32768 중에 자동 할당)
• NodePort는 클러스터의 모든 Node에서 포트를 오픈, 여러 개의 Node가 있을 때 아무 Node로 접근해도 지정한 Pod로 접근하게 됨
• NodePort는 ClusterIP의 기능을 기본적으로 포함

LoadBalancer 만들기

• NodePort의 단점은 Node가 사라졌을 때 자동으로 다른 Node를 통해 접근이 불가능하다는 점, 예를 들어 3개의 Node가 있다면 3개 중에 아무 Node로 접근해도 NodePort로 연결할 수 있지만 어떤 Node가 정상 작동하는지 알 수 없음
• 자동으로 정상 작동하는 Node에 접근하기 위해 모든 Node를 바라보는 LoadBalancer가 필요, LoadBalancer는 NodePort가 정상 작동하는지 계속 확인하며 만약 Node에 문제가 생기면 다른 Node로 요청을 보냄
• 브라우저는 NodePort에 직접 요청을 보내는 것이 아니라 LoadBalancer에 요청을 하고 LoadBalancer가 알아서 정상 작동하는 Node에 접근하면 NodePort의 단점을 없앨 수 있음

apiVersion: v1
kind: Service
metadata:
  name: counter-lb
spec:
  type: LoadBalancer
  ports:
    - port: 30000
      targetPort: 3000
      protocol: TCP
  selector:
    app: counter
    tier: app

• 일반적인 경우에는 NodePort보다 LoadBalancer를 많이 사용
• 그러나 LoadBalancer는 하나의 서비스밖에 바라보지 못한다는 문제가 있음, 예를 들어 쿠버네티스 클러스터에 여러 개의 앱이 있다면 각각의 LoadBalancer가 필요, 서비스가 늘어날 때마다 LoadBalancer를 추가해야 함, 그래서 Ingress를 주로 사용

초보를 위한 쿠버네티스 안내서를 수강하며 정리한 내용입니다.

개념

• Deployment는 쿠버네티스에서 가장 널리 사용되는 오브젝트, ReplicaSet을 이용하여 Pod를 업데이트하고 이력을 관리하여 롤백하거나 특정 버전으로 돌아갈 수 있음

Deployment 만들기

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-deploy
spec:
  replicas: 4
  selector:
    matchLabels:
      app: echo
      tier: app
  template:
    metadata:
      labels:
        app: echo
        tier: app
    spec:
      containers:
        - name: echo
          image: ghrc.io/subicura/echo:v1

• 기존 설정에서 이미지 태그만 변경하고 다시 적용

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-deploy
spec:
  replicas: 4
  selector:
    matchLabels:
      app: echo
      tier: app
  template:
    metadata:
      labels:
        app: echo
        tier: app
    spec:
      containers:
        - name: echo
          image: ghrc.io/subicura/echo:v2 # v1 -> v2

# 새로운 이미지로 업데이트
kubectl apply -f echo-deployment-v2.yaml

# 리소스 확인
kubectl get po, rs, deploy

• Deployment는 새로운 이미지로 업데이트하기 위해 ReplicaSet을 이용, 버전을 업데이트하면 새로운 ReplicaSet을 생성하고 해당 ReplicaSet이 새로운 버전의 Pod를 생성
• 새로운 ReplicaSet에서 Pod를 0개에서 1개로 조정하고 정상적으로 Pod가 동작하면 기존 ReplicaSet에서 Pod를 하나 줄임
• 최종적으로 새로운 ReplicaSet에서 원하는 개수의 Pod가 모두 정상적으로 동작하면 기존 ReplicaSet의 Pod는 0개로 조정되며 업데이트가 완료됨

버전 관리

• Deployment는 변경된 상태를 기록

# 히스토리 확인
kubectl rollout history deploy/echo-deploy

# revision 1 히스토리 상세 확인
kubectl rollout history deploy/echo-deploy --revision=1

# 바로 전으로 롤백
kubectl rollout undo deploy/echo-deploy

# 특정 버전으로 롤백
kubectl rollout undo deploy/echo-deploy --to-revision=2

배포 전략 설정

• Deployment에는 다양한 배포 전략이 있음
• 롤링 업데이트 방식을 사용할 때 동시에 업데이트하는 Pod의 개수를 다음과 같이 변경할 수 있음

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-deploy
spec:
  replicas: 4
  selector:
    matchLabels:
      app: echo
      tier: app
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3
      maxUnavailable: 3
  template:
    metadata:
      labels:
        app: echo
        tier: app
    spec:
      containers:
        - name: echo
          image: ghrc.io/subicura/echo:v2 # v1 -> v2

초보를 위한 쿠버네티스 안내서를 수강하며 정리한 내용입니다.

개념

• Pod는 단독으로 만들면 어떠한 문제가 생겼을 때 자동으로 복구되지 않음, 이러한 Pod를 정해진 수만큼 복제하고 관리하는 것이 ReplicaSet
• ReplicaSet은 원하는 개수의 Pod를 유지하는 역할을 담당
• label을 이용하여 Pod를 체크하기 때문에 겹치지 않게 주의해야 함
• ReplicaSet이 단독으로 쓰이는 경우는 거의 없음, Deployment가 ReplicaSet을 이용

ReplicaSet 만들기

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: echo-rs
spec:
  replicas: 1
  selector:
    matchLables:
      app: echo
      tier: app
    template:
      metadata:
        labels:
          app: echo
          tier: app
      spec:
        containers:
          - name: echo
            image: ghcr.io/subicura/echo:v1

• spec.replicas: 원하는 Pod의 개수
• spec.selector: label 체크 조건
• spec.template: 생성할 Pod의 명세

Scale out

• ReplicaSet을 이용하면 손쉽게 Pod를 여러 개로 복제할 수 있음

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: echo-rs
spec:
  replicas: 4 # 1 -> 4
  selector:
    matchLables:
      app: echo
      tier: app
    template:
      metadata:
        labels:
          app: echo
          tier: app
      spec:
        containers:
          - name: echo
            image: ghcr.io/subicura/echo:v1

초보를 위한 쿠버네티스 안내서를 수강하며 정리한 내용입니다.

개념

• Pod은 쿠버네티스에서 관리하는 가장 작은 배포 단위
• 도커는 컨테이너를 만들지만, 쿠버네티스는 컨테이너 대신 Pod를 만듦
• Pod는 한 개 또는 여러 개의 컨테이너를 포함

Pod 만들기

YAML로 설정 파일 작성

apiVersion: v1
kind: Pod
metadata:
  name: echo
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1

# Pod 생성
kubectl apply -f echo-pod.yaml

# Pod 목록 조회
kubectl get po

# Pod 로그 조회
kubectl logs echo
kubectl logs -f echo

# Pod 컨테이너 접속
kubectl exec -it echo -- sh

# Pod 제거
kubectl delete -f echo-pod.yaml

컨테이너 상태 모니터링

• 컨테이너 생성과 실제 서비스 준비에는 차이가 있음, 서버를 실행하면 바로 접속할 수 없고 짧게는 수 초에서 길게는 수 분의 초기화 시간이 필요한데 서비스에 접속이 가능할 때 서비스가 준비되었다고 할 수 있음
• 쿠버네티스는 컨테이너가 생성되고 서비스가 준비되었다는 것을 확인하는 옵션을 제공

첫 번째 방법: livenessProbe

• 컨테이너가 정상적으로 동작하는지 확인하고 비정상이라면 컨테이너를 재시작하여 문제를 해결
• 정상이라는 것은 여러 가지 방식으로 확인할 수 있는데 http get 요청을 보내서 확인할 수도 있음

apiVersion: v1
kind: Pod
metadata:
  name: echo-lp
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1
      livenessProbe:
        httpGet:
          path: /not/exist
          port: 8080
        initialDelaySeconds: 5
        timeoutSeconds: 2   # Default 1
        periodSeconds: 5    # Default 10
        failureThreshold: 1 # Default 3

두 번째 방법: readinessProbe

• 컨테이너가 준비되었는지 확인하고 비정상이라면 Pod으로 들오어는 요청을 제외시킴
• livenessProbe와 달리 문제가 있어도 Pod을 재시작하지 않고 요청만 제외시킴

apiVersion: v1
kind: Pod
metadata:
  name: echo-rp
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1
      readinessProbe:
        httpGet:
          path: /not/exist
          port: 8080
        initialDelaySeconds: 5
        timeoutSeconds: 2   # Default 1
        periodSeconds: 5    # Default 10
        failureThreshold: 1 # Default 3

세 번째 방법: livenessProbe + readinessProbe

• 일반적으로 livenessProbe와 readindessProbe를 같이 적용

apiVersion: v1
kind: Pod
metadata:
  name: echo-health
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1
      livenessProbe:
        httpGet:
          path: /
          port: 3000
      readinessProbe:
        httpGet:
          path: /
          port: 3000

다중 컨테이너

• 하나의 Pod에 속한 컨테이너는 서로 네트워크를 localhost로 공유하고 동일한 디렉터리를 공유할 수 있음

apiVersion: v1
kind: Pod
metadata:
  name: counter
  labels:
    app: counter
spec:
  containers:
    - name: app
      image: ghrc.io/subicura/counter:latest
      env:
        - name: REDIS_HOST
          value: "localhost"
    - name: db
      image: redis

초보를 위한 쿠버네티스 안내서를 수강하며 정리한 내용입니다.

kubectl은 쿠버네티스 CLI 도구, 쿠버네티스 클러스터에 명령어를 전달하는 일반적인 방법

apply

• 원하는 상태를 적용, 보통 -f 옵션으로 파일과 함께 사용
• 원하는 리소스의 상태를 YAML로 작성하고 apply 명령어 사용
• 파일명뿐만 아니라 URL도 입력 가능

kubectl apply -f https://subicura.com/k8s/code/guide/index/wordpress-k8s.yml

get

• 쿠버네티스에 선언된 리소스를 확인하는 명령어
• -o 옵션으로 출력 형식을 변경할 수 있음
• --show-labels 옵션으로 레이블을 확인할 수 있음

# Pod 조회
kubectl get pod
kubectl get pods
kubectl get po

# Service 조회
kubectl get service
kubectl get svc

# 여러 유형 조회
kubectl get po, svc

# Pod, ReplicaSet, Deployment, Service, Job 조회
kubectl get all

# 추가 정보 조회
kubectl get po -o wide

# yaml 형식으로 출력
kubectl get po -o yaml

# JSON 형식으로 출력
kubectl get po -o json

# Lable을 같이 출력
kubectl get po --show-labels

describe

• 리소스의 상태를 자세하게 보여줌
• 특정 리소스의 상태가 궁금하거나 생성이 실패한 이유를 확인할 때 주로 사용

# Pod 조회로 이름 검색
kubectl get po

# 조회한 이름으로 상세 확인
kubectl describe po/wordpress-5f59577d4d-Bt2dg

delete

• 쿠버네티스에 선언된 리소스를 제거

# Pod 조회로 이름 검색
kubectl get po

#조회한 Pod 제거
kubectl delete po/wordpress-5f59577d4d-Bt2dg

logs

• 컨테이너의 로그 확인
• 실시간 로그를 보려면 -f 옵션 사용
• 하나의 Pod에 여러 개의 컨테이너가 있는 경우 -c 옵션으로 컨테이너를 지정해야 함

# Pod 조회로 이름 검색
kubectl get po

# 조회한 Pod 로그 조회
kubectl logs wordpress-5f59577d4d-Bt2dg

# 실시간 로그 보기
kubectl logs -f wordpress-5f59577d4d-Bt2dg

exec

• 컨테이너에 명령어 전달, 컨테이너에 접근할 때 주로 사용
• 셸로 접속하여 컨테이너 상태를 확인하는 경우 -it 옵션을 사용
• 여러 개의 컨테이너가 있는 경우 -c 옵션으로 컨테이너를 지정해야 함

# Pod 조회로 이름 검색
kubectl get po

# 조회한 Pod의 컨테이너에 접속
kubectl exec -it wordpress-5f59577d4d-Bt2dg -- bash

config

• kubectl 설정을 관리
• kubectl은 여러 개의 쿠버네티스 클러스터를 컨텍스트로 설정하고 필요에 따라 선택할 수 있음
• 현재 어떤 컨텍스트로 설정되어 있는지 확인하고 원하는 컨텍스트를 지정

# 현재 컨텍스트 확인
kubectl config current-context

# 컨텍스트 설정
kubectl config use-context minikube

그 외

# 전체 오브젝트 종류 확인
kubectl api-resources

# 특정 오브젝트 설명 보기
kubectl explain pod

초보를 위한 쿠버네티스 안내서를 수강하며 정리한 내용입니다.

Desired state를 다양한 오브젝트로 정의하고 API Server에 YAML 형식으로 전달

Object Spec

• YAML 형식으로 작성

aipVersion

• apps/v1, v1, batch/v1, networking.k8s.io/v1, ...

kind

• Pod, Deployment, Service, Ingress, ...

metaData

• name, label, namespace

spec

• 각종 설정

status(read-only)

• 시스템에서 관리하는 최신 상태

초보를 위한 쿠버네티스 안내서를 수강하며 정리한 내용입니다.

Pod

• 쿠버네티스에서 컨테이너를 관리하는 가장 작은 배포 단위
• 쿠버네티스는 컨테이너를 직접 관리하지 않고 Pod로 감싸서 관리
• 컨테이너를 배포하는 것이 아니라 Pod를 배포
• Pod마다 IP 주소를 부여 받음, IP 주소를 통해서 내부적으로 통신할 수 있음
• Pod 안에 컨테이너가 하나 이상 존재
• Pod 안에 있는 컨테이너끼리 폴더를 공유할 수 있음
• Pod 안에 있는 컨테이너끼리 포트를 localhost로 공유할 수 있음

ReplicaSet

• 여러 개의 Pod를 관리
• 새로운 Pod는 Template을 참고하여 생성

Deployment

• 배포 버전 관리
• 내부적으로 ReplicaSet을 이용
• 무중단으로 배포 버전을 바꿀 때 기존의 ReplicaSet과 다른 새로운 ReplicaSet을 만듦

Service

ClusterIP

• 클러스터 내부에서 사용하는 프록시, 외부에서는 접근 불가
• Pod에 로드 밸런싱
• Pod는 동적이지만 Service는 고유한 IP를 가짐
• Pod가 사라지고 새로 생성되면서 Pod의 IP도 언제든 사라지고 바뀌게 됨, 요청을 Pod로 바로 보내지 않고 Service에 요청을 보내면 Pod에 전달됨
• 클러스터 내부에서 Service 연결은 DNS를 이용

NodePort

• Node에 노출되어 외부에서 접근 가능한 Service
• Node에 포트가 생기고 이를 통해 접속하면 해당 요청이 ClusterIP를 거쳐 Pod로 전달됨
• 모든 Node에 동일한 포트로 생성됨, 어느 노드로 요청을 보내도 알맞은 ClusterIP를 찾아 요청을 전달

LoadBalancer

• 도메인이 연결된 특정 노드가 중단됐을 때를 대비하여 NodePort 앞에 LoadBalancer를 둠
• LoadBalancer로 보낸 요청은 NodePort와 ClusterIP를 거쳐 Pod로 전달됨

Ingress

• 도메인 또는 경로별 라우팅
• 도메인 이름과 도메인 뒤에 붙는 경로에 따라서 내부에 있는 ClusterIP에 연결할 수 있음

일반적인 구성

• Deployment를 생성하면 Deployment가 ReplicaSet을 자동으로 생성하고 ReplicaSet이 자동으로 Pod를 생성
• 외부에 노출하기 위해 ClusterIP와 Ingress 생성, Ingress를 만들면 NodePort와 LoadBalancer가 자동으로 생성됨
• 클라이언트는 도메인으로 접속하면 LoadBalancer, NodePort, ClusterIP를 거쳐서 Pod에 연결됨

그 외 기본 오브젝트

• Volume: 스토리지
• Namespace: 논리적인 리소스 구분
• ConfigMap / Secret: 설정
• ServiceAccount: 권한 계정
• Role / ClusterRole: 권한 설정

초보를 위한 쿠버네티스 안내서를 수강하며 정리한 내용입니다.

중간에서 상태를 확인하고 실행하는 영역은 Master, 실제로 컨테이너가 실행되는 영역은 Node

Master

• 상태 확인(Observe) -> 차이점 발견(Diff) -> 조치(Act)
  • Current State와 Desired State가 일치하는지 확인, 차이점이 발견되면 Current State가 Desired State가 되도록 조치, 이 과정을 반복
• API Server
  • 상태를 바꾸거나 조회
  • etcd와 유일하게 통신하는 모듈
  • REST API 형태로 제공
  • 권한을 확인하여 적절한 권한이 없을 경우 요청을 차단
  • 관리자 요청 뿐 아니라 다양한 내부 모듈과 통신
  • 수평으로 확장되도록 디자인
• etcd
  • 모든 상태와 데이터를 저장
  • 분산 시스템으로 구성하여 안전성을 높임 (고가용성)
  • 가볍고 빠르면서 정확하게 설계 (일관성)
  • Key-Value 형태로 데이터 저장
  • 백업 필수
• Scheduler
  • 새로 생성된 pod를 감지하고 실행할 Node를 선택
  • Node의 현태 상태와 pod의 요구사항을 확인
• Controller
  • 끊임없이 상태를 확인하고 원하는 상태를 유지
  • 복잡성을 낮추기 위해 하나의 프로세스로 실행
  • 논리적으로 다양한 컨트롤러가 존재
• 조회 흐름
  1. Controller가 API Server에 정보 조회 요청
  2. API Server는 요청을 보낸 Controller가 정보 조회 권한이 있는지 확인
  3. 권한이 있으면 etcd에서 정보를 조회하여 Controller에게 전달
• 기본 흐름
  1. 원하는 상태가 변경되면 API Server는 Controller한테 알림
  2. Controller는 원하는 상태와 현재 상태가 불일치하기 때문에 조치를 해야 함, 원하는 상태로 리소스를 변경
  3. Controller는 리소스가 변경된 결과를 API Server한테 전달
  4. API Server는 Controller에게 정보 갱신 권한이 있는지 확인
  5. 권한이 있으면 etcd에 정보를 갱신

API Server 통신

Node

• Node에는 크게 Proxy와 Kubelet이라는 두 개의 컴포넌트가 있음
• Proxy와 Kubelet도 Master와 통신할 때 API Server만 바라봄
• Proxy
  • 네트워크 프록시와 부하 분산 역할
• Kubelet
  • 각 Node에서 실행
  • Pod을 실행 / 중지하고 상태를 확인

Pod이 생성되는 과정

1. 관리자가 API Server에 Pod 생성 요청
2. API Server는 요청을 etcd에 상태를 생성 요청으로 기록
3. Controller는 새로 생긴 Pod가 있는지 계속 확인하다가 Pod 생성 요청을 발견
4. Controller는 API Server에 실제 Pod를 할당하는 요청 보냄
5. API Server는 해당 요청을 받아서 etcd에 상태를 할당 요청으로 변경
6. Scheduler는 할당 요청이 들어온 Pod이 있는지 계속 확인하다가 Pod 할당 요청을 발견
7. Sechduler가 특정 Node에 Pod를 할당
8. API Server는 etcd에 Pod를 특정 노드에 할당하는데 아직 실행되기 전 상태라고 변경
9. Kubelet이 자신의 Node에 할당된 Pod 중에서 아직 실행이 안 된 것이 있는지 계속 확인하다가 새로 추가된 Pod를 확인
10. 해당 정보를 가지고 와서 Node에 Pod를 생성
11. API Server가 etcd에 Pod가 특정 Node에 할당되었고 실행 중이라는 상태로 변경

초보를 위한 쿠버네티스 안내서를 수강하며 정리한 내용입니다.

서버의 상태를 관리하기 위한 노력

첫 번째 아이디어: 문서화

• 방법: 프로그램을 설치하는 방법을 세세하게 문서로 작성
• 문제점: 아무리 문서를 잘 만들어도 환경(OS, 버전 등)이 바뀌면 잘 되지 않는 경우가 발생할 수 있음

두 번째 아이디어: 서버 관리 도구

• 방법: Ansible, Puppet, Chef와 같은 도구를 사용, 사용자가 직접 서버에 접속해서 명령어를 입력하는 대신에 서버 관리자가 서버 상태를 어떻게 관리하고 싶은지 설정해두면 도구가 그에 맞춰서 수행
• 문제점: 관리 도구에 대한 학습 필요, 서버 관리가 복잡해지면 도구 사용 방법도 어려워짐

세 번째 아이디어: 가상 머신

• 방법: 새로 생성한 가상 머신에 프로그램 설치
• 장점: 하나의 가상 머신에 하나의 프로그램만 실행되어 충돌과 같은 문제가 발생 가능성을 낮출 수 있음
• 단점: 속도가 느리고 특정 벤더에 의존성이 생김, 클라우드 환경에 적합하지 않을 수 있음

네 번째 아이디어: 도커

• 방법: 모든 실행 환경을 컨테이너로 구성
• 장점
  • 가상 머신과 비교하여 컨테이너 생성이 쉽고 효율적
  • 컨테이너 이미지를 이용한 배포와 롤백이 간단
  • 언어나 프레임워크에 상관없이 애플리케이션을 동일한 방식으로 관리
  • 개발, 테스팅, 운영 환경은 물론 로컬 PC와 클라우드까지 동일한 환경 구축
  • 특정 클라우드 벤더에 종속되지 않음
• 도커를 사용하는 흐름: 코드 작성 -> 도커 이미지 생성 -> 도커 허브나 별도의 저장소에 보관 -> 도커 이미지를 컨테이너로 실행
• 한계: 관리해야 할 컨테이너가 너무 많아지면 운영하기 어려워짐

도커 그 이후

문제 상황

• 여러 서버에 직접 접속해서 컨테이너를 관리하기에는 번거로움
• 컨테이너를 실행하기에 여유가 있는 서버를 찾아야 함
• 다량의 컨테이너에서 롤아웃/롤백을 할 때 중앙에서 관리하고 싶은 요구
• 새로 컨테이너와 도메인을 등록하면 관련 요청이 해당 컨테이너로 전달되도록 설정 자동화 요구
• 서비스 이상, 부하 모니터링과 대응 자동화 요구

복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구의 필요성이 높아졌고 여기에 사용되는 것이 컨테이너 오케스트레이션 기술

컨테이너 오케스트레이션

첫 번째 특징: 클러스터

• 노드를 각각 관리하지 않고 클러스터 단위로 추상화하여 관리
• 노드에 일일이 접속하기 어렵하기 때문에 마스터 서버를 두고 관리자는 마스터 서버에 명령어 사용, 마스터 서버가 노드들에게 명령어 전달
• 클러스터에 속한 노드 간에 네트워크 통신이 잘 되어야 함
• 노드의 개수가 수 만개가 되더라도 잘 동작해야 함, 부하를 잘 견디도록 설계해야 함

두 번째 특징: 상태 관리

• 관리자가 상태를 변경하면 컨테이너 오케스트레이션이 자동으로 그에 맞춰서 작업 수행

세 번째 특징: 배포 관리

• 어떤 서버에 여유가 있는지를 자동으로 파악해서 애플리케이션 배포

네 번째 특징: 버전 관리

• 직접 애플리케이션의 버전을 관리하지 않고 중앙에서 관리

다섯 번째 특징: 서비스 등록 및 조회

• 애플리케이션이 실행되고 특정 주소가 부여되면 중앙 서버에 등록
• 프록시 서버는 서비스가 등록된 저장소를 관찰하다가 변경이 감지되면 내부적으로 설정을 바꾸고 프로세스 재시작
• 관리자가 IP 주소를 일일이 바꿀 필요 없이 프로그램이 자동으로 재설정

여섯 번째 특징: 볼륨 스토리지

• 노드에 볼륨을 마운트 할 때 직접 관리하지 않고 설정을 이용해 추상적으로 관리

쿠버네티스 소개

• 컨테이너를 쉽고 빠르게 배포 / 확장하고 관리를 자동화하는 오픈소스 플랫폼
• 컨테이너를 쉽게 관리하고 연결하기 위해 논리적인 단위로 그룹화

스스로 구축하는 AWS 클라우드 인프라 - 기본편을 수강하며 AWS 인프라를 Terraform으로 작성한 내용입니다.

Read Replica 생성

• rds.tf 파일에 아래 내용 추가

resource "aws_db_instance" "rds_rr" {
  identifier                 = "rds-rr"
  replicate_source_db        = aws_db_instance.rds.identifier
  instance_class             = "db.t3.micro"
  storage_type               = "gp2"
  max_allocated_storage      = 0
  auto_minor_version_upgrade = true
  multi_az                   = false
  availability_zone          = var.availability_zones[1]
  vpc_security_group_ids     = [aws_security_group.rds_sg.id]
  publicly_accessible        = false
  copy_tags_to_snapshot      = false
  deletion_protection        = false
  skip_final_snapshot        = true
}

EC2와 Read Replica 연결

• template_file.tf 파일을 아래와 같이 변경

data "template_file" "dbinfo" {
  template = <<-EOT
  <?php
  define('DB_SERVER', '${aws_db_instance.rds_rr.address}');
  define('DB_USERNAME', '${aws_db_instance.rds.username}');
  define('DB_PASSWORD', '${aws_db_instance.rds.password}');
  define('DB_DATABASE', '${aws_db_instance.rds.db_name}');
  ?>
  EOT
}

resource "local_file" "dbinfo_file" {
  content  = data.template_file.dbinfo.rendered
  filename = "${path.module}/dbinfo.inc"
}

• Private EC2에서 RDS에 접속한 뒤 만든 데이터가 Read Replica와 연결된 웹 서버에서 올바르게 조회되는지 확인

스스로 구축하는 AWS 클라우드 인프라 - 기본편을 수강하며 AWS 인프라를 Terraform으로 작성한 내용입니다.

DB 정보 작성

• 웹 서버에서 DB에 접근할 수 있도록 dbinfo.inc 파일 필요
• template_file.tf 파일을 만들고 아래와 같이 작성하여 Terraform이 dbinfo.inc 파일을 생성하도록 함

data "template_file" "dbinfo" {
  template = <<-EOT
  <?php
  define('DB_SERVER', '${aws_db_instance.rds.address}');
  define('DB_USERNAME', '${aws_db_instance.rds.username}');
  define('DB_PASSWORD', '${aws_db_instance.rds.password}');
  define('DB_DATABASE', '${aws_db_instance.rds.db_name}');
  ?>
  EOT
}

resource "local_file" "dbinfo_file" {
  content  = data.template_file.dbinfo.rendered
  filename = "${path.module}/dbinfo.inc"
}

• dbinfo.inc 파일이 Private EC2에 저장되도록 terraform_data.tf 파일과 ami_from_instance.tf 파일을 아래와 같이 수정

resource "terraform_data" "copy_php" {
  depends_on = [aws_instance.public_ec2, local_file.dbinfo_file]

  count = length(var.availability_zones)

  connection {
    type        = "ssh"
    user        = "ec2-user"
    host        = element(aws_eip.public_ec2.*.public_ip, count.index)
    private_key = tls_private_key.ec2_private_key.*.private_key_pem[0]
  }

  provisioner "remote-exec" {
    inline = [
      "while [ ! -d /var/www/html ]; do sleep 5; done",
      "echo '/var/www/html is ready'",
      "sudo chown -R ec2-user:apache /var/www/html",
      "sudo chmod -R 775 /var/www/html"
    ]
  }

  provisioner "file" {
    source      = "${path.module}/index.php"
    destination = "/var/www/html/index.php"
  }

  provisioner "file" {
    source      = "${path.module}/dbinfo.inc"
    destination = "/var/www/html/dbinfo.inc"
  }
}

resource "terraform_data" "delete_dbinfo_file" {
  depends_on = [aws_ami_from_instance.public_ec2_ami]
  provisioner "local-exec" {
    command = "rm -f ${path.module}/dbinfo.inc"
  }
}

resource "terraform_data" "copy_key" {
  depends_on = [local_file.private_ec2_key, aws_ami_from_instance.public_ec2_ami]

  count = length(var.availability_zones)

  connection {
    type        = "ssh"
    user        = "ec2-user"
    host        = element(aws_eip.public_ec2.*.public_ip, count.index)
    private_key = tls_private_key.ec2_private_key.*.private_key_pem[0]
  }

  provisioner "remote-exec" {
    inline = [
      "mkdir /home/ec2-user/keys"
    ]
  }

  provisioner "file" {
    source      = "${path.module}/${local_file.private_ec2_key.filename}"
    destination = "/home/ec2-user/keys/${local_file.private_ec2_key.filename}"
  }

  provisioner "remote-exec" {
    inline = [
      "chmod 600 /home/ec2-user/keys/${local_file.private_ec2_key.filename}"
    ]
  }
}

resource "aws_ami_from_instance" "public_ec2_ami" {
  depends_on = [terraform_data.copy_php]

  name                    = "public-ec2-ami"
  source_instance_id      = aws_instance.public_ec2.*.id[0]
  snapshot_without_reboot = false
}

MySQL 접속

• Private EC2에서 MySQL에 접속하기 위해 아래 명령어 입력

mysql -h <RDS Endpoint> -P 3306 -u admin -p

• MySQL에 접속 후 데이터베이스 목록을 보려면 아래 명령어 입력

show databases;

• 특정 데이터베이스를 사용하려면 아래 명령어 입력

use <DatabaseToUse>;

• 데이터베이스에 SAMPLE 테이블 생성

CREATE TABLE SAMPLE (
ID INT(11) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
NAME VARCHAR(45),
ADDRESS VARCHAR(90)
);

• 테이블에 데이터 추가

INSERT INTO SAMPLE (NAME, ADDRESS) VALUES ('KIM', 'SEOUL');

• 테이블에 추가된 데이터 확인

SELECT * FROM SAMPLE;

스스로 구축하는 AWS 클라우드 인프라 - 기본편을 수강하며 AWS 인프라를 Terraform으로 작성한 내용입니다.

복수의 가용 영역에 생성하는 RDS

• 서로 다른 가용 영역의 Private Subnet에 3개의 RDS를 배치
• 하나는 Master 데이터베이스, 또 다른 하나는 Standby 데이터베이스, 마지막은 Read Replica 데이터베이스
• 기본적으로 Master 데이터베이스와 서버가 연결되어서 시스템이 운영되는데 만약 Master 데이터베이스에 장애가 발생하면 자동으로 서버와 Standby 데이터베이스가 연결됨
  • 이 과정에서 Standby 데이터베이스가 Master 데이터베이스로 변경되고 Master 데이터베이스가 Standby 데이터베이스가 되어 서로 역할이 바뀜
• 읽기 전용 복제본인 Read Replica는 Master 데이터베이스와 싱크를 맞추며 DB의 변동 내역을 실시간으로 업데이트

Security group 생성

• 데이터베이스 인스턴스에 대한 Security group 만들기
• security_group.tf 파일에 아래 내용 추가

# Security group for RDS
resource "aws_security_group" "rds_sg" {
  name = "rds-sg"
  description = "Security group for RDS"
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "rds-sg"
  }
}

# Inbound rule allowing MySQL for RDS
resource "aws_vpc_security_group_ingress_rule" "allow_mysql_for_rds" {
  security_group_id = aws_security_group.rds_sg.id
  cidr_ipv4 = aws_vpc.main.cidr_block
  from_port = "3306"
  ip_protocol = "tcp"
  to_port = "3306"
}

# Outbound rule allowing all traffic for RDS
resource "aws_vpc_security_group_egress_rule" "allow_all_outbound_traffic_for_rds" {
  security_group_id = aws_security_group.rds_sg.id
  cidr_ipv4 = "0.0.0.0/0"
  ip_protocol = "-1"
}

• 특정 VPC에서 출발한 트래픽을 허용하도록 인바운드 규칙 설정

DB Subnet group 생성

• 데이터베이스 인스턴스가 위치할 서브넷 그룹 만들기
• subnet.tf 파일을 아래와 같이 변경

# Public Subnet for ec2
# Subnet will use cidr with /24 -> The number of availability IP is 256
resource "aws_subnet" "public_for_ec2" {
  count = length(var.availability_zones)
  vpc_id = aws_vpc.main.id

  cidr_block = "10.0.${var.cidr_numeral_public_ec2[count.index]}.0/24"
  availability_zone = element(var.availability_zones, count.index)

  tags = {
    Name = "public-${count.index}-${var.vpc_name}"
  }
}

# Private Subnet for ec2
# Subnet will use cidr with /24 -> The number of availability IP is 256
resource "aws_subnet" "private_for_ec2" {
  count = length(var.availability_zones)
  vpc_id = aws_vpc.main.id

  cidr_block = "10.0.${var.cidr_numeral_private_ec2[count.index]}.0/24"
  availability_zone = element(var.availability_zones, count.index)

  tags = {
    Name = "private-${count.index}-${var.vpc_name}"
  }
}

# Private Subnet for rds
# Subnet will use cidr with /24 -> The number of availability IP is 256
resource "aws_subnet" "private_for_rds" {
  count = length(var.availability_zones)
  vpc_id = aws_vpc.main.id

  cidr_block = "10.0.${var.cidr_numeral_private_rds[count.index]}.0/24"
  availability_zone = element(var.availability_zones, count.index)

  tags = {
    Name = "private-${count.index}-${var.vpc_name}"
  }
}

• db_subnet.tf 파일을 만들고 아래와 같이 작성

resource "aws_db_subnet_group" "rds_subnet_group" {
  name = "rds-subnet-group"
  description = "Subnet group for rds-subnet-group"
  subnet_ids = aws_subnet.private_for_rds.*.id

  tags = {
    Name = "rds-subnet-group"
  }
}

KMS Key 생성 및 암호화

KMS Key 만들기

• kms_key.tf 파일을 만들고 아래 내용 추가

data "aws_caller_identity" "current" {}

resource "aws_kms_key" "rds_password_key" {
  description             = "KMS key for encrypting RDS password"
  enable_key_rotation     = true
  deletion_window_in_days = 7
  rotation_period_in_days = 90
}

resource "aws_kms_key_policy" "rds_password_key_policy" {
  key_id = aws_kms_key.rds_password_key.id
  policy = jsonencode({
    Version = "2012-10-17"
    Id      = "key-default-1"
    Statement = [
      {
        Sid    = "Enable IAM User Permissions"
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root"
        },
        Action   = "kms:*"
        Resource = "*"
      }
    ]
  })
}

resource "aws_kms_alias" "rds_password_key" {
  name          = "alias/rds-password-key"
  target_key_id = aws_kms_key.rds_password_key.key_id
}

RDS에 사용할 비밀번호 암호화

• terraform.dec.json 파일을 만들고 비밀번호 작성

{
    "secret": "Write-your-own-password"
}

• SOPS 명령어를 사용하여 비밀번호 암호화

sops --encrypt --kms=arn:aws:kms:<AWS_REGION>:<AWS_ACCOUNT_ID>:key/<AWS_KMS_KEY_ID> terraform.dec.json > terraform.enc.json

• terraform.dec.json 파일은 Git에서 관리되지 않도록 삭제하거나 .gitignore에 추가

RDS 생성

• rds.tf 파일을 만들고 아래와 같이 작성

data "external" "sops_secret" {
  program = ["sh", "-c", "sops -d terraform.enc.json | jq -r '{secret: .secret}'"]
}

resource "aws_db_instance" "rds" {
  identifier                      = "rds"
  db_name                         = "vpcrds"
  instance_class                  = "db.t3.micro"
  storage_type                    = "gp2"
  allocated_storage               = 20
  max_allocated_storage           = 0
  engine                          = "mysql"
  engine_version                  = "8.0"
  auto_minor_version_upgrade      = true
  username                        = "admin"
  password                        = data.external.sops_secret.result["secret"]
  multi_az                        = true
  db_subnet_group_name            = aws_db_subnet_group.rds_subnet_group.name
  vpc_security_group_ids          = [aws_security_group.rds_sg.id]
  publicly_accessible             = false
  parameter_group_name            = "default.mysql8.0"
  backup_retention_period         = 7
  copy_tags_to_snapshot           = true
  enabled_cloudwatch_logs_exports = ["general"]
  deletion_protection             = false
  skip_final_snapshot             = true
}

• multi_az를 true로 설정하여 복수의 가용 영역에 데이터베이스를 생성
  • Subnet group에 등록된 Subnet 중 하나에는 Master 데이터베이스가 만들어지고 다른 Subnet에는 Standby 데이터베이스가 만들어짐
• parameter_group은 데이터베이스 인스턴스 엔진의 기본적인 구성값들이 설정되어 있는 집합

스스로 구축하는 AWS 클라우드 인프라 - 기본편을 수강하며 AWS 인프라를 Terraform으로 작성한 내용입니다.

• 웹 서버를 외부와 직접적인 통신이 가능한 Public Subnet에 두는 것은 보안 측면에서 적절하지 않음
• 웹 서버를 외부와 직접적인 통신에 제한되어 있는 Private Subnet에 두고 이 영역에 있는 EC2 인스턴스를 타겟으로 하는 Application Load Balancer를 통해 트래픽을 분산하고 웹 서비스를 제공하도록 구성

Target group 생성

• Private EC2 인스턴스를 타겟으로 하는 Target group 만들기
• target_group.tf 파일에 아래 내용 추가

# Target group for private ec2 instances
resource "aws_lb_target_group" "alb_private_tg" {
  name = "alb-private-tg-${var.vpc_name}"
  vpc_id = aws_vpc.main.id
  target_type = "instance"
  port = 80
  protocol = "HTTP"
  protocol_version = "HTTP1"

  health_check {
    protocol = "HTTP"
    path = "/"
    enabled = true
    healthy_threshold = 5
    unhealthy_threshold = 2
    timeout = 5
    interval = 30
    matcher = "200"
  }

  tags = {
    Name = "alb-private-tf-${var.vpc_name}"
  }
}

# Register private ec2 instances with Target group
resource "aws_lb_target_group_attachment" "private_ec2" {
  for_each = {
    for k, v in aws_instance.private_ec2 : k => v # type casting: list to map 
  }

  target_group_arn = aws_lb_target_group.alb_private_tg.arn
  target_id = each.value.id
  port = 80
}

Security group 생성

• Application Load Balancer에 적용할 Security group 만들기
• security_group.tf 파일에 아래 내용 추가

# Security group for private ALB
resource "aws_security_group" "alb_private_sg" {
  name = "alb-private-sg"
  description = "Secutiry group for private alb"
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "alb-private-sg"
  }
}

# Inbound rule allowing HTTP for private ALB
resource "aws_vpc_security_group_ingress_rule" "allow_http_for_private_alb" {
  security_group_id = aws_security_group.alb_private_sg.id
  cidr_ipv4 = "0.0.0.0/0"
  from_port = 80
  ip_protocol = "tcp"
  to_port = 80
}

# Outbound rule allowing all traffic for private ALB
resource "aws_vpc_security_group_egress_rule" "allow_all_outbound_traffic_for_private_alb" {
  security_group_id = aws_security_group.alb_private_sg.id
  cidr_ipv4 = "0.0.0.0/0"
  ip_protocol = "-1"
}

Application Load Balancer 생성

• application_load_balancer.tf 파일에 아래 내용 추가

resource "aws_lb" "alb_private" {
  name = "alb-private"
  load_balancer_type = "application"
  internal = false
  ip_address_type = "ipv4"
  security_groups = [aws_security_group.alb_private_sg.id]

  # Indicate which subnet in the availability zone will receive traffic
  dynamic "subnet_mapping" {
    for_each = toset(aws_subnet.public_for_ec2)
    content {
      subnet_id = subnet_mapping.value.id
    }
  }
}

resource "aws_lb_listener" "alb_private_listener" {
  load_balancer_arn = aws_lb.alb_private.arn
  port = 80
  protocol = "HTTP"

  default_action {
    type = "forward"
    target_group_arn = aws_lb_target_group.alb_private_tg.arn
  }

  tags = {
    Name = "alb-private"
  }
}

• Application Load Balancer가 인터넷에서 트래픽을 받을 수 있도록 Public Subnet에 배치

스스로 구축하는 AWS 클라우드 인프라 - 기본편을 수강하며 AWS 인프라를 Terraform으로 작성한 내용입니다.

Public Subnet에 있는 EC2 인스턴스 구성 변경

Public EC2의 구성을 위한 Provisioner

• Public EC2 인스턴스가 생성되면 index.php 파일과 Private EC2에 접속하기 위한 Private Key를 로컬에서 인스턴스로 복사
• terraform_data.tf 파일을 만들고 아래와 같이 작성

resource "terraform_data" "copy_index" {
  depends_on = [aws_instance.public_ec2]

  count = length(var.cidr_numeral_public)

  connection {
    type = "ssh"
    user = "ec2-user"
    host = element(aws_eip.public_ec2.*.public_ip, count.index)
    private_key = tls_private_key.ec2_private_key.*.private_key_pem[0]
  }

  provisioner "remote-exec" {
    inline = [
      "while [ ! -d /var/www/html ]; do sleep 5; done",
      "echo '/var/www/html is ready'",
      "sudo chown -R ec2-user:apache /var/www/html",
      "sudo chmod -R 775 /var/www/html"
    ]
  }

  provisioner "file" {
    source = "${path.module}/index.php"
    destination = "/var/www/html/index.php"
  }
}

resource "terraform_data" "copy_key" {
  depends_on = [local_file.private_ec2_key, aws_ami_from_instance.public_ec2_ami]

  count = length(var.cidr_numeral_public)

  connection {
    type = "ssh"
    user = "ec2-user"
    host = element(aws_eip.public_ec2.*.public_ip, count.index)
    private_key = tls_private_key.ec2_private_key.*.private_key_pem[0]
  }

  provisioner "remote-exec" {
    inline = [
      "mkdir /home/ec2-user/keys"
    ]
  }

  provisioner "file" {
    source = "${path.module}/${local_file.private_ec2_key.filename}"
    destination = "/home/ec2-user/keys/${local_file.private_ec2_key.filename}"
  }

  provisioner "remote-exec" {
    inline = [
      "chmod 600 /home/ec2-user/keys/${local_file.private_ec2_key.filename}"
    ]
  }
}

• Public EC2 인스턴스는 Private EC2 인스턴스에 접속하기 위한 중개 서버 역할을 하게 되며 Public EC2 인스턴스가 Bastion host가 됨
• Bastion host는 외부 네트워크와 외부 네트워크를 연결하는 게이트웨이 역할을 함

Private Subnet에 EC2 인스턴스 생성

Key Pair 만들기

• Private EC2 인스턴스에 사용할 Key Pair 생성
• key_pair.tf 파일을 아래와 같이 변경

# Create a PEM formatted private key
resource "tls_private_key" "ec2_private_key" {
  count = 2
  algorithm = "RSA"
  rsa_bits = 4096
}

# Public ec2 key pair
resource "aws_key_pair" "public_ec2_key_pair" {
  key_name = "public_ec2_key_pair"
  public_key = tls_private_key.ec2_private_key[0].public_key_openssh
}

# Generate a local file about public ec2 key
resource "local_file" "public_ec2_key" {
  filename = "public_ec2_key_pair.pem"
  content = tls_private_key.ec2_private_key[0].private_key_pem
}

# Private ec2 key pair
resource "aws_key_pair" "private_ec2_key_pair" {
  key_name = "private_ec2_key_pair"
  public_key = tls_private_key.ec2_private_key[1].public_key_openssh
}

# Generate a local file about private ec2 key
resource "local_file" "private_ec2_key" {
  filename = "private_ec2_key_pair.pem"
  content = tls_private_key.ec2_private_key[1].private_key_pem
}

Security group 만들기

• security_group.tf 파일에 아래 내용 추가

# Security group for private ec2
resource "aws_security_group" "private_ec2_sg" {
  name = "private-ec2-sg"
  description = "Security group for private ec2 instance"
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "private-ec2-sg"
  }
}

# Inbound rule allowing SSH for private ec2
resource "aws_vpc_security_group_ingress_rule" "allow_ssh_for_private_ec2" {
  security_group_id = aws_security_group.private_ec2_sg.id
  cidr_ipv4 = "0.0.0.0/0"
  from_port = 22
  ip_protocol = "tcp"
  to_port = 22
}

# Inbound rule allowing HTTP for private ec2
resource "aws_vpc_security_group_ingress_rule" "allow_http_for_private_ec2" {
  security_group_id = aws_security_group.private_ec2_sg.id
  cidr_ipv4 = "0.0.0.0/0"
  from_port = 80
  ip_protocol = "tcp"
  to_port = 80
}

# Inbound rule allowing HTTPS for private ec2
resource "aws_vpc_security_group_ingress_rule" "allow_https_for_private_ec2" {
  security_group_id = aws_security_group.private_ec2_sg.id
  cidr_ipv4 = "0.0.0.0/0"
  from_port = 443
  ip_protocol = "tcp"
  to_port = 443
}

# Outbound rule allowing all traffic for private ec2
resource "aws_vpc_security_group_egress_rule" "allow_all_outbound_traffic_for_private_ec2" {
  security_group_id = aws_security_group.private_ec2_sg.id
  cidr_ipv4 = "0.0.0.0/0"
  ip_protocol = "-1"
}

EC2 인스턴스 만들기

• ami_from_instance.tf 파일을 아래와 같이 변경

resource "aws_ami_from_instance" "public_ec2_ami" {
  depends_on = [terraform_data.copy_index]

  name = "public-ec2-ami"
  source_instance_id = aws_instance.public_ec2.*.id[0]
  snapshot_without_reboot = false
}

• ec2.tf 파일에 아래 내용 추가

# Private ec2
resource "aws_instance" "private_ec2" {
  count = length(var.cidr_numeral_private)
  ami = aws_ami_from_instance.public_ec2_ami.id # public ec2 ami
  instance_type = "t2.micro"
  key_name = aws_key_pair.private_ec2_key_pair.key_name
  vpc_security_group_ids = [aws_security_group.private_ec2_sg.id]
  subnet_id = element(aws_subnet.private.*.id, count.index)

  tags = {
    Name = "private-ec2-${count.index}-${var.vpc_name}"
  }

  metadata_options {
    http_endpoint = "enabled"
    http_put_response_hop_limit = 1
    http_tokens = "optional"
    instance_metadata_tags = "enabled"
  }
}

NAT Gateway 생성

• Private EC2 인스턴스가 외부 네트워크와 통신하기 위해서 NAT Gateway가 필요
• NAT Gateway에 Elastic IP를 할당하기 위해 eip.tf 파일에 다음을 추가

# Elastic IP for nat gateway
resource "aws_eip" "nat_gateway" {
  count = length(var.cidr_numeral_public)
  instance = element(aws_nat_gateway.main.*.id, count.index)
  domain = "vpc"

  tags = {
    Name = "eip-nat-gateway-${count.index}"
  }
}

• NAT Gateway를 만들기 위해 nat_gateway.tf 파일을 생성하고 아래와 같이 작성

resource "aws_nat_gateway" "main" {
  count = length(var.cidr_numeral_public)
  subnet_id = element(aws_subnet.public.*.id, count.index)

  tags = {
    Name = "nat-gw-${count.index}-${var.vpc_name}"
  }
}

Private Subnet의 Route Table 수정

• Route Table에 Nat Gateway 경로 추가
• route_table.tf 파일에 아래 내용 추가

# Route for private subnets
resource "aws_route" "private_nat" {
  count = length(var.cidr_numeral_private)
  route_table_id = element(aws_route_table.private.*.id, count.index)
  destination_cidr_block = "0.0.0.0/0"
  gateway_id = aws_nat_gateway.main.id
}

• 외부로 향하는 트래픽은 Public Subnet에 생성한 NAT Gateway를 통과하게 됨

트러블슈팅

• Public EC2 인스턴스가 생성된 후에 provisioner "file"로 로컬에 있는 index.php 파일을 EC2 인스턴스에 복사할 때 발생한 문제는 다음과 같음

1. No such file or directory

• 원인: Provisioner가 실행되는 시점에 Public EC2 인스턴스가 아직 user_data 스크립트가 실행 중이어서 /var/www/html 디렉토리가 아직 생성되지 않았음
• 해결책: remote-exec Privisioner로 디렉토리가 생성될 때까지 대기하다가 디렉토리가 만들어진 것을 확인하면 파일 복사

2. Upload failed: scp: /var/www/html/index.php: Permission denied

• 원인: /var/www/html 디렉토리에 대한 쓰기 권한이 없음
• 해결책: /var/www/html 디렉토리의 소유권을 apache 그룹의 ec2-user로 변경하고 디렉토리의 권한을 775로 변경
  • 775: 소유자와 그룹 사용자는 해당 파일에 대해 읽기, 쓰기, 실행 권한을 가지며 그 외 사용자는 읽기, 실행 권한을 가짐

  provisioner "remote-exec" {
    inline = [
      "while [ ! -d /var/www/html ]; do sleep 5; done",
      "echo '/var/www/html is ready'",
      "sudo chown -R ec2-user:apache /var/www/html",
      "sudo chmod -R 775 /var/www/html"
    ]
  }

  provisioner "file" {
    source = "${path.module}/index.php"
    destination = "/var/www/html/index.php"
  }

스스로 구축하는 AWS 클라우드 인프라 - 기본편을 수강하며 AWS 인프라를 Terraform으로 작성한 내용입니다.

Target group 생성

• Load Balancer는 트래픽을 받으면 리스너를 통해 Target group으로 전달
• Target group은 Load Balancer를 통해 들어온 트래픽을 받을 대상
• target_group.tf 파일을 생성하고 아래와 같이 작성

# Target group
resource "aws_vpclattice_target_group" "main" {
  name = "alb-public-tf-${var.vpc_name}"
  type = "INSTANCE"

  config {
    vpc_identifier = aws_vpc.main.id

    port = 80
    protocol = "HTTP"
    protocol_version = "HTTP1"

    health_check {
      enabled = true
      health_check_interval_seconds = 30
      health_check_timeout_seconds = 5
      protocol = "HTTP"
      path = "/"
      healthy_threshold_count = 5
      unhealthy_threshold_count = 2
      matcher {
        value = "200"
      }
    }
  }

  tags = {
    Name = "alb-public-tf-${var.vpc_name}"
  }
}

# Register targets with Target group
resource "aws_vpclattice_target_group_attachment" "public_ec2" {
  count = length(var.cidr_numeral_private)
  target_group_identifier = aws_vpclattice_target_group.main.id

  target {
    id = element(aws_instance.public_ec2.*.id, count.index)
  }
}

• 여기서 설정하는 프로토콜과 포트는 Application Load Balancer와 타겟이 되는 EC2 인스턴스 사이의 통신에 대한 것
• EC2 인스턴스들이 지정된 프로토콜과 포트로 오는 요청만 받아들이게 됨
• Application Load Balancer는 Health Check를 통해 타겟이 되는 인스턴스의 상태가 정상적인지 지속적으로 확인

Application Load Balancer 생성

Security group 만들기

• Application Load Balancer가 타겟이 되는 인스턴스와 통신할 때 Security group이 사용됨
• security_group.tf 파일에 아래 내용 추가

# Security group for ALB
resource "aws_security_group" "alb_public_sg" {
  name = "alb-public-sg"
  description = "Security group for alb"
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "alb-public-sg"
  }
}

# Inbound rule allowing HTTP for ALB
resource "aws_vpc_security_group_ingress_rule" "allow_http_for_alb" {
  security_group_id = aws_security_group.alb_public_sg.id
  cidr_ipv4 = "0.0.0.0/0"
  from_port = 80
  ip_protocol = "tcp"
  to_port = 80
}

# Outbound rule allowing all traffic for ALB
resource "aws_vpc_security_group_egress_rule" "allow_all_outbound_traffic_for_alb" {
  security_group_id = aws_security_group.alb_public_sg.id
  cidr_ipv4 = "0.0.0.0/0"
  ip_protocol = "-1"
}

Application Load Balancer 만들기

resource "aws_lb" "alb_public" {
  name = "alb-public"
  load_balancer_type = "application"
  internal = false
  ip_address_type = "ipv4"

  # Indicate which subnet in the availability zone will receive traffic
  dynamic "subnet_mapping" {
    for_each = toset(aws_subnet.public)
    content {
      subnet_id = subnet_mapping.value.id
    }
  }

  security_groups = [aws_security_group.alb_public_sg.id]
}

resource "aws_lb_listener" "alb_public_listener" {
  load_balancer_arn = aws_lb.alb_public.arn
  port = 80
  protocol = "HTTP"

  default_action {
    type = "forward"
    target_group_arn = aws_lb_target_group.alb_public_tg.arn
  }

  tags = {
    Name = "alb-public"
  }
}

• 리스너에서 설정하는 프로토콜과 포트는 외부 또는 클라이언트와 Application Load Balancer 사이의 통신에 대한 것

스스로 구축하는 AWS 클라우드 인프라 - 기본편을 수강하며 AWS 인프라를 Terraform으로 작성한 내용입니다.

Security group 생성

• EC2 인스턴스와 EFS 사이에 트래픽이 이동할 수 있도록 Security group이 있어야 함
• EC2 인스턴스와 EFS의 마운트 타겟이 파일 시스템과 관련된 프로토콜 및 포트에 대해 통신을 허용할 수 있도록 하는 규칙이 있어야 함
• security_group.tf 파일에 아래 내용을 추가

# Security group for EFS
resource "aws_security_group" "efs_sg" {
  name = "efs-sg"
  description = "Security group for efs"
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "efs-sg"
  }
}

# Inbound rule allowing NFS
resource "aws_vpc_security_group_ingress_rule" "allow_nfs" {
  security_group_id = aws_security_group.efs_sg.id
  # Fill in below value with security group whose instance will connect to EFS
  referenced_security_group_id = aws_security_group.public_ec2_sg.id
  from_port = 2049
  ip_protocol = "tcp"
  to_port = 2049
}

# Outbound rule allowing all traffic for EFS
resource "aws_vpc_security_group_egress_rule" "allow_all_outbound_traffic_for_nfs" {
  security_group_id = aws_security_group.efs_sg.id
  cidr_ipv4 = "0.0.0.0/0"
  ip_protocol = "-1"
}

• 특정 보안 그룹에서 발생하는 트래픽을 허용하기 위해 referenced_security_group_id 지정
• 트래픽 유형은 NFS로 2049 포트 사용
• 종합하면 지정한 보안 그룹에서 나오는 NFS 트래픽을 EFS의 마운트 타겟이 허용하겠다는 의미

EFS 생성

• efs.tf 파일을 만들고 아래와 같이 작성

# EFS
resource "aws_efs_file_system" "main" {
  performance_mode = "generalPurpose"
  throughput_mode = "bursting"

  lifecycle_policy {
    transition_to_ia = "AFTER_30_DAYS"
  }

  lifecycle_policy {
    transition_to_primary_storage_class = "AFTER_1_ACCESS"
  }

  tags = {
    Name = "vpc-efs-${var.vpc_name}"
  }
}

# EFS backup policy
resource "aws_efs_backup_policy" "efs_backup_policy" {
  file_system_id = aws_efs_file_system.main.id

  backup_policy {
    status = "DISABLED"
  }
}

# EFS mount target
resource "aws_efs_mount_target" "public_subnet" {
  count = length(var.cidr_numeral_public)
  file_system_id = aws_efs_file_system.main.id
  subnet_id = element(aws_subnet.public.*.id, count.index)
  security_groups = [ aws_security_group.efs_sg.id ]
}

• EFS 파일 시스템이 마운트될 수 있도록 aws_efs_mount_target 리소스 사용

EFS를 하나의 EC2 인스턴스에 마운트

• EC2 인스턴스에 접속해서 아래 명령어를 입력하면 파일 시스템의 디스크 공간을 확인할 수 있음

df -f

• 아직 EFS가 마운트되지 않았음
• EFS를 마운트하려면 NFS 클라이언트 또는 EFS 마운트 헬퍼를 사용
  • 본 예제에서는 EFS 마운트 헬퍼를 이용
• 아래 명령어로 EFS 마운트 헬퍼 설치

sudo yum install amazon-efs-utils -y

• /var/www/html/efs를 마운트 포인트로 설정

cd     /var/www/html
mkdir efs

• AWS 콘솔에서 EFS 리소스를 찾고 연결 클릭

• EFS 마운트 헬퍼를 사용하기 위한 명령어를 복사

• EC2 인스턴스에서 명령어를 붙여넣고 실행

sudo mount -t efs -o tls fs-071eafc94bc1e05df:/ efs

• 다시 파일 시스템의 디스크 공간을 확인하면 마운트 포인트로 설정한 경로로 EFS가 마운트가 되어 있는 것을 확인할 수 있음

• 이전 예제에서 S3 버켓의 정적 웹사이트 호스팅에 사용했던 파일을 EFS로 다운로드

cd efs
sudo wget https://s3-web-hosting-chori.s3.us-east-1.amazonaws.com/car.jpg

• 웹 브라우저에서 ip 주소/efs/mycar.html로 접속하면 웹페이지가 표시됨

EFS를 또 다른 EC2 인스턴스에 마운트

• EC2 인스턴스에 접속하여 파일 시스템의 디스크 공간을 확인

• EFS 마운트 헬퍼 설치 후 마운트 포인트 설정

sudo yum install amazon-efs-utils -y
cd     /var/www/html
mkdir efs

• 마운트 헬퍼를 사용하기 위한 명령어 입력

sudo mount -t efs -o tls fs-071eafc94bc1e05df:/ efs

• efs 디렉토리로 이동하면 다른 EC2 인스턴스에서 다운로드했던 파일을 확인할 수 있음

cd efs
ls -al

• 마찬가지로 웹 브라우저에서 ip 주소/efs/mycar.html로 접속하면 웹페이지가 표시됨

EFS에 있는 파일 수정

• 하나의 EC2 인스턴스에서 mycar.html 파일을 수정

sudo vi mycar.html

• 웹 브라우저로 접속하면 웹페이지가 수정되어 있음

• 또 다른 EC2 인스턴스의 ip 주소로 접속해도 수정된 웹페이지가 반영되어 있음

• 즉, 네트워크 파일 시스템이 두 개의 EC2 인스턴스에 동시에 연결되어 있다는 것을 확인할 수 있음