Cloudnet@에서 진행하는 쿠버네티스 실무 실습 스터디를 진행하면서 작성한 글입니다. 스터디에서 사용하는 교재는 24단계 실습으로 정복하는 쿠버네티스 입니다.

Cloudnet@ 24단계 실습으로 정복하는 쿠버네티스

실습 환경 배포

# CloudFormation 스택 배포
aws cloudformation deploy \
--template-file kops-oneclick-f1.yaml \
--stack-name mykops \
--parameter-overrides KeyName=kops-key \
SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32 \
MyIamUserAccessKeyID=AKI... \
MyIamUserSecretAccessKey='o4H...' \
ClusterBaseName='imokapp.net' \
S3StateStore='imok-k8s-study' \
MasterNodeInstanceType=t3.medium \
WorkerNodeInstanceType=c5d.large \
--region ap-northeast-2

# 13분 후 작업 SSH 접속
ssh -i kops-key.pem \
ec2-user@$(aws cloudformation describe-stacks \
--stack-name mykops \
--query 'Stacks[*].Outputs[0].OutputValue' \
--output text)

kops validate cluster --wait 10m

# EC2 instance profiles 에 IAM Policy 추가(attach)
aws iam attach-role-policy --policy-arn arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy --role-name masters.$KOPS_CLUSTER_NAME
aws iam attach-role-policy --policy-arn arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy --role-name nodes.$KOPS_CLUSTER_NAME

kubectl ns default

EC2 메타데이터 호출 실습

IMDS(Instance Metadata Service)를 사용하여 실행 중인 인스턴스에서 인스턴스 메타데이터에 액세스할 수 있습니다.

AWS 인스턴스 메타데이터 검색

워커 노드 1대 EC2 메타데이터(IMDSv2) 보안 제거 및 호출 확인

kops 클러스터로 배포되는 워커 노드의 인스턴스 그룹 2개 중, 첫 번째의 인스턴스 메타데이터 설정을 삭제합니다.

메타데이터 관련 보안 정책을 제거한 후 보안에 취약해집니다.

#
kops edit ig nodes-ap-northeast-2a
---
# 아래 3줄 제거
spec:
  instanceMetadata:
    httpPutResponseHopLimit: 1
    httpTokens: required
---
# 업데이트 적용 : 노드1대 롤링업데이트
kops update cluster --yes && echo && sleep 3 && kops rolling-update cluster --yes

각각의 워커 노드에 접속해 메타데이터 사용이 가능한지 확인해 봅니다.

# 워커 노드 Public IP 확인
aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value}" --filters Name=instance-state-name,Values=running --output table

# 워커 노드 Public IP 변수 지정
W1PIP=<워커 노드 1 Public IP>
W2PIP=<워커 노드 2 Public IP>

# 워커 노드 SSH 접속
ssh -i ~/.ssh/id_rsa ubuntu@$W1PIP
ssh -i ~/.ssh/id_rsa ubuntu@$W2PIP

curl -v http://169.254.169.254/latest

kops 클러스터 기본 설정으로는 워커노드 2c는 다음과 같이 메타데이터를 호출할 수 없습니다.

보안을 제거한 워커노드 2a는 메타데이터를 호출할 수 있습니다.

POD에서 메타데이터 호출 확인

인스턴스 메타데이터 API 노드 설정은 pod까지 영향이 갑니다.

# netshoot-pod 생성
cat <<EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: netshoot-pod
spec:
  replicas: 2
  selector:
    matchLabels:
      app: netshoot-pod
  template:
    metadata:
      labels:
        app: netshoot-pod
    spec:
      containers:
      - name: netshoot-pod
        image: nicolaka/netshoot
        command: ["tail"]
        args: ["-f", "/dev/null"]
      terminationGracePeriodSeconds: 0
EOF

# 파드 이름 변수 지정
PODNAME1=$(kubectl get pod -l app=netshoot-pod -o jsonpath={.items[0].metadata.name})
PODNAME2=$(kubectl get pod -l app=netshoot-pod -o jsonpath={.items[1].metadata.name})

# EC2 메타데이터 정보 확인
kubectl exec -it $PODNAME1 -- curl 169.254.169.254 ;echo
kubectl exec -it $PODNAME2 -- curl 169.254.169.254 ;echo

Pod 2번에서는 다음과 같이 호출해도 아무것도 보이지 않습니다.

pod 1번에서는 다음과 같이 메타데이터를 호출할 수 있습니다.

또한 security-credentials 정보도 쉽게 출력할 수 있습니다.

kubectl exec -it $PODNAME1 -- curl 169.254.169.254/latest/meta-data/iam/security-credentials/nodes.$KOPS_CLUSTER_NAME | jq

🚨 이처럼 Pod가 IMDS API를 사용 가능하게 된다면, 많은 보안상 위험에 노출됩니다. pod를 해킹해 IMDS API를 사용해서 credentials 정보를 탈취해, AWS 리소스를 생성할 수도 있습니다.

쿠버네티스 보안 도구 활용

클러스터 내부에 실행 중인 모든 파드는 기본 설정으로 클러스터 내 다른 모든 파드와 통신이 가능합니다. 따라서 특정 파드가 외부 공격자에 노출되면, 같은 노드 내 다른 파드는 물론 통신 가능한 클러스터 전체의 다른 노드에서 실행 중인 모든 파드까지 영향을 끼칩니다.

쿠버네티스 보안 적용 대상 4C

각 계층 마다 각각 적절한 보안 설정을 적용해 전체적으로 안전한 시스템을 만들 필요가 있습니다.

1. 클라우드(Cloud)
2. 클러스터(Cluster)
3. 컨테이너(Container)
4. 코드(Code)

The 4C's of Cloud Native security

kubescape

미국 NSA에서 발행한 쿠버네티스 보안 체크리스트를 기준으로 현재 클러스터의 취약점을 점검하고 이를 대시보드 형태로 리포트합니다.

kubescape github

NSA/CISA 의 쿠버네티스 클러스터 보안 가이드

1. 컨테이너의 root 사용자 권한 제거
2. 컨테이너 내부 파일 시스템 쓰기 권한 제거
3. 컨테이너의 불필요한 추가 특권 제거
4. 리소스 제한 설정
5. 불필요한 외부 접속 제한을 위한 네트워크 정책 적용
6. 호스트 노드 보안 강화(SELinux 등 사용)

📝 실습 내용

1. kubescape를 설치 및 실행
2. NSA/CISA 보안 권고 사항 대비 현재 클러스터의 보안 취약점 확인

kubesacpe 설치

# 설치
curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash

kubescape version
Your current version is: v2.2.6 [git enabled in build: true]

제공하는 보안 프레임워크들을 확인해 봅니다.

# Download all artifacts and save them in the default path (~/.kubescape)
kubescape download artifacts
tree ~/.kubescape/
cat ~/.kubescape/attack-tracks.json | jq

# 제공하는 보안 프레임워크 확인
kubescape list frameworks --format json | jq '.[]'
"AllControls"
"ArmoBest"
"DevOpsBest"
"MITRE"
"NSA"
"cis-eks-t1.2.0"
"cis-v1.23-t1.0.1"

# 제공하는 통제 정책 확인
kubescape list controls

kubesacpe를 사용해서 보안 취약점을 확인해 보겠습니다.

kubescape scan --enable-host-scan --verbose
kubescape scan framework nsa -e kubesys-tem,kube-public

클러스터 보안 점검 결과 많은 보안 취약점이 발견된 것을 볼 수 있습니다. 😭

kubescape web

kubescape에서 제공하는 web을 통해 보안 취약점을 확인해 봅시다. 회원가입 후 10개의 worker노드까지 무료로 사용할 수 있습니다. https://cloud.armosec.io/

회원 가입 후 들어가면 다음과 같이 설치 명령어가 나옵니다.

Compliance

클러스터의 보안과 규정 준수를 유지하기 위해 보안 위험을 신속하게 발견, 평가 및 해결합니다.

다음과 같이 보안이 필요한 항목에 대해 확인할 수 있습니다.

Vulnerabilities

모든 클러스터에서 알려진 취약점 또는 새로운 취약점을 감지합니다.

RBAC Visualizer

RBAC 구성 상태를 시각화합니다.

polaris

보안 체크리스트 뿐만 아니라 가용성, 안정성 측면에서 모범 사례 대비 현재 매니페스트 yaml 파일의 부족한 점을 파악할 수 있습니다. 해결 방법도 다른 도구에 비해 좀 더 직관적 입니다. polaris github

📝 실습 내용

1. 헬름 차트를 이용해 redis 설치 Polaris 헬름 차트
2. 보안 점검도구 polaris를 이용해 레디스 파드의 취약점을 확인하고 이를 수정

redis 설치

인메모리 기반 데이터베이스인 레디스를 헬름 기반으로 설치합니다.

# redis 헬름 차트 설치
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm pull bitnami/redis
tar xvfz redis-17.9.3.tgz
cd redis/
cp values.yaml my-values.yaml

# 배포
k create ns redis
k ns redis
helm install redis bitnami/redis --namespace redis -f my-values.yaml

# pod 확인
k get pod

polaris 설치 및 redis 보안 취약점 확인

폴라리스를 설치해 보안 취약점을 확인합니다.

# polaris 헬름 차트 설치
helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm repo update
helm pull fairwinds-stable/polaris
tar xvfz polaris-5.7.3.tgz
cd polaris/
cp values.yaml my-values.yaml

LoadBalancer로 변경

k create ns polaris
k ns polaris

# 배포
helm install polaris fairwinds-stable/polaris --namespace polaris --version 5.7.3 -f my-values.yaml
# CLB에 ExternanDNS 로 도메인 연결
kubectl annotate service polaris-dashboard "external-dns.alpha.kubernetes.io/hostname=polaris.$KOPS_CLUSTER_NAME" -n polaris
# 웹 접속 주소 확인 및 접속
echo -e "Polaris Web URL = http://polaris.$KOPS_CLUSTER_NAME"

# pod 확인
k get pod
# 웹 서비스 포트 확인
k get svc
# 노드 ip 주소 확인
k get node -o wide

앞에서 설치한 redis 애플리케이션의 상세한 권고 사항을 확인할 수 있습니다.

❓ 버튼을 클릭하면, 해당 사항에 대하 자세한 설명을 확인할 수 있습니다.

polaris pod의 매니페스트 yaml 파일은 모범 사례로 구성돼 있기 때문에 해당 yaml 파일을 참고해서 다른 애플리케이션을 수정해 적용할 수 있습니다. 구체적인 설정을 확인하기 위해 실행 중인 polaris pod 설정을 확인해 봅니다. k get pod polaris-dashboard-78 -o yaml > polaris-dashboard-pod.yaml

해당 파일을 참고해서 redis 헬름 차트의 yaml 파일에 securityContext.allowPrivilegeEscalation 설정을 추가해봅니다.

# redis 재설치
helm upgrade redis bitnami/redis --namespace redis -f my-values.yaml

polaris 웹에서 변경 사항을 확인합니다.

Cloudnet@에서 진행하는 쿠버네티스 실무 실습 스터디를 진행하면서 작성한 글입니다. 스터디에서 사용하는 교재는 24단계 실습으로 정복하는 쿠버네티스 입니다.

Cloudnet@ 24단계 실습으로 정복하는 쿠버네티스

kwatch

kwatch helps you monitor all changes in your Kubernetes(K8s) cluster, detects crashes in your running apps in realtime, and publishes notifications to your channels (Slack, Discord, etc.) instantly

kwatch gitHub kwatch Helm

# configmap 생성
cat <<EOT > ~/kwatch-config.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: kwatch
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: kwatch
  namespace: kwatch
data:
  config.yaml: |
    alert:
      slack:
        webhook: 'https://hooks.slack.com/services/슬랙주소'
        #title:
        #text:
    pvcMonitor:
      enabled: true
      interval: 5
      threshold: 70
EOT

# 배포
kubectl apply -f kwatch-config.yaml

잘못된 이미지 파드 배포 및 확인

# 터미널1
watch kubectl get pod

# 잘못된 이미지 정보의 파드 배포
kubectl apply -f https://raw.githubusercontent.com/junghoon2/kube-books/main/ch05/nginx-error-pod.yml
kubectl get events -w

# 이미지 업데이트 방안2 : set 사용 - iamge 등 일부 리소스 값을 변경 가능!
kubectl set 
kubectl set image pod nginx-19 nginx-pod=nginx:1.19

# 삭제
kubectl delete pod nginx-19

prometheus alertmanager

프로메테우스는 장애 등의 메시지 전달 기능을 얼럿매니저로 분리해서 관리합니다. 경고 메시지가 발생하면, 이를 얼럿매니저에 푸시 이벤트로 전달하고, 얼럿메니저는 이를 그룹화, 일시 중지(silence) 등의 가공 과정을 거쳐 이메일, 슬랙 등으로 전달합니다.

프로메테우스의 임곗값 도달 시 경고 메시지를 얼럿매니저에 푸시 이벤트로 전달 -> 얼럿매니저는 이를 가공후 이메일/슬랙 등에 전달

prometheus alertmanager

워커 노드 3번 추가 링크

• 노드 추가 시 프로메테우스의 Target들이 자동으로 발견(Auto Discovery)되어서 등록이 되고, 메트릭 수집이 되는지 확인

# EC2 인스턴스 모니터링
while true; do aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --output text | sort; echo "------------------------------" ;date; sleep 1; done

# 인스턴스그룹 정보 확인
kops get ig

# 노드 추가
kops edit ig nodes-ap-northeast-2a --set spec.minSize=2 --set spec.maxSize=2

# 적용
kops update cluster --yes && echo && sleep 3 && kops rolling-update cluster

# 워커노드 증가 확인
while true; do kubectl get node; echo "------------------------------" ;date; sleep 1; done

얼럿매니저 웹 접속 & 얼럿매니저 대시보드 karma 사용

karma github

얼럿매니저 웹 접속

# ingress 도메인으로 웹 접속
echo -e "Alertmanager Web URL = https://alertmanager.$KOPS_CLUSTER_NAME"

1. Alerts 경고: 시스템 문제 시 프로메테우스가 전달한 경고 메시지 목록을 확인
2. Silences 일시 중지 : 계획 된 장애 작업 시 일정 기간 동안 경고 메시지를 받지 않을 때, 메시지별로 경고 메시지를 일시 중단 설정
3. Statue 상태 : 얼럿매니저 상세 설정 확인

얼럿매니저 대시보드 karma 컨테이너로 실행

# 실행
docker run -d -p 80:8080 -e ALERTMANAGER_URI=https://alertmanager.$KOPS_CLUSTER_NAME ghcr.io/prymitive/karma:latest

# 확인
docker ps

# karma 웹 접속 주소 확인
echo -e "karma Web URL = http://$(aws cloudformation describe-stacks --stack-name mykops --query 'Stacks[*].Outputs[0].OutputValue' --output text)"

프로메테우스 웹 Alert & 얼럿매니저 웹 karma

프로메테우스 웹 접속 후 상단 Alert 메뉴 확인

• Inactive 비활성화 : prometheusrules 중 경고가 활성화되지 않은 정상적인 상태

• Pending 지연 : 설정한 임곗값을 초과해 경고 상황이지만 경고 메시지를 전달하기까지 임곗값 시간을 초과하지 않은 상태, 이를 통해 오탐과 자동 복구된 에러 메시지를 처리
• Firing 경보 : 임곗값과 임곗값 시간을 초과해서 경보가 발생한 메시지. 해당 메시지는 얼럿매니저에 전달되어 얼럿매니저를 통해 전파됨

# 프로메테우스 룰 확인
kubectl get prometheusrules -n monitoring
kubectl get prometheusrules -n monitoring kube-prometheus-stack-kubernetes-system-controller-manager -o json | jq

# 룰 전체 확인
kubectl get prometheusrules -n monitoring -o json | more

# 메트릭 이름 확인
kubectl get prometheusrules -n monitoring -o json | grep '"record":' | sed 's/^ *//'
kubectl get prometheusrules -n monitoring -o json | grep '"record":' | sed 's/^ *//' | wc -l

# 얼럿 이름 확인
kubectl get prometheusrules -n monitoring -o json | grep '"alert":' | sed 's/^ *//'

# 얼럿 갯수 확인
kubectl get prometheusrules -n monitoring -o json | grep '"alert":' | sed 's/^ *//' | wc -l
134

얼럿매니저 대시보드 karma 웹 접속 확인

Cloudnet@에서 진행하는 쿠버네티스 실무 실습 스터디를 진행하면서 작성한 글입니다. 스터디에서 사용하는 교재는 24단계 실습으로 정복하는 쿠버네티스 입니다.

Cloudnet@ 24단계 실습으로 정복하는 쿠버네티스

PLG Stack

Promtail + Loki + Grafana 여러 파드의 로그들을 중앙 서버에 저장하고 이를 조회 grafana loki

PLG Stack

Loki

오픈소스 소프트웨어로, 쿠버네티스 환경에서 종료된 파드를 포함한 전체 파드의 로그를 중앙 시스템에서 조회할 수 있음

• Loki에 저장한 로그는 LogQL(PromQL과 유사)을 이용해 조회 할 수 있으며, 그라파나 웹이나 logcli를 이용해 조회 가능
• 기존 로그 통합 시스템과 달리 전체 로그 파일 단위로 인덱싱 하지 않고, 레이블 기반의 메타데이터만 인덱싱해서 인덱스에 소요되는 메모리 사용량이 적다.

Promtail

쿠버네티스 환경에 특화된 에이전트로서 도커, FluentD 등 다른 로그 수집 에이전트도 사용 가능

• Promtail은 데몬셋으로 실행되며 각 로그에 로그를 중앙 로키 서버에 전달

Loki & Promtail 설치

Loki 설치

# 모니터링
kubectl create ns loki
watch kubectl get pod,pvc,svc,ingress -n loki

# Repo 추가
helm repo add grafana https://grafana.github.io/helm-charts

# 파라미터 설정 파일 생성
cat <<EOT > ~/loki-values.yaml
persistence:
  enabled: true
  size: 20Gi

serviceMonitor:
  enabled: true
EOT

# 배포
helm install loki grafana/loki --version 2.16.0 -f loki-values.yaml --namespace loki

# 설치 확인 : 데몬셋, 스테이트풀셋, PVC 확인
helm list -n loki
kubectl get pod,pvc,svc,ds,sts -n loki
kubectl get-all -n loki
kubectl get servicemonitor -n loki
kubectl krew install df-pv && kubectl df-pv

# curl 테스트 용 파드 생성
kubectl delete -f ~/pkos/2/netshoot-2pods.yaml
kubectl apply -f ~/pkos/2/netshoot-2pods.yaml

# 로키 gateway 접속 확인
kubectl exec -it pod-1 -- curl -s http://loki.loki.svc:3100/api/prom/label

# (참고) 삭제 시
helm uninstall loki -n loki
kubectl delete pvc -n loki --all

Promtail 설치

# 파라미터 설정 파일 생성
cat <<EOT > ~/promtail-values.yaml
serviceMonitor:
  enabled: true
config:
  serverPort: 3101
  clients:
    - url: http://loki-headless:3100/loki/api/v1/push
#defaultVolumes:
#  - name: pods
#    hostPath:
#      path: /var/log/pods
EOT

# 배포
helm install promtail grafana/promtail --version 6.0.0 -f promtail-values.yaml --namespace loki

# (참고) 파드 로그는 /var/log/pods에 저장
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME ls /var/log/pods

# 설치 확인 : 데몬셋, 스테이트풀셋, PVC 확인
helm list -n loki
kubectl get pod,pvc,svc,ds,sts,servicemonitor -n loki
kubectl get-all -n loki

# (참고) 삭제 시
helm uninstall promtail -n loki

그라파나

그라파나 → Configuration → Data Source : 데이터 소스 추가 → Loki 클릭 →HTTP URL : http://loki-headless.loki:3100 → Save & Test

nginx 반복 접속

# 접속 주소 확인 및 접속
kubectl logs deploy/nginx -f

# 반복 접속
while true; do curl -s http://nginx2.$KOPS_CLUSTER_NAME -I | head -n 1; date; sleep 1; done

그라파나 → Explore : 상단 데이터 소스 Loki 선택 → Logfilters : Job → default/nginx 값 선택 ⇒ 우측 상단 Run query 클릭

임의의 로그 클릭 : 상세 정보 확인 - 파드 레이블, 네임스페이스, 잡 등 전체 로그 레이블 확인 가능

Loki 로그 확인 대시보드 : 15141

Cloudnet@에서 진행하는 쿠버네티스 실무 실습 스터디를 진행하면서 작성한 글입니다. 스터디에서 사용하는 교재는 24단계 실습으로 정복하는 쿠버네티스 입니다.

Cloudnet@ 24단계 실습으로 정복하는 쿠버네티스

쿠버네티스 모니터링

쿠버네티스 모니터링 솔루션으로는 프로메테우스(Prometheus), 스카우터(Scouter) 등과 같은 오픈소스 솔루션, 데이터독(DataDog), 뉴렐릭(new relic) 등의 상용 솔루션으로 분류됩니다.

쿠버네티스 환경의 모니터링 대상

1. 노드와 컨테이너 자원 사용량 모니터링
   • CPU, 메모리, 네트워크, 스토리지 등
2. 클러스터 모니터링
   • 쿠버네티스 오브젝트의 전체 수량, 종류 등 전반적인 현황과 피드 재시작, 이벤트 메시지 등, 장애와 관련된 모니터링
3. 애플리케이션 모니터링
   • 컨트롤 플레인 파드(etcd, apiserver, coredns),페이지 응답 속도, 세션 수, 데이터베이스 쿼리 응답 속도 등 사용자 체감 정보

실습 환경 배포

aws cloudformation deploy \
--template-file kops-oneclick-f1.yaml \
--stack-name mykops \
--parameter-overrides KeyName=kops-key \
SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32 \
MyIamUserAccessKeyID=AKI... \
MyIamUserSecretAccessKey='o4H...' \
ClusterBaseName='imokapp.net' \
S3StateStore='imok-k8s-study' \
MasterNodeInstanceType=c5a.2xlarge \
WorkerNodeInstanceType=c5a.2xlarge \
--region ap-northeast-2

ssh -i kops-key.pem ec2-user@$(aws cloudformation describe-stacks --stack-name mykops --query 'Stacks[*].Outputs[0].OutputValue' --output text)

kops validate cluster --wait 10m

kubectl ns default

프로메테우스

Prometheus : SoundCloud에서 만든 오픈소스 시스템 모니터링 및 경고 툴킷

• 공식문서
• prometheus-operator

Features

1. 시계열 데이터베이스(time-series database, TSDB) 사용
2. 강력한 queries PromQL 사용
3. 다양한 애플리케이션 익스포터 제공 - HAProxy, StatsD, MySQL
4. Pull 방식 - 중앙 서버가 모니터링 대상의 정보를 직접 가져오는 방식 ( <> Push 방식 - 에이전트가 중앙 서버로 모니터링 정보를 전달하는 방식 )
5. 서비스 디스커버리 - 개별 모니터링 대상을 서비스 엔드포인트로 등록해 자동으로 변경 내역 감지

Architecture

프로메테우스 설치

프로메테우스-스택 설치 : 모니터링에 필요한 여러 요소를 단일 스택으로 제공

• kube prometheus stack Helm

# 모니터링
kubectl create ns monitoring
watch kubectl get pod,pvc,svc,ingress -n monitoring

# 사용 리전의 인증서 ARN 확인
CERT_ARN=`aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text`
echo "alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN"

# 설치
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

# 파라미터 파일 생성
cat <<EOT > ~/monitor-values.yaml
alertmanager:
  ingress:
    enabled: true
    ingressClassName: alb

    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/success-codes: 200-399
      alb.ingress.kubernetes.io/group.name: "monitoring"

    hosts:
      - alertmanager.$KOPS_CLUSTER_NAME

    paths:
      - /*

grafana:
  defaultDashboardsTimezone: Asia/Seoul
  adminPassword: prom-operator

  ingress:
    enabled: true
    ingressClassName: alb

    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/success-codes: 200-399
      alb.ingress.kubernetes.io/group.name: "monitoring"

    hosts:
      - grafana.$KOPS_CLUSTER_NAME

    paths:
      - /*

prometheus:
  ingress:
    enabled: true
    ingressClassName: alb

    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/success-codes: 200-399
      alb.ingress.kubernetes.io/group.name: "monitoring"

    hosts:
      - prometheus.$KOPS_CLUSTER_NAME

    paths:
      - /*

  prometheusSpec:
    podMonitorSelectorNilUsesHelmValues: false
    serviceMonitorSelectorNilUsesHelmValues: false
    retention: 5d
    retentionSize: "10GiB"
EOT


# 배포
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack --version 45.7.1 \
--set prometheus.prometheusSpec.scrapeInterval='15s' --set prometheus.prometheusSpec.evaluationInterval='15s' \
-f monitor-values.yaml --namespace monitoring

# 확인
## alertmanager-0 : 사전에 정의한 정책 기반(예: 노드 다운, 파드 Pending 등)으로 시스템 경고 메시지를 생성 후 경보 채널(슬랙 등)로 전송
## grafana : 프로메테우스는 메트릭 정보를 저장하는 용도로 사용하며, 그라파나로 시각화 처리
## prometheus-0 : 모니터링 대상이 되는 파드는 ‘exporter’라는 별도의 사이드카 형식의 파드에서 모니터링 메트릭을 노출, pull 방식으로 가져와 내부의 시계열 데이터베이스에 저장
## node-exporter : 노드익스포터는 물리 노드에 대한 자원 사용량(네트워크, 스토리지 등 전체) 정보를 메트릭 형태로 변경하여 노출
## operator : 시스템 경고 메시지 정책(prometheus rule), 애플리케이션 모니터링 대상 추가 등의 작업을 편리하게 할수 있게 CRD 지원
## kube-state-metrics : 쿠버네티스의 클러스터의 상태(kube-state)를 메트릭으로 변환하는 파드
helm list -n monitoring
kubectl get pod,svc,ingress -n monitoring
kubectl get-all -n monitoring
kubectl get prometheus,alertmanager -n monitoring
kubectl get prometheusrule -n monitoring
kubectl get servicemonitors -n monitoring
kubectl get crd | grep monitoring

프로메테우스 기본 사용

메트릭 정보 저장

• 모니터링 대상이 되는 서비스는 일반적으로 자체 웹 서버의 /metrics 엔드포인트 경로에 다양한 메트릭 정보를 노출
  • 이후 프로메테우스는 해당 경로에 http get 방식으로 메트릭 정보를 가져와 TSDB 형식으로 저장

    # 아래 처럼 프로메테우스가 각 서비스의 9100 접속하여 메트릭 정보를 수집
    kubectl get node -owide
    kubectl get svc,ep -n monitoring kube-prometheus-stack-prometheus-node-exporter
    

마스터노드에 lynx 설치

ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME hostname ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME sudo apt install lynx -y

노드의 9100번의 /metrics 접속 시 다양한 메트릭 정보를 확인할수 있음 : 마스터 이외에 워커노드도 확인 가능

ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME lynx -dump localhost:9100/metrics

![](https://velog.velcdn.com/images/imok-_/post/9aa5f2db-5a2a-4b72-98e3-32ff34732edf/image.png)


#### 프로메테우스 도메인 접속

```bash
# ingress 확인
kubectl get ingress -n monitoring kube-prometheus-stack-prometheus
kubectl describe ingress -n monitoring kube-prometheus-stack-prometheus

# 프로메테우스 ingress 도메인으로 웹 접속
echo -e "Prometheus Web URL = https://prometheus.$KOPS_CLUSTER_NAME"

웹 상단 주요 메뉴 설명

1. 경고(Alert) : 사전에 정의한 시스템 경고 정책(Prometheus Rules)에 대한 상황
2. 그래프(Graph) : 프로메테우스 자체 검색 언어 PromQL을 이용하여 메트릭 정보를 조회 -> 단순한 그래프 형태 조회
3. 상태(Status) : 경고 메시지 정책(Rules), 모니터링 대상(Targets) 등 다양한 프로메테우스 설정 내역을 확인 > 버전(2.42.0)
4. 도움말(Help)

프로메테우스 설정 확인

메트릭을 그래프로 조회

Graph > 아래 PromQL 쿼리(전체 클러스터 노드의 CPU 사용량 합계)입력 후 조회 > Graph 확인

1- avg(rate(node_cpu_seconds_total{mode="idle"}[1m]))

그라파나

그라파나는 다양한 데이터소스를 토대로 사용자 대시보드를 제공하는 솔루션입니다. 프로메테우스 데이터, 퍼블릭 클라우드, 라즈베리파이 등과 같은 데이터 소스, 로그, 메트릭 등 다양한 데이터 형식을 지원합니다.

TSDB 데이터를 시각화 다양한 데이터 형식 지원(메트릭, 로그, 트레이스 등) 그라파나는 시각화 솔루션으로 데이터 자체를 저장하지 않음

• 그라파나 공식 문서

황금 신호(Golden-Signals)

구글이 공유한 모니터링 항목의 주요 요소

1. 지연(Latency)
   • 사용자 요청에 응답하는 소요 시간
   • 데이터베이스가 웹 서비스의 쿼리에 응답하는 데 걸리는 시간
2. 트래픽(Traffic)
   • 웹 서비스에 대한 초당 HTTP 요청 또는 페이지 로드
   • 데이터베이스, 스토리지 서비스에 대한 초당 트랜젝션
3. 오류(Errors)
   • 여러 가지 이유로 특정 요청이 실패했을 때 발생
4. 포화도(Saturation)
   • 트래픽 증가, 노드 장애 등의 상황이 발생했을 때 예비 노드에서 처리 가능한 시스템 자원 사용률
   • 주어진 리소스가 한 번에 얼마나 많이 소비되고 있는지 측정

그라파나 기본 사용

접속 정보 확인 및 로그인 : 기본 계정 admin / prom-operator

# ingress 확인
kubectl get ingress -n monitoring kube-prometheus-stack-grafana
kubectl describe ingress -n monitoring kube-prometheus-stack-grafana

# ingress 도메인으로 웹 접속
echo -e "Grafana Web URL = https://grafana.$KOPS_CLUSTER_NAME"

웹 주요 메뉴 설명

1. Search dashboards : 대시보드 검색
2. Starred : 즐겨찾기 대시보드
3. Dashboards : 대시보드 전체 목록 확인
4. Explore : 쿼리 언어 PromQL를 이용해 메트릭 정보를 그래프 형태로 탐색
5. Alerting : 경고, 에러 발생 시 사용자에게 경고를 전달
6. Configuration : 설정, 예) 데이터 소스 설정 등
7. Server admin : 사용자, 조직, 플러그인 등 설정
8. admin : admin 사용자의 개인 설정

Configuration → Data sources : 스택의 경우 자동으로 프로메테우스를 데이터 소스로 추가해둠

# 서비스 주소 확인
kubectl get svc,ep -n monitoring kube-prometheus-stack-prometheus
NAME                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/kube-prometheus-stack-prometheus   ClusterIP   100.70.252.201   <none>        9090/TCP   92m

NAME                                         ENDPOINTS          AGE
endpoints/kube-prometheus-stack-prometheus   172.30.55.6:9090   92m

해당 데이터 소스 접속 확인

# 테스트용 파드 배포
kubectl apply -f ~/pkos/2/netshoot-2pods.yaml
kubectl get pod

# 접속 확인
kubectl exec -it pod-1 -- nslookup kube-prometheus-stack-prometheus.monitoring
kubectl exec -it pod-1 -- curl -s kube-prometheus-stack-prometheus.monitoring:9090/graph -v

# 삭제
kubectl delete -f ~/pkos/2/netshoot-2pods.yaml

대시보드 사용

기본 대시보드

스택을 통해서 설치된 기본 대시보드 확인 : Dashboards → Browse

공식 대시보드 가져오기

공식 대시보드 링크 추천 대시보드

NGINX 웹서버 배포 및 애플리케이션 모니터링 설정 및 접속

서비스 모니터 동작

cluster-monitoring-with-prometheus-operator

nginx 웹 서버 helm 설치

[nginx stack Helm] (https://artifacthub.io/packages/helm/bitnami/nginx)

# help repo add
helm repo add bitnami https://charts.bitnami.com/bitnami

# 파라미터 파일 생성 : 서비스 모니터 방식으로 nginx 모니터링 대상을 등록하고, export 는 9113 포트 사용, nginx 웹서버 노출은 AWS CLB 기본 사용
cat <<EOT > ~/nginx-values.yaml
metrics:
  enabled: true

  service:
    port: 9113

  serviceMonitor:
    enabled: true
    namespace: monitoring
    interval: 10s
EOT

# 배포
helm install nginx bitnami/nginx --version 13.2.23 -f nginx-values.yaml

# CLB에 ExternanDNS 로 도메인 연결
kubectl annotate service nginx "external-dns.alpha.kubernetes.io/hostname=nginx.$KOPS_CLUSTER_NAME"

# 확인
kubectl get pod,svc,ep
kubectl get servicemonitor -n monitoring nginx
kubectl get servicemonitor -n monitoring nginx -o json | jq

# nginx 파드내에 컨테이너 갯수 확인
kubectl get pod -l app.kubernetes.io/instance=nginx
kubectl describe pod -l app.kubernetes.io/instance=nginx

# 접속 주소 확인 및 접속
echo -e "Nginx WebServer URL = http://nginx.$KOPS_CLUSTER_NAME"
curl -s http://nginx.$KOPS_CLUSTER_NAME
kubectl logs deploy/nginx -f

# 반복 접속
while true; do curl -s http://nginx.$KOPS_CLUSTER_NAME -I | head -n 1; date; sleep 1; done

프로메테우스 웹서버 확인

state > target에 nginx 서비스 모니터 추가 확인

그라파나 대시보드 추가

12708 대시보드 추가

Cloudnet@에서 진행하는 쿠버네티스 실무 실습 스터디를 진행하면서 작성한 글입니다. 스터디에서 사용하는 교재는 24단계 실습으로 정복하는 쿠버네티스 입니다.

Cloudnet@ 24단계 실습으로 정복하는 쿠버네티스

아르고시디(ArgoCD)를 활용한 깃옵스(GitOps) 시스템 구축

ArgoCD : 쿠버네티스를 위한 GitOps도구

• 공식문서 : ArgoCD

헬름 차트로 ArgoCD 설치 후 웹 로그인

Argo CD Chart

# 모니터링
kubectl create ns argocd
watch kubectl get pod,pvc,svc -n argocd

# 설치
cd
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
helm install argocd argo/argo-cd --set server.service.type=LoadBalancer --namespace argocd --version 5.19.14

# 확인
# argocd-application-controller : 실행 중인 k8s 애플리케이션의 설정과 깃 저장소의 소스 파일에 선언된 상태를 서로 비교하는 컨트롤러. 상태와 다르면 ‘OutOfSync’ 에러를 출력.
# argocd-dex-server : 외부 사용자의 LDAP 인증에 Dex 서버를 사용할 수 있음
# argocd-repo-server : 원격 깃 저장소의 소스 코드를 아르고시디 내부 캐시 서버에 저장합니다. 디렉토리 경로, 소스, 헬름 차트 등이 저장.
helm list -n argocd
kubectl get pod,pvc,svc,deploy,sts -n argocd
kubectl get-all -n argocd

kubectl get crd | grep argoproj
applications.argoproj.io              2023-03-25T20:11:47Z
applicationsets.argoproj.io           2023-03-25T20:11:47Z
appprojects.argoproj.io               2023-03-25T20:11:47Z

# CLB에 ExternanDNS 로 도메인 연결
kubectl annotate service -n argocd argocd-server "external-dns.alpha.kubernetes.io/hostname=argocd.$KOPS_CLUSTER_NAME"

# admin 계정의 암호 확인
ARGOPW=$(kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d)
echo $ARGOPW
scn...

# 웹 접속 로그인 (admin) CLB의 DNS 주소로 접속
echo -e "Argocd Web URL = https://argocd.$KOPS_CLUSTER_NAME"

argocd CLI 도구 설치

argocd cli

# 최신버전 설치
curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
install -m 555 argocd-linux-amd64 /usr/local/bin/argocd
chmod +x /usr/local/bin/argocd

# 버전 확인
argocd version --short

# Help
# argocd app : 쿠버네티스 애플리케이션 동기화 상태 확인
# argocd context : 복수의 쿠버네티스 클러스터 등록 및 선택
# argocd login : 아르고시디 서버에 로그인 
# argocd repo : 원격 깃 저장소를 등록하고 현황 파악
argocd

# argocd 서버 로그인
argocd login argocd.$KOPS_CLUSTER_NAME --username admin --password $ARGOPW

전 단계에서 설치한 깃랩의 프로젝트 URL 을 argocd 깃 리포지토리(argocd repo)로 등록. 깃랩은 프로젝트 단위로 소스 코드를 보관.

argocd repo add https://gitlab.$KOPS_CLUSTER_NAME/<깃랩 계정명>/test-stg.git --username <깃랩 계정명> --password <깃랩 계정 암호>

# 등록 확인 : 기본적으로 아르고시디가 설치된 쿠버네티스 클러스터는 타깃 클러스터로 등록됨
argocd repo list
TYPE  NAME  REPO                                          INSECURE  OCI    LFS    CREDS  STATUS      MESSAGE  PROJECT
git         https://gitlab.imokapp.net/imok/test-stg.git  false     false  false  true   Successful
(imokapp:default) [root@kops-ec2 test-stg]# argocd cluster list

# 기본적으로 아르고시디가 설치된 쿠버네티스 클러스터는 타깃 클러스터로 등록됨
argocd cluster list
SERVER                          NAME        VERSION  STATUS   MESSAGE                                                  PROJECT
https://kubernetes.default.svc  in-cluster           Unknown  Cluster has no applications and is not being monitored.

ArgoCD를 이용하여 RabbitMQ 헬름 애플리케이션 배포하기

RabbitMQ Helm 깃랩 업로드 - RabbitMQ

# test-stg 깃 디렉터리에서 아래 실행
cd ~/gitlab-test/test-stg

# 깃 원격 오리진 주소 확인
git config -l | grep remote.origin.url

# RabbitMQ 헬름 차트 설치
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm fetch bitnami/rabbitmq --untar --version 11.10.3
cd rabbitmq/
cp values.yaml my-values.yaml

# 헬름 차트를 깃랩 저장소에 업로드
git add . && git commit -m "add rabbitmq helm"
git push

# argocd CRD 확인
kubectl get crd | grep argo
applications.argoproj.io                              2023-03-25T20:11:47Z   # 배포 앱 현재 실행 상태와 깃 저장소의 의도한 상태를 계속 비교
appprojects.argoproj.io                               2023-03-25T20:11:47Z   # 프로젝트 단위 구분
argocdextensions.argoproj.io                          2023-03-25T20:11:47Z

# 수정
cd ~/
curl -s -O https://raw.githubusercontent.com/wikibook/kubepractice/main/ch15/rabbitmq-helm-argo-application.yml
vim rabbitmq-helm-argo-application.yml
--------------------------------------
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: rabbitmq-helm
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    namespace: rabbitmq
    server: https://kubernetes.default.svc
  project: default
  source:
    repoURL: https://gitlab.imokapp.net/imok/test-stg.git
    path: rabbitmq
    targetRevision: HEAD
    helm:
      valueFiles:
      - my-values.yaml
  syncPolicy:
    syncOptions:
    - CreateNamespace=true
--------------------------------------

# 모니터링 : argocd 웹 화면 보고 있기!
echo -e "Argocd Web URL = https://argocd.$KOPS_CLUSTER_NAME"

# 배포
kubectl apply -f rabbitmq-helm-argo-application.yml

# YAML 파일을 적용(apply)하여 아르고시디 ‘Application’ CRD를 생성
kubectl get applications.argoproj.io -n argocd
NAME            SYNC STATUS   HEALTH STATUS
rabbitmq-helm   OutOfSync     Missing

argocd 웹 화면 rabbitmq 클릭 > 헬름 차트 상세 내역 확인 > 화면 상단 SYNC 클릭해 동기화 실행

# 모니터링
watch kubectl get pod,pvc -n rabbitmq

# 배포 확인
kubectl get all,svc,cm -n rabbitmq

# sts 파드 1개에서 2개로 증가 설정 후 argocd 웹 화면 모니터링
kubectl scale statefulset -n rabbitmq rabbitmq-helm --replicas 2

sync 확인

실습 환경 삭제

헬름 차트 삭제

kubectl delete application -n argocd rabbitmq-helm  # 미 삭제되어 있을 경우 삭제
helm uninstall -n argocd argocd
kubectl delete ns argocd
kubectl delete ns rabbitmq

kOps 클러스터 삭제 & AWS CloudFormation 스택 삭제

kops delete cluster --yes && aws cloudformation delete-stack --stack-name mykops

Cloudnet@에서 진행하는 쿠버네티스 실무 실습 스터디를 진행하면서 작성한 글입니다. 스터디에서 사용하는 교재는 24단계 실습으로 정복하는 쿠버네티스 입니다.

Cloudnet@ 24단계 실습으로 정복하는 쿠버네티스

깃랩(GitLab)를 이용하여 로컬 깃(Git) 소스 저장소 구축하기

🎯 자신만의 텍스트 파일을 kops-ec2 로컬에서 Gitlab Repo에 올려보고, 다운로드 받아보기

헬름 차트로 gitlab 설치 후 웹 로그인

Cloud Native GitLab Helm Chart GitLab Helm chart

# 설치
echo $CERT_ARN
helm repo add gitlab https://charts.gitlab.io/
helm repo update
helm fetch gitlab/gitlab --untar --version 6.8.1
vim ~/gitlab/values.yaml
----------------------
global:
  hosts:
    domain: <각자자신의도메인>             # 52줄
    https: true

  ingress:                             # 66줄~
    configureCertmanager: false
    provider: aws
    class: alb
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
      alb.ingress.kubernetes.io/certificate-arn: ${CERT_ARN}   # 각자 자신의 값으로 수정입력
      alb.ingress.kubernetes.io/success-codes: 200-399
      alb.ingress.kubernetes.io/group.name: "gitlab"
    tls:                               # 79줄
      enabled: false
----------------------

alb.ingress.kubernetes.io/group.name: "gitlab" 을 설정하면, ALB 1대만으로 동작 가능

# 모니터링
kubectl create ns gitlab
watch kubectl get pod,pvc,ingress -n gitlab
# 설치
helm install gitlab gitlab/gitlab -f ~/gitlab/values.yaml \
--set certmanager.install=false \
--set nginx-ingress.enabled=false \
--set prometheus.install=false \
--set gitlab-runner.install=false \
--namespace gitlab --version 6.8.4

# 확인 - SubCharts
# gitlab-gitaly : 웹서비스 혹은 ssh 방식으로 진행되는 깃 제목, 브랜치, 태그 등의 깃 요청 등에 대한 작업을 담당
# gitlab-gitlab-shell : https 가 아닌 ssh 방식으로 깃 명령어 실행 시 해당 요청을 처리
# gitlab-kas : gitlab agent server
# gitlab-postgresql : 유저, 권한, 이슈 등 깃랩의 메타 데이터 정보가 저장
# gitlab-redis-master : 깃랩 작업 정보는 레디스 캐시 서버를 이용하여 처리
# gitlab-sidekiq-all-in-1-v2 : 레디스와 연동하여 작업 큐 처리 용도로 사용
# gitlab-webservice-default : 깃랩 웹 서비스를 처리
helm list -n gitlab
kubectl get pod,pvc,ingress,deploy,sts -n gitlab
kubectl df-pv -n gitlab
kubectl get-all -n gitlab

# 4개의 Ingress 가 1개의 ALB를 공유해서 사용 : ALB의 Rule 확인해볼것!
# alb.ingress.kubernetes.io/group.name: "gitlab"
kubectl get ingress -n gitlab
NAME                        CLASS   HOSTS                  ADDRESS                                                            PORTS   AGE
gitlab-kas                  alb     kas.imokapp.net        k8s-gitlab-806aafdd2a-290919404.ap-northeast-2.elb.amazonaws.com   80      8m15s
gitlab-minio                alb     minio.imokapp.net      k8s-gitlab-806aafdd2a-290919404.ap-northeast-2.elb.amazonaws.com   80      8m15s
gitlab-registry             alb     registry.imokapp.net   k8s-gitlab-806aafdd2a-290919404.ap-northeast-2.elb.amazonaws.com   80      8m15s
gitlab-webservice-default   alb     gitlab.imokapp.net     k8s-gitlab-806aafdd2a-290919404.ap-northeast-2.elb.amazonaws.com   80      8m15s

# 웹 root 계정 암호 확인
kubectl get secrets -n gitlab gitlab-gitlab-initial-root-password --template={{.data.password}} | base64 -d ;echo
hhBvAjXo...

# 웹 접속 주소 확인 및 접속
echo -e "gitlab URL = https://gitlab.$KOPS_CLUSTER_NAME"

# 웹 접속 https://gitlab.<각자 자신의 도메인> (root / 웹 root 계정 암호)

gitlab에 별도의 사용자 생성

Admins > Users

Administrator 권한 부여

Impersonation Tokens 생성 - 토큰 값 확인

password 설정 > root 계정 로그아웃 > imok 계정 로그인

깃랩 신규 프로젝트 작성

gitlab에 파일 업로드

mkdir ~/gitlab-test && cd ~/gitlab-test

# git 계정 초기화 : 토큰 및 로그인 실패 시 매번 실행해주자
git config --system --unset credential.helper
git config --global --unset credential.helper

# git 계정 정보 확인 및 global 계정 정보 입력
git config --list
git config --global user.name "<각자 자신의 Gialba 계정>"
git config --global user.email "<각자 자신의 Gialba 계정의 이메일>"

# git clone
git clone https://gitlab.$KOPS_CLUSTER_NAME/<각자 자신의 Gitlab 계정>/test-stg.git
Cloning into 'test-stg'...
Username for 'https://gitlab.imokapp.net': imok
Password for 'https://imok@gitlab.imokapp.net':<토큰 입력>

# 이동
ls -al test-stg && cd test-stg && pwd

# 파일 생성 및 깃 업로드(push) : 웹에서 확인
echo "gitlab test memo" >> test.txt
git add . && git commit -m "initial commit - add test.txt"
git push
Username for 'https://gitlab.imokapp.net': imok
Password for 'https://imok@gitlab.imokapp.net':<토큰 입력>

실습 환경 삭제

헬름 차트 삭제

helm uninstall -n gitlab gitlab
kubectl delete pvc --all -n gitlab
kubectl delete ns gitlab

kOps 클러스터 삭제 & AWS CloudFormation 스택 삭제

kops delete cluster --yes && aws cloudformation delete-stack --stack-name mykops

Cloudnet@에서 진행하는 쿠버네티스 실무 실습 스터디를 진행하면서 작성한 글입니다. 스터디에서 사용하는 교재는 24단계 실습으로 정복하는 쿠버네티스 입니다.

Cloudnet@ 24단계 실습으로 정복하는 쿠버네티스

실습 환경 배포

aws cloudformation deploy \
--template-file kops-oneclick-f1.yaml \
--stack-name mykops \
--parameter-overrides
KeyName=kops-key \
SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32  \
MyIamUserAccessKeyID=AKIA... \
MyIamUserSecretAccessKey=o4... \
ClusterBaseName='imokapp.net' \
S3StateStore='imok-k8s-study' \
MasterNodeInstanceType=c5a.2xlarge \
WorkerNodeInstanceType=c5a.2xlarge \
--region ap-northeast-2

# CloudFormation 스택 배포 완료 후 kOps EC2 IP 출력
aws cloudformation describe-stacks --stack-name mykops --query 'Stacks[*].Outputs[0].OutputValue' --output text

# SSH 접속
ssh -i kops-key.pem ec2-user@$(aws cloudformation describe-stacks --stack-name mykops --query 'Stacks[*].Outputs[0].OutputValue' --output text)

# EC2 instance profiles 에 IAM Policy 추가(attach)
aws iam attach-role-policy --policy-arn arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy --role-name masters.$KOPS_CLUSTER_NAME
aws iam attach-role-policy --policy-arn arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy --role-name nodes.$KOPS_CLUSTER_NAME

# 메트릭 서버 확인 : 메트릭은 15초 간격으로 cAdvisor를 통하여 가져옴
kubectl top node

도커 엔진 설치 확인

# default NS 진입
kubectl ns default

# 도커 설치
amazon-linux-extras install docker -y
systemctl start docker && systemctl enable docker

# 설치된 패키지 확인 : 도커 엔진 확인
yum list installed

# 도커 정보 확인 : client - server, Docker Root Dir, Registry
docker info

# 도커 정보 확인 : Docker Engine - Community
docker version

# 도커 서비스 상태 확인
systemctl status docker

# 모든 서비스의 상태 표시 - 링크
systemctl list-units --type=service

# 도커 루트 디렉터리 확인
tree -L 3 /var/lib/docker

하버(Harbor)를 이용하여 로컬 컨테이너 이미지 저장소 구축하기

🎯 Harbor 에 아무 이미지나 태그해서 업로드하고 다운로드 해보고, 파드/디플로이먼트 YAML 배포 시 해당 이미지 주소를 사용해보기

헬름 차트로 하버 설치

Helm Chart for Harbor Deploying Harbor with High Availability via Helm

# 사용 리전의 인증서 ARN 확인
aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text
CERT_ARN=`aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text`
echo "alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN"

# 하버 설치
helm repo add harbor https://helm.goharbor.io
helm fetch harbor/harbor --untar --version 1.11.0
vim ~/harbor/values.yaml
----------------------
expose.tls.certSource=none                        # 19줄
#expose.ingress.hosts.core=harbor.<각자자신의도메인>    # 36줄
#expose.ingress.hosts.notary=notary.<각자자신의도메인>  # 37줄
expose.ingress.hosts.core=harbor.imokapp.net
expose.ingress.hosts.notary=notary.imokapp.net
expose.ingress.controller=alb                      # 44줄
expose.ingress.className=alb                       # 47줄
#expose.ingress.annotations=alb.ingress.kubernetes.io/scheme: internet-facing # 51줄
#expose.ingress.annotations=alb.ingress.kubernetes.io/target-type: ip
#expose.ingress.annotations=alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
#expose.ingress.annotations=alb.ingress.kubernetes.io/certificate-arn: ${CERT_ARN}   # 각자 자신의 값으로 수정입력
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
alb.ingress.kubernetes.io/certificate-arn: ${CERT_ARN}   # 각자 자신의 값으로 수정입력
#externalURL=https://harbor.<각자자신의도메인>          # 131줄
externalURL=https://harbor.imokapp.net           
-------------------

# 모니터링
kubectl create ns harbor
watch kubectl get pod,pvc,ingress -n harbor

# 설치
helm install harbor harbor/harbor -f ~/harbor/values.yaml --namespace harbor --version 1.11.0

# 확인
# registry : 컨테이너 이미지를 저장
# chartmuseum : 하버를 컨테이너 이미지뿐 아니라, 헬름 차트 리포지토리로도 사용
# notary : 서명이 완료된 컨테이너 이미지만 운영 환경에 사용하도록 설정. 서명이 완료된 이미지는 별도로 구분
# trivy : 컨테이너 이미지의 보안 취약점을 스캔, 스캔 기능은 별도 솔루션에서 제공하여 관리자는 보안 스캔용 도구를 선택 가능
helm list -n harbor
kubectl get-all -n harbor
kubectl get pod,pvc,ingress,deploy,sts -n harbor
kubectl get ingress -n harbor harbor-ingress -o json | jq
kubectl krew install df-pv && kubectl df-pv

# 웹 접속 주소 확인 및 접속
echo -e "harbor URL = https://harbor.$KOPS_CLUSTER_NAME"

하버 웹 접속 및 로컬 이미지 업로드

• 로그인 : admin/Harbor12345
• NEW PROJECT → Name(pkos), Access Level(Public Check) ⇒ OK 클릭

# 컨테이너 이미지 가져오기
docker pull nginx && docker pull busybox && docker images

# 태그 설정
docker tag busybox harbor.$KOPS_CLUSTER_NAME/pkos/busybox:0.1
docker image ls

# 로그인 - 방안2
echo 'Harbor12345' > harborpw.txt
cat harborpw.txt | docker login harbor.$KOPS_CLUSTER_NAME -u admin --password-stdin
cat /root/.docker/config.json | jq

# 이미지 업로드
docker push harbor.$KOPS_CLUSTER_NAME/pkos/busybox:0.1

harbor 저장소 이미지를 사용하는 디플로이먼트 생성하기

쿠버네티스 YAML 파일의 컨테이너 이미지 저장소 주소를 로컬 하버로 변경

# 파드 배포
curl -s -O https://raw.githubusercontent.com/junghoon2/kube-books/main/ch13/busybox-deploy.yml
sed -i "s|harbor.myweb.io/erp|harbor.$KOPS_CLUSTER_NAME/pkos|g" busybox-deploy.yml
kubectl apply -f busybox-deploy.yml

# 확인 : 정상적으로 harbor 에서 이미지 다운로드되어 파드가 동작!
kubectl get pod

kubectl describe pod | grep Events: -A7

이미지 보안 스캔 기능 사용

컨테이너 이미지 업로드 시 자동으로 이미지 보안 스캔 기능 사용

자동 보안 스캔 설정 및 확인

• 프로젝트에 > Configuration > Automatically... 클릭 > 하단 Save 선택

# 태그 설정
docker tag nginx harbor.$KOPS_CLUSTER_NAME/pkos/nginx:0.1
docker image ls

# 이미지 업로드
docker push harbor.$KOPS_CLUSTER_NAME/pkos/nginx:0.1

harbor 웹에서 확인

• 아래 처럼 자동으로 스캔 수행됨

실습 환경 삭제

헬름 차트 삭제

helm uninstall -n harbor harbor
kubectl delete pvc --all -n harbor
kubectl delete ns harbor

kOps 클러스터 삭제 & AWS CloudFormation 스택 삭제

kops delete cluster --yes && aws cloudformation delete-stack --stack-name mykops

Cloudnet@에서 진행하는 쿠버네티스 실무 실습 스터디를 진행하면서 작성한 글입니다. 스터디에서 사용하는 교재는 24단계 실습으로 정복하는 쿠버네티스 입니다.

Cloudnet@ 24단계 실습으로 정복하는 쿠버네티스

1. AWS VPC CNI

K8S CNI(Container Network Interface)

• k8s 네트워크 환경 구성
• 다양한 플러그인 존재 : Installing Addons

AWS VPC CNI :

• 파드의 IP를 할당
• 파드의 IP 네트워크 대역과 노드(워커)의 IP 대역이 같아 직접 통신 가능
• Proposal
• VPC 와 통합 : VPC Flow logs, VPC 라우팅 정책, 보안 그룹(Security group) 사용 가능 → 아쉽지만 kOps 는 SG for Pod 미지원 - 링크
• This plugin assigns an IP address from your VPC to each pod.
• supports native VPC networking with the Amazon VPC Container Network Interface (CNI) plugin for Kubernetes.
• VPC ENI 에 미리 할당된 IP를 파드에서 사용할 수 있음

K8S CNI 플러그인(Calico)와 AWS VPC CNI의 노드와 파드 네트워크 대역 비교

K8S CNI 플러그인(Calico)와 AWS VPC CNI의 파드 간 통신 비교

네트워크 기본 정보 확인

# CNI 정보 확인
kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
amazon-k8s-cni-init:v1.12.2
amazon-k8s-cni:v1.12.2

# 노드 IP 확인
aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output table

# 파드 IP 확인
kubectl get pod -n kube-system -o=custom-columns=NAME:.metadata.name,IP:.status.podIP,STATUS:.status.phase

# 파드 이름 확인
kubectl get pod -A -o name

# 파드 갯수 확인
kubectl get pod -A -o name | wc -l
kubectl ktop

# [master node] aws vpc cni log
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME ls /var/log/aws-routed-eni

확인해보면, node와 pod의 네트워크 대역대는 172.30.0.0로 동일

master node 확인

# [master node] SSH 접속
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME

-----------------
# 툴 설치
sudo apt install -y tree jq net-tools

# CNI 정보 확인
ls /var/log/aws-routed-eni
cat /var/log/aws-routed-eni/plugin.log | jq
cat /var/log/aws-routed-eni/ipamd.log | jq

# 네트워크 정보 확인 : eniY는 pod network 네임스페이스와 veth pair
ip -br -c addr
ip -c addr
ip -c route
sudo iptables -t nat -S
sudo iptables -t nat -L -n -v

# 빠져나오기
exit
-----------------

worker node 확인

# 워커 노드 Public IP 확인
aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value}" --filters Name=instance-state-name,Values=running --output table

# 워커 노드 Public IP 변수 지정
W1PIP=<워커 노드 1 Public IP>
W2PIP=<워커 노드 2 Public IP>

# 워커 노드 SSH 접속
ssh -i ~/.ssh/id_rsa ubuntu@$W1PIP
exit
ssh -i ~/.ssh/id_rsa ubuntu@$W2PIP
exit

# [워커 노드1~2] SSH 접속 : 접속 후 아래 툴 설치 등 정보 각각 확인
ssh -i ~/.ssh/id_rsa ubuntu@$W1PIP
ssh -i ~/.ssh/id_rsa ubuntu@$W2PIP
--------------
# 툴 설치
sudo apt install -y tree jq net-tools

# CNI 정보 확인
ls /var/log/aws-routed-eni
cat /var/log/aws-routed-eni/plugin.log | jq
cat /var/log/aws-routed-eni/ipamd.log | jq

# 네트워크 정보 확인
ip -br -c addr
ip -c addr
ip -c route
sudo iptables -t nat -S
sudo iptables -t nat -L -n -v

# 빠져나오기
exit
--------------

2. 노드에서 기본 네트워크 정보 확인

worker node1 인스턴스의 네트워크 정보 확인

보조 IPv4 주소를 파드가 사용하는지 확인

테스트용 파드 생성

# [터미널1~2] 워커 노드 1~2 모니터링
ssh -i ~/.ssh/id_rsa ubuntu@$W1PIP
watch -d "ip link | egrep 'ens5|eni' ;echo;echo "[ROUTE TABLE]"; route -n | grep eni"

ssh -i ~/.ssh/id_rsa ubuntu@$W2PIP
watch -d "ip link | egrep 'ens5|eni' ;echo;echo "[ROUTE TABLE]"; route -n | grep eni"

# 테스트용 파드 netshoot-pod 생성
cat <<EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: netshoot-pod
spec:
  replicas: 2
  selector:
    matchLabels:
      app: netshoot-pod
  template:
    metadata:
      labels:
        app: netshoot-pod
    spec:
      containers:
      - name: netshoot-pod
        image: nicolaka/netshoot
        command: ["tail"]
        args: ["-f", "/dev/null"]
      terminationGracePeriodSeconds: 0
EOF

# 파드 이름 변수 지정
PODNAME1=$(kubectl get pod -l app=netshoot-pod -o jsonpath={.items[0].metadata.name})
PODNAME2=$(kubectl get pod -l app=netshoot-pod -o jsonpath={.items[1].metadata.name})

# 파드 확인
kubectl get pod -o wide
kubectl get pod -o=custom-columns=NAME:.metadata.name,IP:.status.podIP

• 파드가 생성되면, 워커 노드에 eniY@ifN 추가되고 라우팅 테이블에도 정보가 추가된다.

# 노드에서 네트워크 인터페이스 정보 확인
ip -br -c addr show
ip -c link
ip -c addr
ip route # 혹은 route -n

# 마지막 생성된 네임스페이스 정보 출력 -t net(네트워크 타입)
sudo lsns -o PID,COMMAND -t net | awk 'NR>2 {print $1}' | tail -n 1

# 마지막 생성된 네임스페이스 net PID 정보 출력 -t net(네트워크 타입)를 변수 지정
MyPID=$(sudo lsns -o PID,COMMAND -t net | awk 'NR>2 {print $1}' | tail -n 1)

# PID 정보로 파드 정보 확인
sudo nsenter -t $MyPID -n ip -c addr
sudo nsenter -t $MyPID -n ip -c route

3. Pod to Pod Communication

Life of a Pod to Pod Ping Packet

파드간 통신 테스트 및 확인

# 파드 IP 변수 지정
PODIP1=$(kubectl get pod -l app=netshoot-pod -o jsonpath={.items[0].status.podIP})
PODIP2=$(kubectl get pod -l app=netshoot-pod -o jsonpath={.items[1].status.podIP})

# 파드1 Shell 에서 파드2로 ping 테스트
kubectl exec -it $PODNAME1 -- ping -c 2 $PODIP2

# 파드2 Shell 에서 파드1로 ping 테스트
kubectl exec -it $PODNAME2 -- ping -c 2 $PODIP1

# 워커 노드 EC2 : TCPDUMP 확인 - ens6 에서 패킷 덤프 확인이 되나요?
sudo tcpdump -i any -nn icmp
sudo tcpdump -i ens5 -nn icmp
sudo tcpdump -i ens6 -nn icmp

[워커 노드1]
# routing policy database management 확인
ip rule

# routing table management 확인
ip route show table local

# 디폴트 네트워크 정보를 ens5 을 통해서 빠져나간다
ip route show table main
default via 172.30.64.1 dev ens5 proto dhcp src 172.30.85.242 metric 100
...

4. Pod to external communications

Life of a Pod to External Packet

VPC CNI 의 External source network address translation (SNAT) 설정에 따라, 외부(인터넷) 통신 시 SNAT 하거나 혹은 SNAT 없이 통신을 할 수 있다.

파드에서 외부 통신 테스트 및 확인

# 작업용 EC2 : pod-1 Shell 에서 외부로 ping
kubectl exec -it $PODNAME1 -- ping -c 1 www.google.com
kubectl exec -it $PODNAME1 -- ping -i 0.1 www.google.com

# 워커 노드 EC2 : 퍼블릭IP 확인, TCPDUMP 확인
curl -s ipinfo.io/ip ; echo
sudo tcpdump -i any -nn icmp
sudo tcpdump -i ens5 -nn icmp

# 작업용 EC2 : pod-1 Shell 에서 외부 접속 확인 - 공인IP는 어떤 주소인가?
## The right way to check the weather - 링크
kubectl exec -it $PODNAME1 -- curl -s ipinfo.io/ip ; echo
kubectl exec -it $PODNAME1 -- curl -s wttr.in/seoul
kubectl exec -it $PODNAME1 -- curl -s wttr.in/seoul?format=3
kubectl exec -it $PODNAME1 -- curl -s wttr.in/Moon
kubectl exec -it $PODNAME1 -- curl -s wttr.in/:help

# 워커 노드 EC2
ip rule
ip route show table main
sudo iptables -L -n -v -t nat
sudo iptables -t nat -S

# 파드가 외부와 통신시에는 아래 처럼 'AWS-SNAT-CHAIN-0, AWS-SNAT-CHAIN-1' 룰(rule)에 의해서 SNAT 되어서 외부와 통신!
# 뒤 IP는 eth0(ENI 첫번째)의 IP 주소이다
sudo iptables -t nat -S | grep 'A AWS-SNAT-CHAIN'

# 카운트 확인 시 AWS-SNAT-CHAIN-0, AWS-SNAT-CHAIN-1 에 매칭되어, 목적지가 172.30.0.0/16 아니고 외부 빠져나갈때 SNAT 172.30.40.153로 변경되어 나간다!
sudo iptables -t filter --zero; sudo iptables -t nat --zero; sudo iptables -t mangle --zero; sudo iptables -t raw --zero
watch -d 'sudo iptables -v --numeric --table nat --list AWS-SNAT-CHAIN-0; echo ; sudo iptables -v --numeric --table nat --list AWS-SNAT-CHAIN-1; echo ; sudo iptables -v --numeric --table nat --list KUBE-POSTROUTING'

# conntrack 확인
sudo conntrack -L -n |grep -v '169.254.169'
conntrack v1.4.5 (conntrack-tools): 23 flow entries have been shown.
tcp      6 53 TIME_WAIT src=172.30.57.192 dst=5.9.243.187 sport=55954 dport=80 src=5.9.243.187 dst=172.30.40.153 sport=80 dport=55815 [ASSURED] mark=128 use=1

다음 실습을 위해서 파드 삭제:kubectl delete deploy netshoot-pod

5. 파드 생성 갯수 제한

최대 파드 생성 갯수 : (Number of network interfaces for the instance type × (the number of IP addressess per network interface - 1)) + 2 eni-max-Pods.txt

# t3 타입의 정보(필터) 확인
aws ec2 describe-instance-types --filters Name=instance-type,Values=t3.* \
 --query "InstanceTypes[].{Type: InstanceType, MaxENI: NetworkInfo.MaximumNetworkInterfaces, IPv4addr: NetworkInfo.Ipv4AddressesPerInterface}" \
 --output table

최대 파드 생성 확인

```bash
# 워커 노드 EC2 - 모니터링
watch -d "ip link | egrep 'ens|eni'"
while true; do ip -br -c addr show && echo "--------------" ; date "+%Y-%m-%d %H:%M:%S" ; sleep 1; done

# 작업용 EC2 - 터미널1
watch -d 'kubectl get pods -o wide'

# 작업용 EC2 - 터미널2
# 디플로이먼트 생성
cat ~/pkos/2/nginx-dp.yaml | yh
**kubectl apply -f ~/pkos/2/nginx-dp.yaml**

# 파드 확인
kubectl get pod -o wide
kubectl get pod -o=custom-columns=NAME:.metadata.name,IP:.status.podIP
kubectl ktop

# 파드 증가 테스트 >> 파드 정상 생성 확인, 워커 노드에서 eth, eni 갯수 확인
kubectl scale deployment nginx-deployment --replicas=8

# 파드 증가 테스트 >> 파드 정상 생성 확인, 워커 노드에서 eth, eni 갯수 확인 >> 어떤일이 벌어졌는가?
kubectl scale deployment nginx-deployment --replicas=10

# 파드 증가 테스트 >> 파드 정상 생성 확인, 워커 노드에서 eth, eni 갯수 확인 >> 어떤일이 벌어졌는가?
**kubectl scale deployment nginx-deployment --replicas=30**

# 파드 생성 실패!
kubectl get pods | grep Pending
nginx-deployment-7fb7fd49b4-d4bk9   0/1     Pending   0          3m37s
nginx-deployment-7fb7fd49b4-qpqbm   0/1     Pending   0          3m37s
...

kubectl describe pod <Pending 파드> | grep Events: -A5
Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  45s   default-scheduler  0/3 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 2 **Too many pods**. preemption: 0/3 nodes are available: 1 Preemption is not helpful for scheduling, 2 No preemption victims found for incoming pod.

# 디플로이먼트 삭제
kubectl delete deploy nginx-deployment

6. max-pod 설정

# 파드 갯수 모니터링
watch "kubectl get pod | grep -v NAME | wc -l"

# 파드 100개 배포
kubectl apply -f ~/pkos/2/nginx-dp.yaml
kubectl scale deployment nginx-deployment --replicas=0
kubectl scale deployment nginx-deployment --replicas=10
kubectl scale deployment nginx-deployment --replicas=30
kubectl scale deployment nginx-deployment --replicas=100

# Nitro 인스턴스 유형 확인
aws ec2 describe-instance-types --filters Name=hypervisor,Values=nitro --query "InstanceTypes[*].[InstanceType]" --output text | sort | egrep 't3\.|c5\.|c5d\.'

# 노드 인스턴스 타입 확인
kubectl describe nodes | grep "node.kubernetes.io/instance-type"

# 노드 상세 정보 확인 : 노드 상세 정보의 Allocatable 에 노드별 최대 생성 가능한 pods 정보 확인 - 각각 마스터 노드, 워커 노드
kubectl describe node | grep Allocatable: -A6

# 파드 배포 확인
kubectl get pod
kubectl get pod | grep -v NAME | wc -l
kubectl get replicasets

# LimitRanges 기본 정책 확인
kubectl describe limitranges

# 수정 전 env 정보 확인
kubectl describe ds -n kube-system aws-node | grep ADDITIONAL_ENI_TAGS: -A22
kubectl describe daemonsets.apps -n kube-system aws-node | egrep 'ENABLE_PREFIX_DELEGATION|WARM_PREFIX_TARGET'

https://learnk8s.io/kubernetes-instance-calculator https://docs.google.com/spreadsheets/d/1yhkuBJBY2iO2Ax5FcbDMdWD5QLTVO6Y_kYt_VumnEtI/edit#gid=1994017257

7. Service & AWS LoadBalancer Controller

# 기본 EC2 profile 권한 확인 
aws elbv2 describe-load-balancers

# 계정 Account ID 변수 지정
ACCOUNT_ID=`aws sts get-caller-identity --query 'Account' --output text`
echo $ACCOUNT_ID

# 생성된 IAM Policy Arn 확인
aws iam list-policies --scope Local
aws iam get-policy --policy-arn arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy
aws iam get-policy --policy-arn arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy --query 

# EC2 instance profiles 이름 확인 
aws iam list-instance-profiles
aws iam list-instance-profiles --query 'InstanceProfiles[*].InstanceProfileName'

# kOps 클러스터 편집 : 아래 내용 추가
## 인증서 구성을 웹훅에 삽입할 수 있도록 cert-manager를 설치합니다. 
## Cert-manager는 쿠버네티스 클러스터 내에서 TLS인증서를 자동으로 프로비저닝 및 관리하는 오픈 소스입니다
kops edit cluster --name ${KOPS_CLUSTER_NAME}
-----
spec:
  certManager:
    enabled: true
  awsLoadBalancerController:
    enabled: true
-----

# 업데이트 적용 : 적용이 안될 경우 한번 더 아래 명령 실행
kops update cluster --yes && echo && sleep 5 && kops rolling-update cluster

# aws-load-balancer-controller 파드 확인 : 서비스 정상 상태로 변경까지 대략 2분 30초 정도 소요
watch kubectl get pod -A

# 버전 확인 : v2.4.3
kubectl describe deploy -n kube-system aws-load-balancer-controller | grep Image | cut -d "/" -f 2

# crds 확인
kubectl get crd

서비스/파드 배포 테스트 with NLB

# 작업용 EC2 - 디플로이먼트 & 서비스 생성
cat ~/pkos/2/echo-service-nlb.yaml | yh
kubectl apply -f ~/pkos/2/echo-service-nlb.yaml

# 확인
kubectl get deploy,pod
kubectl get crd
kubectl get svc,ep,ingressclassparams,targetgroupbindings
kubectl get targetgroupbindings -o json | jq

# AWS ELB(NLB) 정보 확인
aws elbv2 describe-load-balancers | jq
aws elbv2 describe-load-balancers --query 'LoadBalancers[*].State.Code' --output text

# 웹 접속 주소 확인
kubectl get svc svc-nlb-ip-type -o jsonpath={.status.loadBalancer.ingress[0].hostname} | awk '{ print "Pod Web URL = http://"$1 }'

------------------------------
# CLB에 ExternanDNS 로 도메인 연결
kubectl annotate service svc-nlb-ip-type "external-dns.alpha.kubernetes.io/hostname=nginx.$KOPS_CLUSTER_NAME"

# 확인
dig +short nginx.$KOPS_CLUSTER_NAME
kubectl logs -n kube-system -l k8s-app=external-dns

# 웹 접속 주소 확인 및 접속
echo -e "Nginx Web URL = http://nginx.$KOPS_CLUSTER_NAME"
------------------------------

# 파드 로깅 모니터링
kubectl logs -l app=deploy-websrv -f

# 분산 접속 확인
NLB=$(kubectl get svc svc-nlb-ip-type -o jsonpath={.status.loadBalancer.ingress[0].hostname})
curl -s $NLB
for i in {1..100}; do curl -s $NLB | grep Hostname ; done | sort | uniq -c | sort -nr
  52 Hostname: deploy-echo-55456fc798-2w65p
  48 Hostname: deploy-echo-55456fc798-cxl7z

# 지속적인 접속 시도 : 아래 상세 동작 확인 시 유용(패킷 덤프 등)
while true; do curl -s --connect-timeout 1 $NLB | egrep 'Hostname|client_address'; echo "----------" ; date "+%Y-%m-%d %H:%M:%S" ; sleep 1; done

파드 2개 → 1개 → 3개 설정 시 동작

자동으로 반영 가능! => AWS와 k8s의 role

# 작업용 EC2 - 파드 1개 설정 
kubectl scale deployment deploy-echo --replicas=1

# 확인
kubectl get deploy,pod,svc,ep
curl -s nginx.$KOPS_CLUSTER_NAME
curl -s $NLB
for i in {1..100}; do curl -s --connect-timeout 1 nginx.$KOPS_CLUSTER_NAME | grep Hostname ; done | sort | uniq -c | sort -nr
for i in {1..100}; do curl -s --connect-timeout 1 $NLB | grep Hostname ; done | sort | uniq -c | sort -nr


# 작업용 EC2 - 파드 3개 설정 
kubectl scale deployment deploy-echo --replicas=3

# 확인
kubectl get deploy,pod,svc,ep
curl -s nginx.$KOPS_CLUSTER_NAME
curl -s $NLB
for i in {1..100}; do curl -s --connect-timeout 1 nginx.$KOPS_CLUSTER_NAME | grep Hostname ; done | sort | uniq -c | sort -nr
for i in {1..100}; do curl -s --connect-timeout 1 $NLB | grep Hostname ; done | sort | uniq -c | sort -nr

# [AWS LB Ctrl] 클러스터 롤 바인딩 정보 확인
kubectl describe clusterrolebindings.rbac.authorization.k8s.io aws-load-balancer-controller-rolebinding

# [AWS LB Ctrl] 클러스터롤 확인 
kubectl describe clusterroles.rbac.authorization.k8s.io aws-load-balancer-controller-role

8. Ingress

클러스터 내부의 서비스(ClusterIP, NodePort, Loadbalancer)를 외부로 노출(HTTP/HTTPS) - Web Proxy 역할

서비스/파드 배포 테스트 with Ingress(ALB)

# 게임 파드와 Service, Ingress 배포
cat ~/pkos/3/ingress1.yaml | yh
kubectl apply -f ~/pkos/3/ingress1.yaml

# 생성 확인
kubectl get-all -n game-2048
kubectl get ingress,svc,ep,pod -n game-2048
kubectl get targetgroupbindings -n game-2048
NAME                               SERVICE-NAME   SERVICE-PORT   TARGET-TYPE   AGE
k8s-game2048-service2-e48050abac   service-2048   80             ip            87s

# Ingress 확인
kubectl describe ingress -n game-2048 ingress-2048

# 게임 접속 : ALB 주소로 웹 접속
kubectl get ingress -n game-2048 ingress-2048 -o jsonpath={.status.loadBalancer.ingress[0].hostname} | awk '{ print "Game URL = http://"$1 }'
kubectl get logs -n game-2048 -l app=game-2048

# 파드 IP 확인
kubectl get pod -n game-2048 -owide
NAME                               READY   STATUS    RESTARTS   AGE   IP              NODE                  NOMINATED NODE   READINESS GATES
deployment-2048-6bc9fd6bf5-7f4mr   1/1     Running   0          72s   172.30.53.54    i-000e0b051c37cf359   <none>           <none>
deployment-2048-6bc9fd6bf5-g4h4f   1/1     Running   0          72s   172.30.95.128   i-0a5c718b3b0a7996b   <none>           <none>

도전 과제

AWS Load Balancer Controller 참고

AWS_ACM_ARN=`aws acm list-certificates --query 'CertificateSummaryList[1].CertificateArn' --output text`

k apply -f imok-games.yaml
k get ingress,svc,ep,pod -n game

k delete -f imok-games.yaml

# imok-games.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: game
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: game
  name: tetris
  labels:
    app: tetris
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tetris
  template:
    metadata:
      labels:
        app: tetris
    spec:
      containers:
      - name: tetris
        image: bsord/tetris
---
apiVersion: v1
kind: Service
metadata:
  namespace: game
  name: tetris
  annotations:
     alb.ingress.kubernetes.io/healthcheck-path: /tetris/index.html
spec:
  selector:
    app: tetris
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: game
  name: mario
  labels:
    app: mario
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mario
  template:
    metadata:
      labels:
        app: mario
    spec:
      containers:
      - name: mario
        image: pengbai/docker-supermario
---
apiVersion: v1
kind: Service
metadata:
  namespace: game
  name: mario
  annotations:
    alb.ingress.kubernetes.io/healthcheck-path: /mario/index.html
spec:
  selector:
    app: mario
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  type: NodePort
  externalTrafficPolicy: Local
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: game
  name: ingress-game-imok
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/certificate-arn: ${AWS_ACM_ARN}
    alb.ingress.kubernetes.io/healthcheck-port: traffic-port
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    alb.ingress.kubernetes.io/ssl-redirect: '443'
spec:
  ingressClassName: alb
  rules:
    - host: albweb.imokapp.net
      http:
          paths:
          - path: /tetris
            pathType: Prefix
            backend:
              service:
                name: tetris
                port:
                  number: 80
          - path: /mario
            pathType: Prefix
            backend:
              service:
                name: mario
                port:
                  number: 80

Cloudnet@에서 진행하는 쿠버네티스 실무 실습 스터디를 진행하면서 작성한 글입니다. 스터디에서 사용하는 교재는 24단계 실습으로 정복하는 쿠버네티스 입니다.

Cloudnet@ 24단계 실습으로 정복하는 쿠버네티스

실습 환경 배포

1. CloudFormation 스택 배포

   # YAML 파일 다운로드
   curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/kops-oneclick-f1.yaml
   

CloudFormation 스택 배포

aws cloudformation deploy --template-file kops-oneclick-f1.yaml --stack-name mykops --parameter-overrides KeyName=kops-key SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32 MyIamUserAccessKeyID='[본인 AccessKey입력]' MyIamUserSecretAccessKey='[본인 SecretAccessKey 입력]' ClusterBaseName='imokapp.net' S3StateStore='imok-k8s-s3' MasterNodeInstanceType=t3.medium WorkerNodeInstanceType=c5d.large --region ap-northeast-2

CloudFormation 스택 배포 완료 후 kOps EC2 IP 출력

aws cloudformation describe-stacks --stack-name mykops --query 'Stacks[*].Outputs[0].OutputValue' --output text

SSH 접속

ssh -i kops-key.pem ec2-user@$(aws cloudformation describe-stacks --stack-name mykops --query 'Stacks[*].Outputs[0].OutputValue' --output text)

2. EC2 접속 > IAM Role에 정책 추가
```bash
# AWSLoadBalancerController IAM 정책 생성 : 이미 정책이 있다면 Skip~
curl -o iam_policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.4.5/docs/install/iam_policy.json
aws iam create-policy --policy-name AWSLoadBalancerControllerIAMPolicy --policy-document file://iam_policy.json

# EC2 instance profiles 에 IAM Policy 추가(attach)
aws iam attach-role-policy --policy-arn arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy --role-name masters.$KOPS_CLUSTER_NAME
aws iam attach-role-policy --policy-arn arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy --role-name nodes.$KOPS_CLUSTER_NAME

3. IAM Role 확인

4. kops validate cluster --wait 10m 명령어로 ready 될 때까지 확인

5. 메트릭 서버 확인

# 메트릭 서버 확인 : 메트릭은 15초 간격으로 cAdvisor를 통하여 가져옴
kubectl top node
kubectl top pod -A

# (옵션) LimitRanges 기본 정책 삭제
kubectl describe limitranges # LimitRanges 기본 정책 확인 : 컨테이너는 기본적으로 0.1CPU(=100m vcpu)를 최소 보장(개런티)
kubectl delete limitranges limits
kubectl get limitranges

Cloudnet@에서 진행하는 쿠버네티스 실무 실습 스터디를 진행하면서 작성한 글입니다. 스터디에서 사용하는 교재는 24단계 실습으로 정복하는 쿠버네티스 입니다.

Cloudnet@ 24단계 실습으로 정복하는 쿠버네티스

사전 준비

Route53 도메인 구매

kOps

Kubernetes Operations (kOps) - Production Grade k8s Installation, Upgrades and Management

실습 과정

1. k8s 를 배포할 수 있는 kops 가 설치된 ec2 를 cloudformation 로 생성

2. kops 로 k8s 클러스터를 생성 : s3 에 k8s 설정 파일 저장

3. 버전 : k8s v1.24.10, OS Ubuntu 20.04 LTS

4. kops-ec2 역할 : kOps 배포 수행, kubectl 명령 실행 등

5. 마스터 노드와 워커 노드 : EC2 Auto Scaling Group(=ASG) 설정으로 구성

6. 도메인은 퍼블릭 도메인 사용

AWS kOps 설치

💡 AWS kOps 클러스터 설치 후 정보 확인하기 kops get cluster , kops get instances

1. 기본 인프라 배포

1. key pair 생성

2. AWS CloudFormation 스택 구성 AWS CloudFormation 링크

• create stack

• key, ami, ip 설정

• 스택 구성 완료

• kops-ec2 접속 확인

2. kOps 클러스터 배포 및 확인

위에서 생성된 EC2 접속 후 실행

1. 설치된 기본 툴 확인

• kubectl 버전 확인 : kubectl version --client=true -o yaml | yh

• kops 버전 확인 : kops version

• aws cli 버전 확인 : aws --version

• 개인 키와 공개키 확인 : ls /root/.ssh/id_rsa*

2. IAM User 자격 구성

실습의 편의를 위해 administrator 권한을 가진 IAM User 생성

• 자격 구성

  $aws configure
  AWS Access Key ID [None]: AKIA5...
  AWS Secret Access Key [None]: CVNa2...
  Default region name [None]: ap-northeast-2
  Default output format [None]: json

• 자격 구성 적용 확인

aws ec2 describe-instances

3. 배포

• S3 버킷 생성

# aws cli 페이지 출력 옵션
export AWS_PAGER=""

# 리소스를 배치할 리전이름을 변수 지정
REGION=ap-northeast-2  # 서울 리전 사용

# k8s 설정 파일이 저장될 버킷 생성
aws s3 mb s3://버킷<유일한 이름> --region $REGION

aws s3 ls

• 배포

export AWS_PAGER=""
export REGION=ap-northeast-2
export KOPS_CLUSTER_NAME=<자신의 퍼블릭 호스팅 메인 주소>
export KOPS_STATE_STORE=<s3://(위에서 생성한 자신의 버킷 이름)>

echo 'export AWS_PAGER=""' >>~/.bashrc
echo 'export REGION=ap-northeast-2' >>~/.bashrc
echo 'export KOPS_CLUSTER_NAME=<자신의 퍼블릭 호스팅 메인 주소>' >>~/.bashrc
echo 'export KOPS_STATE_STORE=<s3://(위에서 생성한 자신의 버킷 이름)>' >>~/.bashrc

• EC2 생성 모니터링

while true; do aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text ; echo "------------------------------" ; sleep 1; done

kops create cluster --zones="$REGION"a,"$REGION"c --networking amazonvpc --cloud aws \
--master-size t3.medium --node-size t3.medium --node-count=2 --network-cidr 172.30.0.0/16 \
--ssh-public-key ~/.ssh/id_rsa.pub --name=$KOPS_CLUSTER_NAME --kubernetes-version "1.24.10" -y

• 확인

kops validate cluster --wait 10m

4. AWS Route53 도메인 정보 확인

• A 레코드 등록된 ip는 처음에 기본 203.0.113.123이고, 배포가 완료되면 ec2 ip로 변경

• dig +short api.imokapp.net 명령어로 바뀐 ip 확인

# 자신의 도메인 변수 지정 : 소유하고 있는 자신의 도메인을 입력하시면 됩니다
MyDomain=<자신의 도메인>

# 자신의 Route 53 도메인 ID 조회 및 변수 지정
aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." | jq
aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Name"
aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text
MyDnzHostedZoneId=`aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text`
echo $MyDnzHostedZoneId

# A 레코드 타입 조회
aws route53 list-resource-record-sets --hosted-zone-id "${MyDnzHostedZoneId}" --query "ResourceRecordSets[?Type == 'A']" | jq
aws route53 list-resource-record-sets --hosted-zone-id "${MyDnzHostedZoneId}" --query "ResourceRecordSets[?Type == 'A'].Name" | jq
aws route53 list-resource-record-sets --hosted-zone-id "${MyDnzHostedZoneId}" --query "ResourceRecordSets[?Type == 'A'].Name" --output text

# A 레코드 값 반복 조회
while true; do aws route53 list-resource-record-sets --hosted-zone-id "${MyDnzHostedZoneId}" --query "ResourceRecordSets[?Type == 'A']" | jq ; date ; echo ; sleep 1; done

5. kOps 설치 확인

# 노드 IP 확인
aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output table

# 파드 IP 확인
kubectl get pod -n kube-system -o=custom-columns=NAME:.metadata.name,IP:.status.podIP,STATUS:.status.phase

# kops 클러스터 정보 확인
$kops get cluster
NAME        CLOUD    ZONES
imokapp.net    aws    ap-northeast-2a,ap-northeast-2c

kops get cluster -o yaml
kops get cluster -o yaml | yh
...

# 인스턴스그룹 정보 확인
kops get ig

kops get ig -o yaml
kops get ig -o yaml | yh
...

# 인스턴스 정보 확인
kops get instances
kops get instances -o yaml | yh
...

6. 세부 정보 확인

# 클러스터 정보 확인
kubectl cluster-info
kubectl cluster-info dump

# 노드 정보 확인 : 사용자 인증 정보
kubectl get nodes -v6
...

# CRI 컨테이너 런타임
kubectl get nodes -o wide

# 배포 완료 후 정보 확인
tree -L 1 ~/.kube
cat .kube/config
cat .kube/config | yh

# volume(sc)
kubectl get sc

kubectl get sc kops-csi-1-21 -o jsonpath={.parameters} ;echo
{"encrypted":"true","type":"gp3"}

kubectl get sc kops-ssd-1-17 -o jsonpath={.parameters} ;echo
{"encrypted":"true","type":"gp2"}

# [master node] aws vpc cni log
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME ls /var/log/aws-routed-eni
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME cat /var/log/aws-routed-eni/plugin.log | jq
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME cat /var/log/aws-routed-eni/ipamd.log | jq

# pod ip 확인
kubectl get pod -n kube-system
kubectl get pod -n kube-system -owide

# [master node] iptables rules
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME sudo iptables -t nat -S

# [master node] 컨테이너 정보 확인
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME ps axf |grep /usr/bin/containerd
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME ps afxuwww

# [master node] tree 툴 설치
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME sudo apt install -y tree jq

# [master node] Static 파드 정보 확인
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME tree /etc/kubernetes/manifests/
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME cat /etc/kubernetes/manifests/kube-apiserver.manifest
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME cat /etc/kubernetes/manifests/kube-controller-manager.manifest
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME cat /etc/kubernetes/manifests/kube-proxy.manifest
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME cat /etc/kubernetes/manifests/kube-scheduler.manifest

# [master node] 볼륨/마운트 확인 : nvme1n1 과 nvme2n1 은 etcd-events, etcd-main 으로 사용
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME lsblk
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME df -hT --type=ext4

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/root      ext4   62G  5.6G   57G   9% /
/dev/nvme1n1   ext4   20G  126M   20G   1% /mnt/master-vol-08d1c4acf0650414b
/dev/nvme2n1   ext4   20G  123M   20G   1% /mnt/master-vol-0cc3c6878de9f5263

# [master node] nvme1n1,nvme1n2 디렉터리 확인
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME tree /mnt/master-vol-03072035bffdd8252
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME tree /mnt/master-vol-0db4765644c7d6ecb

# [master node] kubelet 상태 확인
ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME systemctl status kubelet

• master node에 SSH 접속 후 확인

ssh -i ~/.ssh/id_rsa ubuntu@api.$KOPS_CLUSTER_NAME

# [master node] EC2 메타데이터 확인 : IAM Role - 링크
TOKEN=`curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
echo $TOKEN

curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/meta-data/iam/security-credentials/masters.imokapp.net | jq

• 워커 노드에 SSH 접속 후 확인 : 워커 노드의 public ip 로 SSH 접속

# 워커 노드 Public IP 확인
aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value}" --filters Name=instance-state-name,Values=running --output table

# 워커 노드 Public IP 변수 지정
W1PIP=<워커 노드 1 Public IP>
W2PIP=<워커 노드 2 Public IP>
W1PIP=3.35.50.183
W2PIP=54.180.118.11

# 워커 노드 SSH 접속
ssh -i ~/.ssh/id_rsa ubuntu@$W1PIP
exit
ssh -i ~/.ssh/id_rsa ubuntu@$W2PIP
exit

# 워커 노드 스토리지 확인
ssh -i ~/.ssh/id_rsa ubuntu@$W1PIP lsblk
ssh -i ~/.ssh/id_rsa ubuntu@$W2PIP lsblk
ssh -i ~/.ssh/id_rsa ubuntu@$W1PIP df -hT -t ext4
ssh -i ~/.ssh/id_rsa ubuntu@$W2PIP df -hT -t ext4

# 워커 노드 SSH 접속 후 node EC2 메타데이터 확인 : IAM Role - 링크
ssh -i ~/.ssh/id_rsa ubuntu@$W1PIP
ssh -i ~/.ssh/id_rsa ubuntu@$W2PIP

TOKEN=`curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
echo $TOKEN
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/meta-data/iam/security-credentials/nodes.imokapp.net | jq

3. 관리 편의성

1. 자동 완성 및 alias 축약 설정

source <(kubectl completion bash)
echo 'source <(kubectl completion bash)' >> ~/.bashrc
echo 'alias k=kubectl' >> ~/.bashrc
echo 'complete -F __start_kubectl k' >> ~/.bashrc

2. kubectl cli 플러그인 매니저 쿠버네티스 크루(krew) 설치

# 설치
$curl -fsSLO https://github.com/kubernetes-sigs/krew/releases/download/v0.4.3/krew-linux_amd64.tar.gz
$tar zxvf krew-linux_amd64.tar.gz
$./krew-linux_amd64 install krew
$tree -L 3 /root/.krew/bin

# PATH 추가
export PATH="${PATH}:/root/.krew/bin"
echo 'export PATH="${PATH}:/root/.krew/bin"' >>~/.bashrc

# krew 확인
kubectl krew
kubectl krew update
kubectl krew search
kubectl krew list
kubectl krew

3. krew 로 kube-ctx, kube-ns 설치 및 사용

• kube-ctx : 쿠버네티스 컨텍스트 사용

# 설치
kubectl krew install ctx

# 컨텍스트 확인
kubectl ctx

# 컨텍스트 사용 
kubectl ctx <각자 자신의 컨텍스트 이름>

• kube-ns : 네임스페이스(단일 클러스터 내에서 가상 클러스터) 사용

# 설치
kubectl krew install ns

# 네임스페이스 확인
kubectl ns

# 터미널1
watch kubectl get pod

# kube-system 네임스페이스 선택 사용
kubectl ns kube-system

# default 네임스페이스 선택 사용
kubectl ns -
혹은
kubectl ns default

• krew list 확인

kubectl krew list

4. krew 로 기타 플러그인 설치 및 사용 : df-pv get-all ktop neat oomd view-secret

# 설치
kubectl krew install df-pv get-all ktop neat oomd view-secret # mtail tree

# get-all 사용
kubectl get-all
kubectl get-all -n kube-system

# ktop 사용
kubectl ktop

# oomd 사용
kubectl oomd

# df-pv 사용
kubectl df-pv

# view-secret 사용 : 시크릿 복호화
kubectl view-secret

5. kube-ps1 설치 및 사용

# 설치 및 설정
git clone https://github.com/jonmosco/kube-ps1.git /root/kube-ps1

cat <<"EOT" >> /root/.bash_profile
source /root/kube-ps1/kube-ps1.sh
KUBE_PS1_SYMBOL_ENABLE=true
function get_cluster_short() {
  echo "$1" | cut -d . -f1
}
KUBE_PS1_CLUSTER_FUNCTION=get_cluster_short
KUBE_PS1_SUFFIX=') '
PS1='$(kube_ps1)'$PS1
EOT

# 적용
exit
exit

# default 네임스페이스 선택
kubectl ns default

서비스/파드 배포 테스트 with CLB

• 마리오 게임 🎮

# 수퍼마리오 디플로이먼트 배포
$curl -s -O https://raw.githubusercontent.com/euneun316/k8s-study/main/1/mario.yaml
$kubectl apply -f mario.yaml
cat mario.yaml | yh

# 배포 확인 : CLB 배포 확인 >> 5분 이상 소요
kubectl get deploy,svc,ep mario
watch kubectl get svc mario

# 마리오 게임 접속 : CLB 주소로 웹 접속
kubectl get svc mario -o jsonpath={.status.loadBalancer.ingress[0].hostname} | awk '{ print "Maria URL = http://"$1 }'

실습 환경 삭제

🚨 실습 완료 후 실습 리소스 삭제 필요

• kOps 클러스터 삭제: kops delete cluster --yes
• (클러스터 삭제 완료 확인 후) AWS CloudFormation 스택 삭제 : aws cloudformation delete-stack --stack-name mykops

🚨 kOps 설치 중간에 실패 시 삭제 방법

1. EC2 Auto Scaling 그룹 : 3개 삭제
2. EC2 시작 템플릿 Launch Templates : 3개 삭제
3. S3 버킷 비우기
4. Route53에 추가된 A 레코드 3개 삭제
5. CloudFormation 삭제

1. Route53 검색 > Registered domains > Register domain

2. 도메인 이름 검색 > 선택 > 기간 선택

3. 등록자 정보 입력

4. 등록자 정보 확인 및 주문

5. Pending requests 확인

6. Hosted zones 확인

7. 이메일 확인

8. 정상 등록 확인

지난번 'terraform으로 간단한 인프라 구축하기'에 대한 내용을 작성했습니다. Terraform 기본 인프라 구축하기

비슷한 인프라 구축 요구 사항이 들어왔을 때는 해당 코드를 활용하기 좋았지만, 조금이라도 새로운 리소스 구성이 필요하면 코드의 재사용이 어렵다는 것을 느꼈습니다.

또한 비슷한 환경을 생성할 때 마다 terraform의 .tf 파일을 복사해 계속 새로운 파일을 만들어 내는 점이 비효율적이라 생각되었습니다.

💡 따라서 공통으로 사용하는 리소스를 만들어 코드를 재사용하기 위해 terraform module을 사용하고, 팀원들과 동일 코드을 다른 환경에서 사용하기 위해 terraform workspace를 도입하기로 했습니다.

⚠️ 본 내용은 Terraform스터디를 진행하며 현업에 적용 해 본 내용을 기재하였기 때문에, AWS 및 Terraform의 기본 개념에 대해서는 생략하였습니다.

인프라 구축 전 체크 사항

지난번 사원 👶🏻 OK는 terraform으로 기본 인프라 구성을 완료했습니다. 하지만 코드의 재사용에 있어 몇 가지 불편한 점이 있었고, 규모가 커질수록 단순한 방식으로 처리가 힘들어졌습니다. 또한 추가로 팀원들과 공동 작업을 하기 위해, 다음과 같이 코드를 개선하기로 했습니다.

인프라 개선 필요 사항 체크 ✅

1. terraform의 count 매개변수의 제약 사항

   • 전체 리소스를 반복할 수는 있지만 리소스 내에서 인라인 블록을 반복할 수는 없음

   • 리소스가 배열의 형식으로 생성되기 때문에, 어떤 리소스가 생성되는지 명확히 알 수 없어, 수정 시 에러 발생 가능성이 높음

     ** ➡️ for_each 표현식으로 변경**

2. 구성 환경의 중복된 코드

   • 개발(Dev)과 운영(Prod) 환경은 일부 속성만 다르기 때문에 코드에 중복된 내용이 상당히 많았음

   ** ➡️ terraform module과 terraform workspace를 활용하는 방식으로 코드 변경 **

3. 규모가 커짐에 따라 필요한 리소스들(EC2, S3, DynamoDB 등)이 증가해, root 경로에서 파일 이름만으로 분리된 소스를 관리하는 것이 불편해짐

   ** ➡️ 폴더별로 리소스를 구분하고, root 경로에서 리소스별 모듈을 사용하는 코드로 변경**

4. Bastion Host를 통한 Tunneling 접속 방식의 불편함

   ** ➡️ Private Server에 직접 접속할 수 있는 AWS Systems Manager(AWS SSM) 구성**

구축 내용 ✅

👶🏻 OK는 개선이 필요한 사항을 확인하고, Terraform 구성 전에 미리 구축 내용을 작성했습니다.

1. VPC(Virtual Private Cloud) 다양한 네트워크 환경 구성

   • IP 대역 : 10.60.0.0/16
   • Internet Gateway
   • NAT gateways
   • Route tables

2. Subnet 구성 Public 환경과 Private 환경 구분

   • Region : ap-northeast-2 [Asia Pacific (Seoul)]

     Env	AZ	Subnet	IPv4 CIDR
     Public	ap-northeast-2a	T101-pub-sub-2a	10.60.0.0/24
     Public	ap-northeast-2c	T101-pub-sub-2c	10.60.1.0/24
     Private	ap-northeast-2a	T101-pri-sub-2a	10.60.2.0/24
     Private	ap-northeast-2c	T101-pri-sub-2c	10.60.3.0/24

3. SG(Security Group) 보안그룹은 언제든 확장할 수 있게 구성

   • EC2 접속을 위한 On-Premise의 IP Inbound Source 정보 (IP는 보안을 위해 임의로 생성했습니다.)

     CIDR	Port	Desc
     151.149.23.124/32	22	From Imok SSH(random test ip)
     151.149.23.124/32	25	From Imok SMTP(random test ip)
     151.149.23.124/32	80	From Imok HTTP(random test ip)

4. EC2 다양한 환경에서 EC2 접속할 수 있게 구성

   • Public EC2 : pem key를 이용한 ssh 접속

   • Private EC2 : AWS SSM을 이용해 접속

   • OS : Amazon Linux 2

     용도	Name	CPU	Memory	Disk	Type
     public-server	T101-public-server	2	1GiB	30GiB	t3.micro
     private-server	T101-private-server	2	1GiB	3oGiB	r5.micro

5. IAM(Identity and Access Management) SSM 사용 및 S3 접근을 위해 Private EC2에 IAM role 적용

   • AWS SSM Policy : AmazonSSMManagedInstanceCore
   • Amazon S3 Policy : AmazonS3FullAccess

구축 예상 아키텍처 ✅

👶🏻 OK는 다음과 같이 구축하게 될 예상 아키텍처를 그려봤습니다.

인프라 구축

👶🏻 OK는 팀원들에게 공통 terraform module을 작성해 배포해야 했기 때문에 다음과 같은 목표를 세웠습니다.

💡 서비스별로 폴더를 분리해, root module에서만 코드 수정하도록 환경 구성 💡 각자의 aws 환경에서 진행할 수 있도록 terraform workspace 환경 구성

Terraform Workspace 구성

작업 공간을 통한 Workspaces 격리 HashiCorp 공식 문서 : Terraform Workspaces

• 테라폼은 기본 default 작업 공간을 사용합니다. 새 작업 공간을 만들거나 전환하려면 terraform workspace 명령을 사용합니다.
• 작업 공간은 code refactoring을 시도하는 것 같이, 이미 배포된 인프라에 영향을 주지 않고 테라폼 모듈을 테스트할 때 유용합니다.

workspace 구조

terraform.tfstate.d라는 폴더 아래에 workspace 별로 폴더가 생성되고, 각각 상태 파일인 .tfstate 파일이 관리되는 형태입니다.

# workspace 구조 예시

├── terraform.tfstate.d
│   ├── imok
│   │   ├── terraform.tfstate
│   │   └── terraform.tfstate.backup
│   └── project
│       ├── terraform.tfstate
│       └── terraform.tfstate.backup

workspace 사용

1. 새 workspace 생성

   terraform workspace new [workspace name]

2. workspace 전환

   terraform workspace select [workspace name]

3. workspace 리스트 확인

   terraform workspace list

4. 현재 workspace 확인

   terraform workspace show

aws credentials 사용

terraform 프로젝트를 두 개 이상의 어카운트에서 사용해야 할 경우, aws credential의 profile 이름을 workspace 이름과 일치시키는 방법을 사용합니다.

• ~/.aws/credentials 파일 예

[imok]
aws_access_key_id = []
aws_secret_access_key = []
[workspace name]
aws_access_key_id = []
aws_secret_access_key = []
...

Terraform module 구성

1. root module : 실제로 수행하게 되는 작업 디렉터리의 terraform 코드 모음
   • root.tf
2. child module : root module에서 리소스를 생성하기 위해 참조하고 있는 module block
   • EC2, VPC, IAM, SG
     

child module에서 모듈이 생성하는 resource는 보통의 리소스를 생성하는 코드와 동일하지만, root module(모듈을 사용하는 코드)에서 건네주는 변수들을 사용해서 리소스를 생성해야 합니다.  저는 root module을 root.tf파일로 정의하고, 해당 파일에서 모듈을 사용하는 코드를 작성했습니다.

var.az_names와 같이 root module에서 설정한 변수를 받아와 child module에서 리소스를 생성할 수 있습니다. 이러한 변수를 받아오기 위해서는 child module에서 variable을 설정해주어야 합니다.

child module에서 리소스를 생성한 후, 생성한 리소스에 대한 정보(arn, id 등)를 받기 위해 child module에서 output을 통해 리소스 정보를 출력해주어야 합니다.

root module에서는 module.<MODULE_NAME>.id와 같이 output을 받아올 수 있습니다.

⚠️ 해당 내용이 모듈을 도입하면서 제일 많이 헷갈리고, 제일 많은 오류를 겪었던 부분입니다. 😵
반복해서 환경을 구성해보면서 이해하는 것이 좋습니다.

저는 다음과 같이 root module과 서비스 별 child module영역으로 구분해 코드를 작성했습니다.

.
├── ec2
│   ├── ami.tf
│   ├── key-pair.tf
│   ├── main.tf
│   ├── outputs.tf
│   ├── user_data
│   │   ├── user_data_private.sh
│   │   └── user_data_public.sh
│   └── variables.tf
├── iam
│   ├── main.tf
│   ├── outputs.tf
│   └── variables.tf
├── sg
│   ├── main.tf
│   ├── outputs.tf
│   └── variables.tf
├──vpc
│   ├── main.tf
│   ├── outputs.tf
│   └── variables.tf
├── terraform.tfstate.d # workspace
│   └── imok
│       ├── terraform.tfstate
│       └── terraform.tfstate.backup
├── terraform.tfvars
├── outputs.tf
├── provider.tf
├── root.tf # root module
└── variables.tf

VPC Resouece

지난 번 구성과 다른 점은 count를 for_each 문으로 변경했다는 점입니다. for each 표현식에 대한 설명은 제 블로그 내용 참고 부탁드립니다. Terraform 반복문 Loops 사용하기

1. main.tf 파일 구성

   resource "aws_subnet" "private" {
    for_each          = var.private_subnets
    vpc_id            = aws_vpc.vpc.id
    cidr_block        = each.value["cidr"]
    availability_zone = each.value["zone"]
   
    tags = merge(
      {
        Name = format(
          "%s-pri-sub-%s",
          var.name,
          element(split("_", each.key), 2)
        )
      },
      var.tags,
    )
   }

2. variables.tf 파일 구성 root module에서 정의한 변수를 받아오기 위해 다음과 같이 variable을 설정했습니다.

   # project name
   variable "name" {}
   
   # VPC default CIDR
   variable "vpc_cidr" {}
   
   # Availability Zones
   variable "az_names" {}
   
   # public subnet list
   variable "public_subnets" {}
   
   # private subnet list
   variable "private_subnets" {}
   
   # Tags
   variable "tags" {}

3. output.tf 파일 구성 ec2 리소스에서 vpc의 subnet id 변수를 사용하기 위해 output에 정의했습니다.

   output "public_subnet_ids" {
    value = values(aws_subnet.public)[*].id
   }
   
   output "private_subnet_ids" {
    value = values(aws_subnet.private)[*].id
   }

EC2 Resouece

1. main.tf 파일 구성

• 미리 ami.tf 파일에서 정의한 ami 중 최신 amazon linux2의 이미지를 선택했고, 인스턴스 타입, 볼륨 등을 설정했습니다.

• user_data는 미리 파일을 구성해서 ${path.module}를 사용해 해당 모듈 경로에 있는 파일을 불러와 인스턴스를 생성했습니다.

  resource "aws_instance" "private" {
    key_name               = var.key_name
    ami                    = data.aws_ami.amazon_linux2_kernel_5.id
    instance_type          = var.ec2_type_private
    vpc_security_group_ids = [var.security_group_id_private]
    subnet_id              = var.pri_sub_ids[0]
  
    iam_instance_profile    = var.iam_instance_profile
    disable_api_termination = var.instance_disable_termination
  
    user_data = file("${path.module}/user_data/user_data_private.sh")
  
    root_block_device {
      volume_size           = 10
      volume_type           = "gp3"
      delete_on_termination = true
    }
  
    tags = merge(
      {
        Name = format(
          "%s-private-server",
          var.name
        )
      },
      var.tags,
    )
  }

2. variables.tf 파일 구성 root module에서 정의한 변수를 받아오기 위해 다음과 같이 variable을 설정했습니다. 다른 모듈의 output에서 정의된 변수를 여기에서 받아 옵니다.

   #  For EC2
   variable "name" {}
   variable "tags" {}
   variable "az_names" {}
   variable "instance_disable_termination" {}
   variable "key_name" {}
   variable "ec2_type_public" {}
   variable "ec2_type_private" {}
   variable "volume_size" {}
   variable "public_subnets" {}
   variable "private_subnets" {}
   
   #  From module VPC
   variable "pub_sub_ids" {}
   variable "pri_sub_ids" {}
   
   #  From module IAM
   variable "iam_instance_profile" {}
   
   #  From module SG
   variable "security_group_id_public" {}
   variable "security_group_id_private" {}

3. output.tf 파일 구성 root module의 output에서 ec2 접속을 위한 정보를 확인하기 위해 다음과 같이 필요한 변수들을 정의했습니다.

   output "key_pair" {
    value = var.key_name
   }
   
   output "public_eip" {
    value = aws_eip.public.public_ip
   }
   
   output "ec2_private_id" {
    value = aws_instance.private.id
   }

4. key-pair.tf 파일 구성 ${path.module}를 사용해 local의 모듈 경로에 key file을 생성합니다.

   # Generates a secure private key and encodes it as PEM
   resource "tls_private_key" "key_pair" {
    algorithm = "RSA"
    rsa_bits  = 4096
   }
   # Create the Key Pair
   resource "aws_key_pair" "key_pair" {
    key_name   = "${var.name}-key"
    public_key = tls_private_key.key_pair.public_key_openssh
   }
   # Save Pem Key
   resource "local_file" "ssh_key" {
    filename = "${path.module}/${aws_key_pair.key_pair.key_name}.pem"
    content  = tls_private_key.key_pair.private_key_pem
   }

SG Resouece

SG 구성은 지난번 구성과 거의 동일하고, locals 변수를 추가해 tag에 활용했습니다.

1. main.tf 파일 구성

   locals {
    public_sg  = format("%s-%s-sg", var.name, "public")
    private_sg = format("%s-%s-sg", var.name, "private")
   }
   
   resource "aws_security_group" "private" {
    name        = local.private_sg
    description = "private security group for ${var.name}"
    vpc_id      = var.vpc_id
   
    # inbound rule
    dynamic "ingress" {
      for_each = [for s in var.private_ingress_rules : {
        from_port = s.from_port
        to_port   = s.to_port
        desc      = s.desc
        cidrs     = [s.cidr]
      }]
      content {
        from_port   = ingress.value.from_port
        to_port     = ingress.value.to_port
        cidr_blocks = ingress.value.cidrs
        protocol    = "tcp"
        description = ingress.value.desc
      }
    }
   
    # outbound rule
    egress {
      from_port   = 0
      to_port     = 0
      protocol    = "-1"
      cidr_blocks = ["0.0.0.0/0"]
    }
   
    tags = merge(
      {
        Name = local.private_sg
      },
      var.tags
    )
   }

2. variables.tf 파일 구성 root module에서 정의한 변수를 받아오기 위해 다음과 같이 variable을 설정했습니다.

   # Project name
   variable "name" {}
   
   # Tags
   variable "tags" {}
   
   # public ingress IP list
   variable "public_ingress_rules" {}
   
   # private ingress IP list
   variable "private_ingress_rules" {}
   
   # From module VPC
   variable "vpc_id" {}

3. output.tf 파일 구성 ec2 리소스에서 sg의 security_group_id 변수를 사용하기 위해 output에 정의했습니다.

   output "security_group_id_public" {
    value = aws_security_group.public.id
   }
   
   output "security_group_id_private" {
    value = aws_security_group.private.id
   }

IAM Resouece

Private EC2에 AWS SSM을 통해 접속하기 위한 IAM Role 구성입니다. SSM의 AmazonSSMManagedInstanceCore 정책과 S3의 AmazonS3FullAccess 정책을 붙였습니다.

1. main.tf 파일 구성

   # IAM role
   resource "aws_iam_role" "private" {
    name = format("%s-private-role", lower(var.name))
   
    assume_role_policy = <<EOF
   {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Sid": "",
              "Effect": "Allow",
              "Principal": {
                  "Service": "ec2.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
          }
      ]
   }
   EOF
   }
   
   # Attaches a Managed IAM Policy to an IAM role
   resource "aws_iam_role_policy_attachment" "private_for_s3" {
    role       = aws_iam_role.private.name
    policy_arn = "arn:aws:iam::aws:policy/AmazonS3FullAccess"
   }
   
   resource "aws_iam_role_policy_attachment" "private_for_ssm" {
    role       = aws_iam_role.private.name
    policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
   }
   
   # IAM instance profile
   resource "aws_iam_instance_profile" "private" {
    name = format("%s-private", lower(var.name))
    role = aws_iam_role.private.name
   }

2. variables.tf 파일 구성 root module에서 정의한 변수를 받아오기 위해 다음과 같이 variable을 설정했습니다.

   # Project name
   variable "name" {}
   
   # Tags
   variable "tags" {}

3. output.tf 파일 구성 ec2 리소스에서 iam의 iam_instance_profile 변수를 사용하기 위해 output에 정의했습니다.

   output "iam_instance_profile" {
    value = aws_iam_instance_profile.private.name
   }

root module

1. provider.tf 파일 구성 terraform.workspace를 사용해 workspace를 변경할 때마다 환경이 적용되도록 구성했습니다.

   terraform {
    required_providers {
      aws = {
        source  = "hashicorp/aws"
        version = "~> 4.45.0"
      }
    }
   
    required_version = ">= 1.2.0"
   }
   
   provider "aws" {
    region  = var.region
    profile = terraform.workspace
   }

2. root.tf 파일 구성 root module에서 child module을 사용하기 위한 코드를 작성했습니다. 각각의 모듈의 경로를 source = "./vpc" 다음과 같이 정의하고 시작하고, child module에 건네주기 위한 변수를 정의합니다. 이제 파일 한 곳에서 모든 리소스를 통제할 수 있습니다. 🤗

   module "vpc" {
    # Required
    source = "./vpc"
   
    # environment = var.environment
    name     = var.name
    tags     = var.tags
    az_names = var.az_names
   
    vpc_cidr        = var.vpc_cidr
    public_subnets  = var.public_subnets
    private_subnets = var.private_subnets
   }
   
   module "iam" {
    # Required
    source = "./iam"
   
    name = var.name
    tags = var.tags
   }
   
   module "ec2" {
    # Required
    source = "./ec2"
   
    name     = var.name
    tags     = var.tags
    az_names = var.az_names
   
    public_subnets  = var.public_subnets
    private_subnets = var.private_subnets
   
    # module vpc
    pub_sub_ids = module.vpc.public_subnet_ids
    pri_sub_ids = module.vpc.private_subnet_ids
   
    # module iam
    iam_instance_profile = module.iam.iam_instance_profile
   
    # module sg
    security_group_id_public  = module.sg.security_group_id_public
    security_group_id_private = module.sg.security_group_id_private
   
    instance_disable_termination = var.instance_disable_termination
    key_name                     = "${var.name}-key"
    volume_size                  = var.ec2_volume_size
    ec2_type_public              = var.ec2_type_public
    ec2_type_private             = var.ec2_type_private
   }
   
   module "sg" {
    # Required
    source = "./sg"
   
    name = var.name
    tags = var.tags
   
    public_ingress_rules  = var.public_ingress_rules
    private_ingress_rules = var.private_ingress_rules
   
    # module vpc
    vpc_id = module.vpc.vpc_id
   }

3. terraform.tfvars.tf 파일 구성 variables에서 사용하기 위한 변수를 tfvars.tf에서 정의했습니다.

   # Terraform setting
   environment = "dev"
   region      = "ap-northeast-2"
   
   tags = {
    MadeBy = "imok"
   }
   
   # Project name
   name = "T101"
   
   # Network setting 
   vpc_cidr = "10.60.0.0/16"
   
   az_names = [
    "ap-northeast-2a",
    "ap-northeast-2c"
   ]
   
   public_subnets = {
    pub_sub_2a = {
      zone = "ap-northeast-2a"
      cidr = "10.60.0.0/24"
    },
    pub_sub_2c = {
      zone = "ap-northeast-2c"
      cidr = "10.60.1.0/24"
    }
   }

4. variables.tf 파일 구성

root module 구성에 필요한 모든 변수를 정의합니다.

  # env - e.g: dev|prd|stage
  variable "environment" {}

  # Region - e.g: ap-northeast-2
  variable "region" {}

  # project name
  variable "name" {}

  # EC2 instance type
  variable "ec2_type_public" {}
  variable "ec2_type_private" {}

  # EC2 volume size
  variable "ec2_volume_size" {}

  # EC2 termination protection
  variable "instance_disable_termination" {}

  # VPC default CIDR
  variable "vpc_cidr" {}

  # Availability Zones
  variable "az_names" {}

  # public subnet list
  variable "public_subnets" {}

  # private subnet list
  variable "private_subnets" {}

  # Tag
  variable "tags" {}

  # public ingress IP list
  variable "public_ingress_rules" {}

  # private ingress IP list
  variable "private_ingress_rules" {}

  # DB port
  variable "db_port" {}

5. output.tf 파일 구성 최종 출력이 필요한 output을 모두 정의합니다.

   output "vpc_id" {
    value = module.vpc.vpc_id
   }
   
   output "public_subnet_ids" {
    value = module.vpc.public_subnet_ids
   }
   
   output "private_subnet_ids" {
    value = module.vpc.private_subnet_ids
   }
   
   output "nat_eip" {
    value = module.vpc.nat_eip
   }
   
   output "key_pair" {
    value = module.ec2.key_pair
   }
   
   output "public_eip" {
    value = module.ec2.public_eip
   }
   
   output "ec2_private_id" {
    value = module.ec2.ec2_private_id
   }

Terraform 실행

terraform output 확인

terraform output

• instance id 확인 : i-080061b0ee6c5e7bb
• key-pair 확인 : T101-key
• public ip 확인 : 15.164.88.41

생성된 리소스 및 접속 확인

1. VPC - Subnet

2. IAM Role

3. EC2

• Public EC2 접속 : pem key 사용

  ssh -i "T101-key.pem" ec2-user@15.164.88.41

  

• Private EC2 접속 및 S3 접근 : aws ssm, s3 정책 적용한 iam role 사용

  aws ssm start-session \
      --target i-080061b0ee6c5e7bb

  

👶🏻 OK는 이제 root module 파일 한 곳에서 모든 리소스를 통제, 관리할 수 있게 되었습니다. 💜

완성 코드는 제 깃허브에 올려놨습니다 참고 부탁드립니다 :) https://github.com/euneun316/terraform-study/tree/main/Modules/default

마치며..

사실 terraform module은 이미 잘 구성된 코드들이 많습니다. 하지만, 정확하게 module에 대해서 파악하지 않으면 처음부터 그 소스를 가져와 활용하기 무척 어렵습니다.

이번에 terraform module을 직접 구성하고 나니, 이제야 전반적으로 terraform이 동작하는 원리에 대해 더 정확히 파악되었습니다.

현재는 EC2, IAM, VPC, SG와 같은 기본 서비스 구성만 완료된 상태지만,

앞으로 kinesis, glue, athena와 같은 타 서비스 생성에 대한 기본 코드도 작성해 놓고, 필요할 때마다 코드를 활용할 수 있도록 module을 고도화할 생각입니다.

테라폼 모듈의 고수가 될 그날까지... 🏃🏻‍♀️

count 매개변수 사용 시 아래와 같은 제약사항이 있습니다.

1. 인라인 블록에 count 사용 지원하지 않음

• 전체 리소스를 반복할 수는 있지만 리소스 내에서 인라인 블록을 반복할 때, count 사용은 지원하지 않습니다.

2. 수정 시 발생하는 에러

• 배열의 중간 항목을 제거하면 모든 항목이 1칸씩 앞으로 당겨집니다.
• 즉 count 사용 시, 목록 중간 항목을 제거하면 테라폼은 해당 항목 뒤에 있는 모든 리소스를 삭제한 다음 해당 리소스를 처음부터 다시 만듭니다.

리소스의 여러 복사본을 만들 때는 count 대신 for_each 를 사용하는 것이 바람직합니다. 따라서 for each 표현식을 사용해 vpc를 생성하는 실습을 진행했습니다.

for each 표현식

for_each 공식문서

for_each 표현식을 사용하면 리스트 lists, 집합 sets, 맵 maps 를 사용하여 전체 리소스의 여러 복사본 또는 리소스 내 인라인 블록의 여러 복사본, 모듈의 복사본을 생성 할 수 있습니다.

resource "<PROVIDER>_<TYPE>" "<NAME>" {
  for_each = <COLLECTION>

  [CONFIG ...]
}

• COLLECTION 은 루프를 처리할 집합 또는 맵

• 리소스에 for_each 를 사용할 때, 리스트는 지원 안함

• CONFIG 는 해당 리소스와 관련된 하나 이상의 인수로 구성되는데, CONFIG 내에서 each.key또는 each.value 를 사용하여 COLLECTION 에서 현재 항목의 키와 값에 접근할 수 있음

for each 사용 예시

# public subnet
resource "aws_subnet" "pub_sub" {
  for_each                = var.public_subnet
  vpc_id                  = aws_vpc.vpc.id
  cidr_block              = each.value["cidr"]
  availability_zone       = each.value["az"]
  map_public_ip_on_launch = false

  tags = {
    Name = "${var.tags}-${each.key}"
  }
}

맵에서 값만 반환하는 내장 함수 values 사용 가능

output "pub_sub_ids" {
  value = aws_subnet.pub_sub.*
}

output "dev_pri_sub_ids" {
  value = values(aws_subnet.dev_pri_sub)[*].id
}

terraform outputs

for_each 를 사용한 후에는 하나의 리소스 또는 count 를 사용한 것과 같은 리소스 배열이 되는 것이 아니라 리소스 맵 list into a set 이 됩니다.

Outputs:

dev_pri_sub_ids = [
  "subnet-0457a9a5e265772e4",
  "subnet-08b233055afe17048",
]
pub_sub_ids = [
  {
    pub-sub-2a = {
      "availability_zone" = "ap-northeast-2a"
      "availability_zone_id" = "apne2-az1"
      "cidr_block" = "10.60.4.0/24"
      "id" = "subnet-0caaebfec80d80359"
      "tags" = tomap({
        "Name" = "T101-pub-sub-2a"
      })
      "vpc_id" = "vpc-0473c85bd926f6873"
    },
    pub-sub-2c = {
      "availability_zone" = "ap-northeast-2c"
      "availability_zone_id" = "apne2-az3"
      "cidr_block" = "10.60.5.0/24"
      "id" = "subnet-0aaaf57e88b761897"
      "tags" = tomap({
        "Name" = "T101-pub-sub-2c"
      })
      "vpc_id" = "vpc-0473c85bd926f6873"
    },
  }
]

완성 코드는 제 깃허브에 올려놨습니다 참고 부탁드립니다 :) https://github.com/euneun316/terraform-study/tree/main/T101/WEEK5/vpc

CloudNet@ Terraform Study 101 을 진행하며 학습한 내용을 정리했습니다. 스터디 교재는 테라폼 업앤러닝을 사용했습니다.

반복문 Loops

테라폼이 제공하는 반복문 구성

• count 매개변수 parameter : 리소스와 모듈의 반복

• for_each 표현식 expressions : 리소스 내에서 리소스 및 인라인 블록, 모듈을 반복

• for 표현식 expressions : 리스트 lists 와 맵 maps 을 반복

• for 문자열 지시어 string directive : 문자열 내에서 리스트 lists 와 맵 maps 을 반복

count 매개 변수

count 공식문서

count.index 사용

count.index 를 사용하여 반복문 안에 있는 각각의 반복 iteration 을 가리키는 인덱스를 얻을 수 있음

# main.tf
resource "aws_iam_user" "myiam" {
count = 3
name  = "imok.${count.index+1}"
}

• terraform state list 확인

  aws_iam_user.myiam[0]
  aws_iam_user.myiam[1]
  aws_iam_user.myiam[2]

배열 조회 구문과 length 함수 사용

배열 조회 구문 Array lookup syntax : ARRAY[<INDEX>]

• 테라폼에서 count 와 함께 배열 조회 구문과 length 함수를 사용해서 사용자들 생성 가능
• 리소스에 count 사용한 후에는 하나의 리소스가 아니라 리소스의 배열이 됨

# main.tf
resource "aws_iam_user" "myiam" {
count = length(var.user_names)
name  = var.user_names[count.index]
}

• terraform apply 결과

  aws_iam_user.myiam[1]: Creating...
  aws_iam_user.myiam[2]: Creating...
  aws_iam_user.myiam[0]: Creating...
  aws_iam_user.myiam[2]: Creation complete after 2s [id=imok3]
  aws_iam_user.myiam[1]: Creation complete after 2s [id=imok2]
  aws_iam_user.myiam[0]: Creation complete after 2s [id=imok1]
  

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Outputs:

all_arns = [ "arn:aws:iam::[Account ID]:user/imok1", "arn:aws:iam::[Account ID]:user/imok2", "arn:aws:iam::[Account ID]:user/imok3", ] first_arn = "arn:aws:iam::[Account ID]:user/imok1"

### count 제약 사항

1. 전체 리소스를 반복할 수는 있지만 리소스 내에서 인라인 블록을 반복할 수는 없음. 인라인 블록 내에서는 count 사용은 지원하지 않음

2. 수정 시 발생하는 에러

- 중간에 있는 imok2 user를 제거하고 plan & apply

```bash
default = ["imok1", "imok2", "imok3"]

• terraform plan 결과

~ update in-place
- destroy

Terraform will perform the following actions:

# aws_iam_user.myiam[1] will be updated in-place
~ resource "aws_iam_user" "myiam" {
        id            = "imok2"
    ~ name          = "imok2" -> "imok3"
        tags          = {}
        # (5 unchanged attributes hidden)
    }

# aws_iam_user.myiam[2] will be destroyed
# (because index [2] is out of range for count)
- resource "aws_iam_user" "myiam" {
    - arn           = "arn:aws:iam::[Account ID]:user/imok3" -> null
    - force_destroy = false -> null
    - id            = "imok3" -> null
    - name          = "imok3" -> null
    - path          = "/" -> null
    - tags          = {} -> null
    - tags_all      = {} -> null
    - unique_id     = "fgdgdfgdfgd" -> null
    }

Plan: 0 to add, 1 to change, 1 to destroy.

Changes to Outputs:
~ all_arns = [
        # (1 unchanged element hidden)
        "arn:aws:iam::[Account ID]:user/imok2",
    - "arn:aws:iam::[Account ID]:user/imok3",
    ]

• 배열의 중간에 항목을 제거하면 모든 항목이 1칸씩 앞으로 당겨짐.
• 테라폼이 인덱스 번호를 리소스 식별자로 보기 때문에 ‘인덱스 1에서는 계정 생성, 인덱스2에서는 계정 삭제한다’라고 해석함
• 즉 count 사용 시 목록 중간 항목을 제거하면 테라폼은 해당 항목 뒤에 있는 모든 리소스를 삭제한 다음 해당 리소스를 처음부터 다시 만듬.
• 따라서 위 예시에서 imok2 user를 삭제했지만, imok3 user가 삭제되는 에러 발생

for each 표현식

for_each 공식문서

for_each 표현식을 사용하면 리스트 lists, 집합 sets, 맵 maps 를 사용하여 전체 리소스의 여러 복사본 또는 리소스 내 인라인 블록의 여러 복사본, 모듈의 복사본을 생성 할 수 있음

resource "<PROVIDER>_<TYPE>" "<NAME>" {
  for_each = <COLLECTION>

  [CONFIG ...]
}

• COLLECTION 은 루프를 처리할 집합 sets 또는 맵 maps

• 리소스에 for_each 를 사용할 때 리스트는 지원 안함

• CONFIG 는 해당 리소스와 관련된 하나 이상의 인수로 구성되는데 CONFIG 내에서 each.key또는 each.value 를 사용하여 COLLECTION 에서 현재 항목의 키와 값에 접근할 수 있음

for_each 예제

for_each 를 사용하여 3명의 IAM 사용자를 생성

var.user_names 리스트를 집합(set)으로 변환하기 위해 toset 사용.

# main.tf
resource "aws_iam_user" "myiam" {
  for_each = toset(var.user_names)
  name     = each.value
}

for_each 를 사용한 후에는 하나의 리소스 또는 count 를 사용한 것과 같은 리소스 배열이 되는 것이 아니리 리소스 맵 list into a set 이 됩니다.

• terraform state list 확인

aws_iam_user.myiam["imok1"]
aws_iam_user.myiam["imok2"]
aws_iam_user.myiam["imok3"]

• terraform apply 확인

aws_iam_user.myiam["imok2"]: Creating...
aws_iam_user.myiam["imok3"]: Creating...
aws_iam_user.myiam["imok1"]: Creating...
aws_iam_user.myiam["imok3"]: Creation complete after 2s [id=imok3]
aws_iam_user.myiam["imok2"]: Creation complete after 2s [id=imok2]
aws_iam_user.myiam["imok1"]: Creation complete after 2s [id=imok1]

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Outputs:

all_users = [
  "arn:aws:iam::[Account ID]:user/imok1",
  "arn:aws:iam::[Account ID]:user/imok2",
  "arn:aws:iam::[Account ID]:user/imok3",
]

리소스 중간 값 제거 테스트

for_each 를 사용해 리소스를 맵으로 처리하면 컬렉션 중간의 항목도 안전하게 제거할 수 있어서, count 로 리소스를 배열 처리보다 이점이 큽니다.

중간에 있는 imok2 user를 제거하고 plan & apply

• terraform plan 결과

  이제 주변 모든 리소스를 옮기지 않고 정확히 목표한 리소스만 삭제가 됩니다.

  - destroy

Terraform will perform the following actions:

  # aws_iam_user.myiam["imok2"] will be destroyed
  # (because key ["imok2"] is not in for_each map)
  - resource "aws_iam_user" "myiam" {
      - arn           = "arn:aws:iam::[Account ID]:user/imok2" -> null
      - force_destroy = false -> null
      - id            = "imok2" -> null
      - name          = "imok2" -> null
      - path          = "/" -> null
      - tags          = {} -> null
      - tags_all      = {} -> null
      - unique_id     = "dsdsdsdsdsd" -> null
    }

Plan: 0 to add, 0 to change, 1 to destroy.

Changes to Outputs:
  ~ all_users = [
        "arn:aws:iam::[Account ID]:user/imok1",
      - "arn:aws:iam::[Account ID]:user/imok2",
        "arn:aws:iam::[Account ID]:user/imok3",
    ]

for 표현식

for Expressions 공식문서

단일 값을 생성하기 위해 반복이 필요한 경우 사용

for Expressions - list 예제

조건을 지정해서 결과 리스트를 필터링할 수 있음
list를 사용한 for 표현식 : [for <ITEM> in <LIST> : <OUTPUT>]

• LIST : 반복할 리스트
• ITEM : LIST의 각 항목에 할당할 변수의 이름
• OUTPUT : ITEM을 어떤 식으로든 변환하는 표현식

# main.tf
variable "names" {
  description = "A list of names"
  type        = list(string)
  default     = ["imok22", "imok1", "imok333"]
}

output "upper_names" {
  value = [for name in var.names : upper(name)]
}

output "short_upper_names" {
  value = [for name in var.names : upper(name) if length(name) < 6]
}

• terraform output 결과

short_upper_names = [
  "IMOK1",
]
upper_names = [
  "IMOK22",
  "IMOK1",
  "IMOK333",
]

for Expressions - map 예제

map을 사용한 for 표현식 : [for <KEY>, <VALUE> in <MAP> : <OUTPUT>]

• MAP : 반복되는 맵
• KEY, VALUE : MAP의 각 키-값 쌍에 할당할 로컬 변수의 이름
• OUTPUT : KEY와 VALUE를 어떤 식으로든 변환하는 표현식

#main.tf
variable "names" {
  description = "A list of names"
  type        = list(string)
  default     = ["imok1", "imok22", "imok333"]
}

output "upper_names" {
  value = [for name in var.names : upper(name)]
}

output "short_upper_names" {
  value = [for name in var.names : upper(name) if length(name) < 5]
}

variable "hero_thousand_faces" {
  description = "map"
  type        = map(string)
  default = {
    imok1   = "hero"
    imok22  = "love interest"
    imok333 = "mentor"
  }
}

output "bios" {
  value = [for name, role in var.hero_thousand_faces : "${name} is the ${role}"]
}

• terraform output 결과

  bios = [
  "imok1 is the hero",
  "imok22 is the love interest",
  "imok333 is the mentor",
  ]
  short_upper_names = []
  upper_names = [
  "IMOK1",
  "IMOK22",
  "IMOK333",
  ]

for Expressions - 출력 예제

for 표현식을 리스트가 아닌 맵을 출력하는 데 사용할 수도 있음

• 리스트를 반복하고 맵을 출력 Loop over a list and output a map
  {for <ITEM> in <LIST> : <OUTPUT_KEY> => <OUTPUT_VALUE>}

• 맵을 반복하고 리스트를 출력 Loop over a map and output a map
  {for <KEY>, <VALUE> in <MAP> : <OUTPUT_KEY> => <OUTPUT_VALUE>}

#main.tf
variable "names" {
  description = "A list of names"
  type        = list(string)
  default     = ["imok1", "imok22", "imok333"]
}

output "upper_names" {
  value = [for name in var.names : upper(name)]
}

output "short_upper_names" {
  value = [for name in var.names : upper(name) if length(name) < 6]
}

variable "hero_thousand_faces" {
  description = "map"
  type        = map(string)
  default = {
    imok1   = "hero"
    imok22  = "love interest"
    imok333 = "mentor"
  }
}

output "bios" {
  value = [for name, role in var.hero_thousand_faces : "${name} is the ${role}"]
}

output "upper_roles" {
  value = { for name, role in var.hero_thousand_faces : upper(name) => upper(role) }
}

• terraform output 결과

  bios = [
  "imok1 is the hero",
  "imok22 is the love interest",
  "imok333 is the mentor",
  ]
  short_upper_names = [
  "IMOK1",
  ]
  upper_names = [
  "IMOK1",
  "IMOK22",
  "IMOK333",
  ]
  upper_roles = {
  "IMOK1" = "HERO"
  "IMOK22" = "LOVE INTEREST"
  "IMOK333" = "MENTOR"
  }

문자열 지시자(String Derective)

문자열 지시자를 사용하면 문자열 보간과 유사한 구문으로 문자열 내에서 for 반복문, if문 같은 제어문을 사용할 수 있음

• 문자열 보간법 : "Hello, ${var.name}"

• 달러 부호와 중괄호 ${..} 대신 백분율 부호 %{..} 를 사용한다는 차이가 있음

for 문자열 지시자 : %{ for <ITEM> in <COLLECTION> }<BODY>%{ endfor }

• COLLECTION : 반복할 리스트 또는 맵
• ITEM : COLLECTION 의 각 항목에 할당할 로컬 변수의 이름
• BODY : ITEM을 참조할 수 있는 각각의 반복을 렌더링하는 대상

String Derective 예제

variable "names" {
  description = "Names to render"
  type        = list(string)
  default     = ["imok1", "imok22", "imok33"]
}

output "for_directive" {
  value = "%{ for name in var.names }${name}, %{ endfor }"
}

• terraform output 결과

for_directive = "imok1, imok22, imok33, "

• index 추가

variable "names" {
  description = "Names to render"
  type        = list(string)
  default     = ["imok1", "imok22", "imok33"]
}

output "for_directive" {
  value = "%{ for name in var.names }${name}, %{ endfor }"
}

output "for_directive_index" {
  value = "%{ for i, name in var.names }(${i}) ${name}, %{ endfor }"
}

• terraform output 결과

for_directive = "imok1, imok22, imok33, "
for_directive_index = "(0) imok1, (1) imok22, (2) imok33, "

완성 코드는 제 깃허브에 올려놨습니다 참고 부탁드립니다 :) https://github.com/euneun316/terraform-study/tree/main/T101/WEEK5

CloudNet@ Terraform Study 101 을 진행하며 학습한 내용을 바탕으로 업무에 활용한 내용을 작성했습니다. 따라서 AWS와 terraform에 대한 기본 개념 내용은 생략한 경우가 많습니다.

Terraform 스터디를 시작한 계기

클라우드 서비스 공급자인 AWS는 고객이 인프라 구성을 간편하게 할 수 있도록 웹 콘솔을 지원하고 있습니다.

성향에 따라 이런 GUI 환경을 좋아하시는 분들이 있지만, 저 같은 경우는 반복적인 작업이 필요한 경우 휴먼 에러를 방지할 수 있고, 생성하고자 하는 리소스를 한눈에 파악하기 쉽기 때문에 콘솔 작업보다 코드의 작업을 더 선호하는 편입니다.

처음 AWS를 접하고 VPC, EC2, SG, ELB과 같은 기본 서비스를 생성하고자 하면 어려울 수 있지만, 한번 익히고 나면 지루한 반복 작업으로 느껴질 수 있습니다.

따라서 저는 간단하지만 자주 사용하는 기본 인프라 구성을 코드형 인프라(Infrastructure as Code, IaC)중 하나인 Terraform으로 작성해 업무에 활용하고자 스터디를 시작하게 되었습니다.

⚠️ 본 내용은 개인적으로 Terraform을 처음 사용하면서 활용한 내용이기 때문에 틀릴 수 있습니다.

TL;DR: 노가다 하기 싫어서 Terraform 시작함 🙂 근데 너무 어렵다.. 그치만 재밌다

인프라 구축 전 체크 사항

A 기업에서 새로운 프로젝트 도입에 앞서 AWS에 테스트 환경을 구축하고자, 주니어 사원 👶🏻 OK에게 다음과 같은 인프라를 생성해줄 것을 요청했다고 가정해봤습니다.

인프라 구축 요구 사항 체크 ✅

1. 서비스 개발을 위해 사용할 서버는 Private Subnet 환경으로 구성

2. 서버는 개발(Dev) 환경과 운영(Prod) 환경으로 나눠서 구성 필요

   • 나중에 서버 환경은 추가될 수 있음
   • 운영 서버 환경은 고가용성을 위해 2개의 가용영역(AZ)으로 이중화 구성

3. SG(Security Group)에 다양한 Inbound Source 정보 등록 필요

   • 환경에 따라 Port 및 Source 정보는 달라질 수 있음

4. ALB에 HTTPS로 리스너 설정해 SSL Offload 수행

   • ALB는 개발 환경과 서비스별로 구분해서 생성
   • Target Group port는 언제든 변경, 추가될 수 있음

👶🏻 OK는 요구 사항을 확인하고, Terraform 구성 전에 미리 구축 내용을 작성했습니다.

구축 내용 ✅

1. VPC(Virtual Private Cloud)

• IP 대역 : 10.60.0.0/16
• On-Premise 환경에서 AWS의 Private Subnet 환경에 접속하기 위해, 인터넷 게이트웨이와 NAT 게이트웨이로 구성

2. Subnet 구성

• Region : ap-northeast-2 [Asia Pacific (Seoul)]

  Env	AZ	Subnet	IPv4 CIDR
  Common	ap-northeast-2a	imok-corp-pub-sub-2a	10.60.4.0/24
  Common	ap-northeast-2c	imok-corp-pub-sub-2c	10.60.5.0/24
  Dev	ap-northeast-2a	imok-corp-dev-pri-sub-2a	10.60.0.0/24
  Dev	ap-northeast-2c	imok-corp-dev-pri-sub-2c	10.60.1.0/24
  Prod	ap-northeast-2a	imok-corp-prd-pri-sub-2a	10.60.2.0/24
  Prod	ap-northeast-2c	imok-corp-prd-pri-sub-2c	10.60.3.0/24

3. SG(Security Group)

• EC2 접속을 위한 On-Premise의 IP Inbound Source 정보 (IP는 보안을 위해 임의로 생성했습니다.)

  CIDR	Desc
  18.164.239.93/32	ImOK Tower wireless ip
  111.245.120.118/32	ImOK Tower lan
  179.245.107.211/32	ImOK Corp VPN

4. EC2

• Private EC2에 ssh 접속은 Bastion Host를 통한 Tunneling 방식으로 접속

• OS : Amazon Linux 2

  구분	용도	Name	CPU	Memory	Disk	Type
  Common	Bastion Host	imok-corp-bastion	2	2GiB	10GiB	t3.small
  Dev	Management	imok-corp-dev-management-2a	2	16GiB	100GiB	r5.large
  Dev	Service	imok-corp-dev-service-2a	2	4GiB	50GiB	t3.medium
  Prd	Management	imok-corp-prd-management-2a	4	16GiB	100GiB	t3.xlarge
  Prd	Service	imok-corp-prd-service-2a	4	16GiB	50GiB	t3.xlarge
  Prd	Service	imok-corp-prd-service-2c	4	16GiB	50GiB	t3.xlarge

5. ALB(Application Load Balancer)

*6. ACM(AWS Certificate Manager) *

• AWS ACM 발급을 위해 외부 도메인 호스팅 업체에 DNS 검증 과정을 진행
• 검증 완료 후 Status : ✅ Issued 상태

👶🏻 OK는 다음과 같이 구축하게 될 예상 아키텍처를 그려봤습니다.

구축 예상 아키텍처 ✅

인프라 구축

👶🏻 OK는 향후 비슷한 업무를 맡게되었을 때, 미리 작성해 놓은 Terraform 코드를 재가공해 빠르게 인프라를 구축하고자 하는 목적이 있었습니다. 따라서 다음과 같은 목표를 세웠습니다.

💡 재사용 가능한 코드 작성을 위해 서비스별로 코드를 분리하기 💡 최대한 서비스 구축을 위한 코드는 수정하지않고, 요구사항의 변화에 맞춰 variables 파일만 수정해 사용하기

Terraform 사용 준비

terraform은 다음과 같은 workflow로 동작합니다.

https://learn.hashicorp.com/tutorials/terraform/infrastructure-as-code?in=terraform/aws-get-started

AWS credentials

저는 업무 특성상 여러 AWS 계정을 다뤄야하기 때문에 profile로 aws configure를 관리하고 있습니다. 따라서 export AWS_PROFILE="imok"로 아래와 같이 profile을 미리 정의하고 시작합니다.

Variables

보통 테라폼 코드를 작성할 때 variables.tf 파일을 만들어 해당 파일에 변수를 저장합니다. company명, service명, service port 등 인프라 생성 시에 바뀔 수 있는 부분을 변수로 지정해 사용했습니다.

terraform.tfvars

정의한 변수에 값을 주입하기 위해 가장 일반적인 방법은 terraform.tfvars 파일을 생성하는 것입니다. variable = value 형태로 정의합니다. 저 같은 경우는 보안그룹에 추가해야할 Inbound Source 정보를 모두 terraform.tfvars 파일에 정의해 놓고 사용했습니다.

# terraform.tfvars파일 작성 예시
bastion_ingress_rules = [
  {
    from_port = "22",
    to_port   = "22",
    cidr      = "18.164.239.93/32"
    desc      = "ImOK Tower wireless ip"
  },
  {
    from_port = "22",
    to_port   = "22",
    cidr      = "111.245.120.118/32"
    desc      = "ImOK Tower lan"
  }
]

AWS ACM의 경우 보통 기업의 상황에 따라 도메인 호스팅 업체에 등록 후 사용하는 경우가 많기 때문에, Terraform 코드로 생성하는 것이 아닌, AWS Console에서 생성 후 ARN을 tfvars에 등록하는 방법을 택했습니다.

terraform init

terraform init 명령어를 실행하면, local의 현재 디렉터리 아래에 아래 캡처 화면과 같이 미리 선언된 프로바이더(AWS) 플러그인을 설치해 줍니다.

init 작업을 완료하면, 테라폼의 꽃🌺인 .tfstate 파일과 .tfstate에 정의된 내용을 담은 .terraform 파일이 생성됩니다. .tfstate 파일은 상태 저장을 위한 파일로, 기존에 다른 개발자가 이미 .tfstate에 인프라를 정의해 놓은 것이 있다면, 다른 개발자는 init작업을 통해서 local에 sync를 맞출 수 있습니다.

.terraform
├── environment
├── providers
│   └── registry.terraform.io
│       └── hashicorp
│           └── aws
│               └── 4.38.0
│                   └── darwin_arm64
│                       └── terraform-provider-aws_v4.38.0_x5
└── terraform.tfstate

이제 인프라 생성을 위한 초기 준비가 완료됐습니다.

Terraform 구성

저는 다음과 같이 10개의 영역으로 구분해 코드를 작성했습니다.

terraform_study
├── alb.tf
├── ami.tf
├── ec2.tf
├── key-pair.tf
├── output.tf
├── provider.tf
├── sg.tf
├── terraform.tfvars
├── variables.tf
└── vpc.tf

Provider

1. variables.tf 파일 구성

profile에 쓰일 account와 region을 미리 variables에 정의했습니다.

  variable "account" {
    default     = "imok"
    description = "aws account"
  }

  variable "region" {
    type    = string
    default = "ap-northeast-2"
  }

2. provider.tf 파일 구성

   provider "aws" {
    region  = var.region
    profile = var.account
   }

key-pair Resource

1. variables.tf 파일 구성 key에 붙는 이름은 기업명, 프로젝트명에 따라 달라지기 때문에 tags를 미리 variables에 정의했습니다.

   variable "tags" {
    type        = string
    default     = "imok-corp"
    description = "Additional company tags"
   }

2. key-pair.tf 파일 구성

   # Generates a secure private key and encodes it as PEM
   resource "tls_private_key" "key_pair" {
    algorithm = "RSA"
    rsa_bits  = 4096
   }
   # Create the Key Pair
   resource "aws_key_pair" "key_pair" {
    key_name   = "${var.tags}-key"
    public_key = tls_private_key.key_pair.public_key_openssh
   }
   # Save Pem Key
   resource "local_file" "ssh_key" {
    filename = "${aws_key_pair.key_pair.key_name}.pem"
    content  = tls_private_key.key_pair.private_key_pem
   }

VPC Resouece

1. variables.tf 파일 구성 vpc에 사용할 ip 대역대와 subnet 대역대, az 정보를 미리 variables에 정의했습니다.

   variable "aws_az" {
    type    = list(any)
    default = ["ap-northeast-2a", "ap-northeast-2c"]
   }
   
   variable "aws_az_des" {
    type    = list(any)
    default = ["2a", "2c"]
   }
   
   variable "vpc_cidr" {
    type    = string
    default = "10.60.0.0/16"
   }
   
   variable "dev_private_subnet" {
    type    = list(any)
    default = ["10.60.0.0/24", "10.60.1.0/24"]
   }
   
   variable "prd_private_subnet" {
    type    = list(any)
    default = ["10.60.2.0/24", "10.60.3.0/24"]
   }
   
   variable "public_subnet" {
    type    = list(any)
    default = ["10.60.4.0/24", "10.60.5.0/24"]
   }

2. vpc.tf 파일 구성 subnet은 보통 az 2개의 쌍으로 구성하기 때문에, 코드의 반복을 줄이고자 count 라는 메타 변수를 사용했습니다. variables에서 정의한 aws_az의 개수가 2 이기 때문에, length 함수를 이용해 길이를 계산해 count 변수에서 정의했습니다.

따라서 count = length(var.aws_az) 로 count = 2가 되어 총 2개의 리소스가 생성됩니다.

count가 설정된 스탠자(stanza)에서 index 라는 객체를 사용할 수 있기 때문에, variables에서 정의한 public_subnet 변수에 count.index를 사용했습니다.

💡_ 저는 terraform 초보이고 생성할 리소스가 2개뿐이어서 count를 사용했지만, 생성할 리소스가 많을 때는 for each 문을 사용하는 것이 더 올바른 방법이라는 의견이 많습니다. 따라서 좀 더 학습 후 for each 문으로 변경해볼 예정입니다._

2022.12.11 for_each 문으로 변경 완료 😘 for_each 활용해 vpc 생성하기

  ## vpc
  resource "aws_vpc" "vpc" {
    cidr_block           = var.vpc_cidr
    enable_dns_support   = true
    enable_dns_hostnames = true

    tags = {
      Name = "${var.tags}-vpc"
    }
  }
  ## Subnet
  # public subnet
  resource "aws_subnet" "pub_sub" {
    count                   = length(var.aws_az)
    vpc_id                  = aws_vpc.vpc.id
    cidr_block              = var.public_subnet[count.index]
    availability_zone       = var.aws_az[count.index]
    map_public_ip_on_launch = false

    tags = {
      Name = "${var.tags}-pub-sub-${var.aws_az_des[count.index]}"
    }
  }

EC2 AMI data 정의

OS 요구에 따라 다양한 EC2 AMI를 활용하기 위해 최신 AMI 정보를 미리 구성했습니다.

*1. Amazon Linux2 *

# amazon linux2 ami latest
data "aws_ami" "amazon-linux-2" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name = "name"
    # values = ["amzn2-ami-hvm*"]
    values = ["amzn2-ami-hvm-*-gp2"]
  }
  filter {
    name   = "root-device-type"
    values = ["ebs"]
  }
  filter {
    name   = "architecture"
    values = ["x86_64"]
  }
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

2. Amazon Linux2 kernel-5

# amazon linux2 ami latest kernel-5
data "aws_ami" "amazon-linux-2-kernel-5" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-kernel-5*"]
  }
}

3. Ubuntu

# ubuntu ami latest
data "aws_ami" "ubuntu_latest" {
  most_recent = true
  owners      = ["099720109477"] # Canonical(owner account id)

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-xenial-16.04-amd64-server-*"]
    # values = ["ubuntu/images/hvm-ssd/ubuntu-xenial-18.04-amd64-server-*"]
    # values = ["ubuntu/images/hvm-ssd/ubuntu-xenial-22.04-arm64-server-*"]
  }
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

EC2 Resouece

EC2의 인스턴스 타입을 결정할 때 보통 cpu 와 memory 스펙을 정하고 워크로드에 적합한 타입을 선정합니다. 저는 아래 명령어를 통해 인스턴스 타입을 결정하는 편입니다.

• 참고 : Amazon EC2 인스턴스 유형 찾기

aws ec2 describe-instance-types --filters \
"Name=current-generation,Values=true" \
"Name=memory-info.size-in-mib,Values=4096" \
"Name=vcpu-info.default-vcpus,Values=2" \
--query "InstanceTypes[*].[InstanceType]" --output text | sort

1. ec2.tf 파일 구성 요구사항에 맞춰 미리 위에서 정의한 ami 중 최신 amazon linux2의 이미지를 선택했고, 인스턴스 타입, 볼륨 등을 설정했습니다.

   ## EC2
   # bastion
   resource "aws_instance" "bastion" {
    ami                    = data.aws_ami.amazon_linux2_kernel_5.id
    instance_type          = "t3.small"
    key_name               = aws_key_pair.key_pair.key_name
    subnet_id              = element(aws_subnet.pub_sub.*.id, 0) # public-subnet-2a
    vpc_security_group_ids = [aws_security_group.bastion_sg.id]
   
    root_block_device {
      volume_type = "gp3"
      volume_size = "10"
    }
   
    tags = {
      Name = "${var.tags}-bastion"
    }
   }
   
   # dev-management
   resource "aws_instance" "dev_management_2a" {
    ami                    = data.aws_ami.amazon_linux2_kernel_5.id
    instance_type          = "r5.large"
    key_name               = aws_key_pair.key_pair.key_name
    subnet_id              = element(aws_subnet.dev_pri_sub.*.id, 0) # dev-private-subnet-2a
    vpc_security_group_ids = [aws_security_group.dev_management_sg.id]
   
    root_block_device {
      volume_type = "gp3"
      volume_size = "100"
    }
   
    tags = {
      Name = "${var.tags}-dev-management-2a"
    }
   }

SG Resouece

1. variables.tf 파일 구성 SG에서 사용하기 위한 ingress rules을 미리 variables에 정의했습니다. default를 비워둔 이유는 위에서 언급한 terraform.tfvars 파일에 정의한 변수를 사용하기 위함입니다.

   variable "bastion_ingress_rules" {
    type        = list(map(string))
    default     = []
    description = "bastion sg rule"
   }
   
   variable "service_ingress_rules" {
    type        = list(map(string))
    default     = []
    description = "service sg rule"
   }
   
   variable "management_ingress_rules" {
    type        = list(map(string))
    default     = []
    description = "management sg rule"
   }

2. sg.tf 파일 구성 aws_security_group 리소스의 내부에 ingress block을 생성하는 데 dynamic block을 활용했습니다. for_each에서 block을 생성할 정보를 담은 for 표현식을 사용한 collection 을 전달받고, 이 collection 의 item 수만큼 block이 생성됩니다.

   for 표현식 : [for <ITEM> in <LIST> : <OUTPUT>]

   content는 실제로 정의하려는 block 안에 전달되는 값들을 명시하는 곳입니다. 따라서 원래 ingress block을 생성할 때 필요한 값을 넣어줍니다.

   ## Security group
   # bastion-sg
   resource "aws_security_group" "bastion_sg" {
    # count = length(var.bastion_ip)
    name        = "${var.tags}-bastion-sg"
    description = "${var.tags}-bastion-sg"
    vpc_id      = aws_vpc.vpc.id
   
    # inbound rule
    dynamic "ingress" {
      for_each = [for s in var.bastion_ingress_rules : {
        from_port = s.from_port
        to_port   = s.to_port
        desc      = s.desc
        cidrs     = [s.cidr]
      }]
      content {
        from_port   = ingress.value.from_port
        to_port     = ingress.value.to_port
        cidr_blocks = ingress.value.cidrs
        protocol    = "tcp"
        description = ingress.value.desc
      }
    }
   
    # outbound rule
    egress {
      from_port   = 0
      to_port     = 0
      protocol    = "-1"
      cidr_blocks = ["0.0.0.0/0"]
    }
   
    tags = {
      Name = "${var.tags}-bastion-sg"
    }
   }

ALB Resouece

ALB 구성이 개인적으로 제일 힘들었습니다. 처음엔 ALB의 Listener rule의 조건을 코드로 모두 작성하려고 했습니다. 하지만 아래 캡처와 같이 생각해야 할 분기 조건들이 너무 많았고, 처음부터 코드를 간결히 작성하는 데에만 집중해 count와 list로 해결하려다 보니 의존성에 문제가 생겨 오류가 계속 발생했습니다. 결국 룰 분기 조건은 콘솔창에서 작성하는 게 더 빠를 것 같다는 판단을 내렸습니다.

제 개인적인 생각으로는 ALB는 수고스럽지만, 코드가 반복되더라도 하나하나 작성하는 게 더 좋지않았을까라는 생각을 합니다. (아직 제가 좋은 방법이 있지만 찾지 못해서 그럴 수도..더 좋은 방법을 찾으면 개선하겠습니다. 🙇🏻‍♀️)

1. variables.tf 파일 구성 ALB에서 Target Group에 사용하기 위한 서비스 포트 및 certificate arn을 미리 variables에 정의했습니다.

   variable "env" {
    type        = list(any)
    default     = ["dev", "prd"]
    description = "Additional env tags"
   }
   
   variable "service_server_port" {
    type    = list(any)
    default = [8085, 8086]
   }
   
   variable "management_server_port" {
    type    = list(any)
    default = [8080]
   }
   
   variable "acm_certi" {
   type    = string
   default = ""
   }

2. alb.tf 파일 구성

• alb는 개발 환경에 따라 구성돼야하기 때문에 variables에 정의한 환경 변수의 개수만큼 생성되도록 했습니다.

  # ALB 생성
  resource "aws_lb" "service_alb" {
    count              = length(var.env)
    name               = "${var.tags}-${var.env[count.index]}-alb-service"
    load_balancer_type = "application"
    security_groups    = [aws_security_group.service_alb_sg.id]
    subnets            = [element(aws_subnet.pub_sub.*.id, 0), element(aws_subnet.pub_sub.*.id, 1)]
  
    tags = {
      Name = "${var.tags}-${var.env[count.index]}-alb-service"
    }
  }

• alb의 target group을 생성하고, target인 인스턴스를 붙입니다.

  ## ALB target group & attachment
  # dev service_tg
  resource "aws_lb_target_group" "dev_service_tg" {
    count    = length(var.service_server_port)
    name     = "${var.tags}-${var.env[0]}-service-tg-${var.service_server_port[count.index]}"
    port     = var.service_server_port[count.index]
    protocol = "HTTP"
    vpc_id   = aws_vpc.vpc.id
  }
  
  resource "aws_alb_target_group_attachment" "dev_service_tg_attach_2a" {
    count            = length(aws_lb_target_group.dev_service_tg)
    target_group_arn = element(aws_lb_target_group.dev_service_tg.*.arn, count.index)
    target_id        = aws_instance.dev_service_2a.id
    port             = var.service_server_port[count.index]
  }

• ALB listener를 http와 https로 나눠서 생성 후, https의 리스너 설정에서 terraform.tfvars에 정의한 AWS ACM ARN을 사용했습니다.

  ## ALB listener Redirect Action
  # service alb listener_http
  resource "aws_lb_listener" "service_alb_listener_http" {
    count             = length(var.env)
    load_balancer_arn = element(aws_lb.service_alb.*.arn, count.index)
    port              = 80
    protocol          = "HTTP"
  
    default_action {
      type = "redirect"
      redirect {
        port        = "443"
        protocol    = "HTTPS"
        status_code = "HTTP_301"
      }
    }
  }
  
  # service alb listener_https
  resource "aws_lb_listener" "service_alb_listener_https" {
    count             = length(var.env)
    load_balancer_arn = element(aws_lb.service_alb.*.arn, count.index)
    port              = 443
    protocol          = "HTTPS"
    ssl_policy        = "ELBSecurityPolicy-2016-08"
    certificate_arn   = var.acm_certi
  
    default_action {
      type = "fixed-response"
  
      fixed_response {
        content_type = "text/plain"
        message_body = "Fixed response content"
        status_code  = "503"
      }
    }
  }

Terraform 실행

terraform plan

앞에 작성한 리소스들이 실제 AWS에서 생성할 수 있는지 terraform plan 명령어를 통해 확인합니다. plan 명령어를 사용하면 현재 정의되어있는 리소스들을 실제 프로바이더에 적용했을 때, 테라폼이 어떤 작업을 수행할지 계획을 보여줍니다. 개인적으로 apply를 실행하기 전에 미리 내가 작성한 코드에 문제가 없는지 알 수 있어서 꼭 필요한 명령어라고 생각했습니다. (AWS 리소스 함부로 생성했다간 돌이킬 수 없는 일이 생길 수도 있기 때문이죠 😢)

아래 명령어 수행 결과를 보면, 총 71개의 리소스가 추가될 예정임을 알 수 있습니다.

terraform apply

plan을 통해 확인한 내용을, 실제로 AWS 프로바이더에 terraform apply 명령어를 통해 적용합니다. "정말 적용해도 괜찮으시겠어요?" 라는 마치 이 명령어에 책임을 질 수 있겠냐는 질문에 yes를 치고서야 최종적으로 리소스들을 생성할 수 있습니다. (물론, 생략하고 바로 생성할 수 있는 terraform apply -auto-approve 라는 명령어가 있습니다.)

아래 캡처 화면과 같이 Creating.. 이라는 문구가 계속 올라가면서 리소스들이 생성되는 과정을 확인할 수 있습니다. 마지막으로 Apply complete!라는 문구가 나오면, 이제 AWS에 콘솔에서 리소스들이 정상적으로 생성되었음을 확인할 수 있습니다.

1. VPC

2. EC2

3. SG

• 가장 반복 작업이라고 생각하는 inboud rule 한 번에 생성!🥳

4. ALB

👶🏻 OK는 3분 만에 구축 요구 사항에 맞는 인프라 구성을 완료했고, 룰루랄라 놀 수 새로운 일을 시작할 수 있었습니다. 😂

완성 코드는 제 깃허브에 올려놨습니다 참고 부탁드립니다 :) https://github.com/euneun316/terraform-study/tree/main/Default_Infra

마치며

처음 테라폼으로 인프라 구축을 시작했을 때 받았던 느낌은 '와 이걸 왜 지금 알았지..?' 였습니다. 명령어 몇 개로 쉽게 인프라가 뚝딱 만들어졌기 때문이죠. 하지만 계속 스터디하면서 느끼게 된 점은 쓰면 쓸수록 어렵고, 정말 '잘' 써야겠다는 생각입니다. 아무것도 없는 상태에서 기본 인프라 구축을 하는 데 사용하기에는 정말 좋습니다.

하지만 저는 위의 기본 인프라를 생성하는데 테라폼을 사용하면서도 많은 에러를 겪었습니다. subnet에서 리스트로 생성하다 꼬여서 6개가 만들어져야 하는데, 12개씩 생성되기도 하고, 만들어 놓은 ALB가 삭제가 안 되기도 하고, 잘 만들어진 EC2였는데, 글자 몇 개 수정했더니 삭제되고 다시 생성되기도 하고.. 그런데 이 리소스가 운영 중이던 서비스였다면..? 생각만 해도 아찔합니다.

따라서 앞으로는 ** .tfstate (상태 저장 파일)을 활용하는 부분, 테라폼을 사용해 협업하는 부분** 에 중점을 두고 스터디할 예정입니다. 테라폼 고수가 되어 다시 이 글을 고칠 그날까지... 🏃🏻‍♀️

사담..

이때의 느낌을 잊지 않기 위한 기록.

처음 CloudNet@ Terraform Study 101 모집 공고를 보고 스터디 신청을 한 후, 운영진 가시다님과의 전화 인터뷰에서 "스터디 탈락 인원이 꽤 많은데, 스터디 완주 가능하실까요?" 라는 질문을 받았습니다. "물론이죠!!" 라고 당차게 외친지 불과 첫 주 만에 자신감이 와르르 무너졌습니다.😢

분명 101 스터디인데.. 심화 과정이 아닌가 싶을 만큼 스터디 내용이 방대했고, 스터디원분들은 이미 고수들뿐인 것 같았습니다. 다들 이미 경지에 오르신 분들인데도 이렇게 열심히 노력한다는 사실에 엄청난 자극을 얻었고, 따라가려면 다른 분들이 걸을 때 나는 뛰어야겠다는 라는 생각으로 주말 밤을 새워 스터디 과제를 매주 제출했습니다. 그랬더니 조금 이해가 되는 것 같아서 점점 재밌어졌습니다. 😆

또 매주 테라폼 장인님들이 테라폼을 사용하면서 얻은 경험을 공유해주시는데, 모두 알차고 박수가 절로 나왔습니다. 그래서 꼭 스터디 완주를 해야겠다 다시 다짐했죠.

그런데..! (두둥 효과음) 중간과제 : 스터디 내용 혹은 테라폼 내용을 정리하여 글 작성 후 외부 공개! 중간과제 내용을 듣고 전 엄청난 부담감에 사로잡혔습니다. 다른 분들께 도움이 되는 내용을 과연 내가 작성할 수 있을지 자신이 없었습니다. 😢

하지만 그렇다고 포기할 순 없었기에, 할 수 있는 범위내에서 최선을 다하자고 결론 내리고 이 글을 작성하게 되었습니다. 저와 같이 처음 Terraform 스터디 중이신 분들이나, 기본 인프라 구성을 코드로 자동화하고 싶어 하시는 분들에게 꼭 도움이 됐으면 좋겠습니다. 제발(?) 🙏

*AWS EC2 안에서 Docker로 딥러닝 GPU 환경 구성 과정에서 발생한 ERROR 해결 과정을 기록합니다. *

인스턴스 유형 : g4dn.4xlarge

1. NVIDIA 확인

$lspci | grep -i nvidia
00:1e.0 3D controller: NVIDIA Corporation Device 1eb8 (rev a1)

2. docker run --gpus ERROR

ubuntu: 18.04 cuda: 11.3.1 torch: 1.7.1

2.1. docker run error 발생

$docker run -it --name pytorch --gpus '"device=0"' --network airflownet -v $PWD/notebooks:/notebooks -p 8888:8888 cuda11.3:pytorch1.7.1

docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]].
ERRO[0000] error waiting for container: context canceled

2.1. 해결 과정 : nvidia-container-toolkit을 설치

# nvidia-container-toolkit 설치
$distribution=$(. /etc/os-release;echo $ID$VERSION_ID) \
   && curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add - \
   && curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list

$sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit

# docker service 재시작
$sudo systemctl restart docker

2.2. 다시 docker run error 발생

$docker run -it --name pytorch --gpus '"device=0"' --network airflownet -v $PWD/notebooks:/notebooks -p 8888:8888 cuda11.3:pytorch1.7.1

docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: Running hook #0:: error running hook: exit status 1, stdout: , stderr: nvidia-container-cli: initialization error: load library failed: libnvidia-ml.so.1: cannot open shared object file: no such file or directory: unknown.
ERRO[0000] error waiting for container: context canceled

2.2. 해결 과정 1 : nvidia-utils 설치

• nvidia-smi 명령어 확인

$nvidia-smi

Command 'nvidia-smi' not found, but can be installed with:

sudo apt install nvidia-340
sudo apt install nvidia-utils-390

$sudo apt install nvidia-utils-390

• error 발생

$nvidia-smi

NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.

2.2 해결과정 2 : nvidia-driver 설치

$sudo apt install -y nvidia-driver-470
# 재시작해줘야 함
$sudo reboot now

2.3 해결 완료

$nvidia-smi
Sun Apr 24 08:09:45 2022
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.103.01   Driver Version: 470.103.01   CUDA Version: 11.4     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  Tesla T4            Off  | 00000000:00:1E.0 Off |                    0 |
| N/A   47C    P0    28W /  70W |      0MiB / 15109MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

3. CUDA 버전 확인

$nvcc -V
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2021 NVIDIA Corporation
Built on Mon_May__3_19:15:13_PDT_2021
Cuda compilation tools, release 11.3, V11.3.109
Build cuda_11.3.r11.3/compiler.29920130_0

conda version : conda 4.11.0 (homebrew miniconda) OS: Apple Silicon M1 python version : 3.9.10 catboost version : 1.0.5

install error

$pip install catboost
ERROR: Could not find a version that satisfies the requirement catboost (from versions: none)
ERROR: No matching distribution found for catboost

install catboost

$git clone https://github.com/catboost/catboost.git

$cd catboost/catboost/python-package/catboost

# DPYTHON_CONFIG에 본인 python3 config 경로 넣기
$../../../ya make -r -DUSE_ARCADIA_PYTHON=no -DOS_SDK=local \
-DPYTHON_CONFIG=/opt/homebrew/Caskroom/miniconda/base/envs/imok/bin/python3-config \
--target-platform=CLANG12-DARWIN-ARM64

# DPYTHON_BIN에 본인 python3 bin 경로 넣기
$python3 ../mk_wheel.py --target-platform=CLANG12-DARWIN-ARM64 \
-DPYTHON_BIN=/opt/homebrew/Caskroom/miniconda/base/envs/imok/bin/python3 \
-DPYTHON_CONFIG=/opt/homebrew/Caskroom/miniconda/base/envs/imok/bin/python3-config \
-DHAVE_CUDA=no --build-widget=no

$cd ..

$pip install catboost-1.0.5-cp39-none-macosx_11_0_arm64.macosx_12_0_arm64.whl

catboost version check

import catboost
catboost.__version__

Reference

https://github.com/catboost/catboost/issues/1526

1.Intel CPU 기반의 macOS나 Linux

• linux/amd64 아키텍처의 이미지를 사용

2. Apple Silicon M1

• linux/arm64/v8 아키텍처의 이미지를 우선적으로 사용 --platform linux/arm64/v8이 기본으로 설정

• Rosetta 2를 통해 Intel CPU에서 실행할 수 있도록 linux/amb64로 빌드된 애플리케이션도 실행할 수 있다. --platform linux/amd64 옵션을 사용

linux/arm64/v8 없는 경우 linux/amd64 아키텍처 이미지를 대신 사용할 수 있지만, 아직 여러가지 문제가 있는 것을 알려져있으며, Docker 사에서는 가능하면 arm64 이미지를 사용할 것을 권장함

• Run a command in a new container
• docker run 공식문서

Usage

docker run [OPTIONS] IMAGE [COMMAND] [ARG...]

Options

Examples

# docker 로 zeppelin 이미지 실행 
# 구동 directory 내에 logs 폴더와 notebook 폴더를 생성하고 docker path 에 마운트
# zeppelin:0.8.2
$docker run -p 4040:4040 -p 8080:8080 --platform linux/amd64 --name zeppelin --privileged=true -v $PWD/logs:/logs -v $PWD/notebook:/notebook -e ZEPPELIN_NOTEBOOK_DIR='/notebook' -e ZEPPELIN_LOG_DIR='/logs' -d apache/zeppelin:0.8.2 /zeppelin/bin/zeppelin.sh

# zeppelin:0.10.0
$docker run -p 4040:4040 -p 8080:8080 --platform linux/amd64 --name zeppelin --privileged=true -v $PWD/logs:/logs -v $PWD/notebook:/notebook -e ZEPPELIN_NOTEBOOK_DIR='/notebook' -e ZEPPELIN_LOG_DIR='/logs' -d apache/zeppelin:0.10.0 /opt/zeppelin/bin/zeppelin.sh

docker stop

• Stop one or more running containers
• docker stop 공식문서

Usage

docker stop [OPTIONS] CONTAINER [CONTAINER...]

Examples

$docker stop my_container

docker start

• Start one or more stopped containers
• docker start 공식문서

Usage

docker start [OPTIONS] CONTAINER [CONTAINER...]

Examples

$docker start my_container

docker rm

• Remove one or more containers
• docker rm 공식문서

Usage

docker rm [OPTIONS] CONTAINER [CONTAINER...]

Examples

$docker rm my_container

1. AWS 접속 AWS

2. 컴퓨팅 >EC2 > EC2 대시보드 > 인스턴스 시작

3. Amazon Machine Image(AMI) 선택

• Ubuntu Server 18.04 LTS (HVM), SSD Volume Type

4. 인스턴스 유형 선택

5. 인스턴스 시작 검토

• 새 키 페어 생성

6. EC2 생성 완료

7. 보안 규칙 설정

• 인스턴스 ID 클릭 > 보안 > 보안 그룹 클릭

• 인바운드 규칙 편집 클릭

2. ssh 로 EC2 인스턴스에 접속

1. ssh 연결할 인스턴스 체크 > 연결 버튼을 클릭한다.

• 인스턴스 엑세스 방법 확인
• ssh 명령어 복사 후 사용

$chmod 400 mykey.pem 
# key 프라이빗 키 파일 설치 경로로 이동 후 실행
$ssh -i "mykey.pem" ubuntu@[퍼블릭 IPv4 주소]

2. 정상 접속 확인

3. 퍼블릭 IPv4 주소 확인

# 디렉토리 파일 복사 (실행할 py 파일)
$scp -i "mykey.pem" -r [복사할 py 파일] ubuntu@[퍼블릭 IPv4 주소]:/home/ubuntu

# 필요 패키지 설치
$python3 --version
$pip3 list
$sudo apt-get update
$sudo apt-get install python3-pip
$pip3 install flask
$pip3 install pymysql
$pip3 show flask
$pip3 show pymysql