junkmm blog

[O-Tel] Opentelemetry로 .Net Trace 구성하기

junkmm — Sat, 12 Oct 2024 17:46:51 +0900

개요

안녕하세요. 오늘은 회사에서 PoC를 진행했던 O-Tel을 통한 Observalbility 구성하기 중 .Net Core App을 대상으로 Trace 메트릭을 수집하는 방법에 대해 정리하고자 합니다. 공식 문서를 참고하며 구성하였고, PoC를 진행했던 것보단 최소한으로 핵심적인 것들만 정리해 보려 합니다.

아키텍처

구현 목표

이번 글에서의 흐름은 아래와 같이 진행됩니다.

1. kind를 통해 간단한 kubernetes 클러스터를 생성합니다.

2. Trace Metrics을 확인하기 위한 Grafana를 설치합니다.

3. Trace Metrics의 수집, 저장을 위한 Tempo를 설치합니다.

4. Open Telemetry Collector를 설치하고, Trace Metrics 자동 수집을 위한 CRD를 구성합니다.

5. .Net Application을 배포합니다. 이 때 Trace Metrics을 자동 수집해주기 위한 Annotation을 설정합니다.

6. Grafana에서 Tempo 데이터를 추가하고, 조회 합니다.

쿠버네티스 환경에서 .Net Application의 별도 코드 수정 없이, O-Tel 구성을 통해 Trace Metrics을 자동 수집하는 것을 목표로 합니다.

참고로 .Net Application에 O-Tel SDK를 구성하여 수집할 메트릭을 직접 정의할 수도 있습니다.

구현하기

Step 1. Kind로 간단한 Kubernetes 클러스터 생성하기

아래 사진처럼 kind로 간단한 Kubernetes 클러스터를 생성합니다. kind는 로컬 환경에서 소규모로 kubernetes 클러스터를 간단히 생성할 수 있게 도와주며, 처음 접해보신다면 공식 문서를 참고하여 설정해 보시기 바랍니다.

kind – Quick Start

Quick Start This guide covers getting started with the kind command. If you are having problems please see the known issues guide. NOTE: kind does not require kubectl, but you will not be able to perform some of the examples in our docs without it. To inst

kind.sigs.k8s.io

Step 2. Grafana 설치하기

Trace Metrics을 시각화 하여 볼 수 있도록 공식 문서를 참고하여 Helm을 통해 Grafana를 설치합니다.

먼저 Helm 설치가 안되어 있다면, Helm을 설치합니다.

Installing Helm

Learn how to install and get running with Helm.

helm.sh

그 다음 아래 명령을 통해 Grafana repo를 등록합니다.

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

Grafana 컴포넌트를 설치할 네임스페이스를 생성하고, Grafana 설치를 진행합니다.

kubectl create namespace monitoring
helm install my-grafana grafana/grafana --namespace monitoring

설치가 정상적으로 완료되었는지 확인합니다.

관리자 비밀번호를 확인하기 위해 secret 데이터를 조회합니다.

kubectl get secret --namespace monitoring my-grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

새로운 터미널을 띄우고 `kubectl port-forward` 명령을 사용하여 Grafana 대시보드에 접근할 수 있도록 합니다. 호스트 포트에 접근하여 Grafana에 접근합니다. 이 때 로그인 ID는 `admin` 이고, 비밀번호는 위에서 확인한 비밀번호를 입력합니다.

kubectl port-forward -n monitoring services/my-grafana 30080:80

Step 3. Tempo 설치하기

Trace 메트릭을 받고, 저장, 관리할 수 있도록 Tempo를 설치합니다. Tempo는 Grafana와 같은 Helm repo를 사용하기 때문에 윗 단계에서 repo add를 진행하였다면 바로 설치할 수 있습니다.

먼저 `vi values.yaml`을 통해 Tempo 설치에 사용될 Helm value 파일을 생성합니다.

traces:
  otlp:
    http:
      enabled: true
      receiverConfig: {}
    grpc:
      enabled: true
      receiverConfig: {}
global_overrides:
  metrics_generator_processors:
  - service-graphs

아래 명령어로 Tempo를 설치하기 위한 네임스페이스를 생성 및 설치를 진행합니다.

kubectl create namespace tempo
helm -n tempo install tempo grafana/tempo-distributed -f values.yaml

설치가 정상적으로 완료되었는지 확인합니다.

Step 4. Opentelemetry Collector 설치 및 CRD(Auto-Instrument) 구성하기

Otel Operator 설치 및 Otel Collector 설치하기

Open Telemetry Collector의 경우 Helm 설치와 Operator를 통한 설치가 가능합니다. Helm을 통한 구성이 무조건 안되는 것인지는 모르겠으나 저의 경우 Helm을 통해 구성시 실패하였고, Operator를 통해 구성 시 성공하였기에 Operator를 통한 구성으로 내용을 정리하겠습니다.

먼저 Otel-Opertaor 설치 시 Cert-manager가 선제적으로 설치되어 있어야 하기에 cert-manager를 설치해 줍니다.

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.16.1/cert-manager.yaml

다음으로, Otel-Operator를 설치 합니다.

kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml

설치가 성공적으로 완료되면 Otel CRD도 설치됩니다. 따라서 아래와 같이 `kind: OpenTelemetryCollector`인 리소스도 쿠버네티스 환경에 설치할 수 있게 됩니다. 아래 파일을 생성하고 `kubectl apply -f <filename.yaml>`을 통해 Opentelemetry Collector를 설치합니다. 저는 otel.yaml 이라는 이름으로 생성하였습니다.

apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: collector
  namespace: otel-trace
spec:
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
          http:
            endpoint: 0.0.0.0:4318
    processors:
      memory_limiter:
        check_interval: 1s
        limit_percentage: 75
        spike_limit_percentage: 15
      batch:
        send_batch_size: 10000
        timeout: 10s
    exporters:
      otlphttp/tempo:
        endpoint: http://tempo-distributor.tempo.svc.cluster.local:4318
    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [memory_limiter, batch]
          exporters: [otlphttp/tempo]

위 Otel Collector Config를 해석 해보겠습니다. pipeline쪽을 보시면 traces 메트릭에 대해 recivers가 otlp로 구성되어 있습니다.

상단의 `config.receivers.otlp.protocols` 부분에 4317, 4318 포트로 OTLP를 리슨하는 것을 의미합니다. 아래 단계에서 .Net Application 구성 중 Trace 메트릭을 Otel Collector의 4317 혹은 4318 포트로 전송하면 될 것 입니다.

다음으로 processors가 있습니다. 수집된 데이터를 가공하는 단계 입니다. 마지막으로 exporters가 있습니다. 수집, 가공한 데이터를 tempo로 송신하게 됩니다.

이로써 유추할 수 있는 Trace 데이터의 흐름은 .Net App -> Otel-Collector -> Tempo -> Grafana를 통한 Trace 데이터 시각화 일 것 입니다.

위 YAML 파일을 작성하였다면 Otel Collector 설치를 위한 네임스페이스 생성 및 Collector 설치를 진행합니다.

kubectl create namespace otel-trace
kubectl apply -f otel.yaml

설치가 잘 되었는지 확인합니다.

Auto-Instrument 구성하기

먼저 Auto-Instrument에 대해 간략히 설명하겠습니다. Traces 메트릭은 Application의 상태 혹은 성능과 관련된 메트릭 입니다. 따라서 Trace 메트릭을 수집하기 위해서는 아래의 간단한 예시처럼 소스 코드에 Otel SDK를 적용하여 Trace 메트릭의 생성에 대해 정의해야 합니다.

반면 Auto-Instrument를 사용하면, 기존 Application의 코드 수정 없이 Traces와 관련된 메트릭을 수집할 수 있습니다.(정확히는 metrics, logs, traces 모든 메트릭에 대해 수집 가능합니다.)

기존 코드 수정없이 메트릭을 수집할 수 있기에 관리의 복잡성이 개선됩니다. 하지만 직접 코드에 정의하는 방식 보다 구성에 제약이 있어, 필요 없는 메트릭 까지 수집하게 될 수 있는 단점이 존재합니다.

Datadog에서는 별도의 Agent 설치를 통해 코드 수정 없이 APM 메트릭을 수집합니다. 쿠버네티스 환경에서의 Opentelemetry는 Instrument라는 리소스를 통해 메트릭을 수집하게 됩니다.

윗 단계에서 Opentelemetry Operator를 설치하며 Instrument를 배포할 수 있습니다. 그럼 아래의 YAML파일을 생성하고, Instrument 리소스 배포를 진행합니다.

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: dotnet-instrumentation
spec:
  exporter:
    endpoint: http://collector-collector.otel-trace.svc.cluster.local:4318
  propagators:
    - tracecontext
    - baggage
  sampler:
    type: parentbased_traceidratio
    argument: '1'
  dotnet:
    env:
    - name: OTEL_DOTNET_AUTO_TRACES_INSTRUMENTATION_ENABLED
      value: "true"
    - name: OTEL_DOTNET_AUTO_METRICS_INSTRUMENTATION_ENABLED
      value: "false"
    - name: OTEL_DOTNET_AUTO_LOGS_INSTRUMENTATION_ENABLED
      value: "false"

위 config를 살펴 보겠습니다.

spec.exporter : Instrument에서 수집한 메트릭을 전송할 Otel Collector의 주소입니다. 이전 단계에서 생성한 Otel-Collector의 서비스 주소를 입력하였습니다.
spec.propagators: Trace ID의 Context를 관리하기 위해 설정합니다. 만약 여러 서비스를 호출하는 MSA 구조인 Application이 존재한다면 API GW -> Backend -> DB 간의 Trace 추적을 해야할 것입니다. 이 옵션을 활성화 함으로써 1개의 요청에 대한 서비스 간 흐름을 1개의 Trace ID로 파악할 수 있습니다.
spec.sampler: Trace 추적을 필터링 합니다. 현재 argument는 1(100%)로 모든 요청에 대한 Trace를 기록하게 됩니다.
spec.dotnet.env: 메트릭 수집에 대한 옵션을 제공합니다. 현재는 Trace 메트릭만 수집하게 됩니다.

그럼 Instrument를 배포하고, 리소스가 잘 배포되었는지 확인합니다.

# 위 instrument yaml을 생성
kubectl apply -f instrument.yaml
# 리소스 배포 확인
kubectl get instrumentations.opentelemetry.io

Step 5. .Net Core App 배포하기

이번 글의 핵심(?)인 .Net Core Application을 배포합니다. 샘플 코드는 Opentelemetry의 문서를 참고 하였으며 핵심 로직은 아래 코드를 참고 합니다.

/rolldice를 호출하면 1~6 의 숫자 중 한 개의 숫자를 리턴하는 샘플 코드입니다.

using System.Globalization;

using Microsoft.AspNetCore.Mvc;

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

string HandleRollDice([FromServices]ILogger<Program> logger, string? player)
{
    var result = RollDice();

    if (string.IsNullOrEmpty(player))
    {
        logger.LogInformation("Anonymous player is rolling the dice: {result}", result);
    }
    else
    {
        logger.LogInformation("{player} is rolling the dice: {result}", player, result);
    }

    return result.ToString(CultureInfo.InvariantCulture);
}

int RollDice()
{
    return Random.Shared.Next(1, 7);
}

app.MapGet("/rolldice/{player?}", HandleRollDice);

app.Run();

위 .Net Core App을 컨테이너 이미지화 하였으며, 아래의 Yaml을 배포하여 deployment 리소스를 배포합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: myapp
  name: myapp-deployment
  namespace: app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      annotations:
        instrumentation.opentelemetry.io/inject-dotnet: "default/dotnet-instrumentation"
      labels:
        app: myapp
    spec:
      containers:
      - image: kimhj4270/rolldice:0.1
        name: myapp
        ports:
        - containerPort: 80
          protocol: TCP

배포 후 리소스가 잘 배포되었는지 확인합니다.

kubectl apply -f app.yaml
kubectl get pod -n app

Step 6. Grafana에 Tempo 데이터 연결 및 Trace 데이터 조회하기

Tempo Datasource 추가하기

먼저 Grafana의 Connections > Data sources > Add new Data source에 접근합니다. `Tempo`를 검색하고 클릭합니다.

Connection URL에 `http://tempo-query-frontend-discovery.tempo.svc.cluster.local:3100/`를 입력합니다.

하단의 [Save & Test]를 클릭합니다. 성공적으로 데이터가 연결 됐는지 확인합니다.

Trace 데이터 조회하기

Trace 데이터를 조회하려면, Trace 데이터를 생성해야 합니다. 따라서 아래의 절차에 따라 Application에 요청을 보내 Trace 메트릭을 발생 시킵니다.

먼저 새로운 터미널에서 `kubectl port-forward` 명령으로 로컬호스트에서 App 파드로 요청할 수 있는 환경을 만들어 줍니다.

kubectl port-forward -n app pods/myapp-deployment-d7bd896fd-t6gsk 30081:80

다음으로 `curl localhost/rolldice` 명령으로 App 파드에 http 요청을 보냅니다. 사진과 같이 1~6 사일의 랜덤 숫자를 리턴 받아야 합니다.

Trace 메트릭을 발생 시켰으니 Grafana에서 확인 합니다. Explore 메뉴에 접근하고, Data Source를 Tempo로 지정합니다. Query type을 Search로 변경하면 하위에 Trace ID를 확인할 수 있습니다. Trace ID를 클릭합니다.

Trace 메트릭을 아래 사진처럼 확인할 수 있습니다.

마무리 하며

이번 글에서는 Otel과 Tempo를 사용한 Trace 메트릭 수집 과정을 살펴 보았습니다. 사실 Application의 성능 관측을 위해선 Trace 메트릭 뿐만 아니라, Metrics, Logs 메트릭도 수집하고, 대시보드화 해야 할 것입니다. Trace는 단지 최초 요청으로 부터의 서비스 호출 흐름과 시간, 실패 여부만 파악할 수 있기 때문이죠.

Metrics을 통해 HTTP 요청이 초당 얼마나 들어오는지, 1 req당 응답 시간이 얼마나 걸리는지 확인할 수 있으며, Logs를 통해 오류가 발생한 요청의 TraceID를 검색하여 Error Logs도 손쉽게 확인해 볼 수 있을것입니다. (아래는 PoC를 완료한 샘플 대시보드 입니다. 물론 공개된 대시보드를 불러와, 일부 수정해서 사용했습니다.)

여러분도 이 과정을 참고하여 Metrics과 Logs를 수집하고 대시보드화 하는데 도움이 되었으면 합니다.

감사합니다.

[cks][killershell] Auditing Enable Audit Logging 실습

junkmm — Wed, 31 Jul 2024 18:58:47 +0900

문제

Configure the Apiserver for Audit Logging.
The log path should be /etc/kubernetes/audit-logs/audit.log on the host and inside the container.
The existing Audit Policy to use is at /etc/kubernetes/audit-policy/policy.yaml . The path should be the same on the host and inside the container.

Set argument --audit-log-maxsize=7
Set argument --audit-log-maxbackup=2
---
감사 로깅을 위해 Apiserver를 구성합니다.
로그 경로는 호스트 및 컨테이너 내부의 /etc/kubernetes/audit-logs/audit.log여야 합니다.
사용할 기존 감사 정책은 /etc/kubernetes/audit-policy/policy.yaml 에 있습니다. 경로는 호스트와 컨테이너 내부에서 동일해야 합니다.

인수 설정 --audit-log-maxsize=7
인수 설정 --audit-log-maxbackup=2

문제 분석하기

kube-apiserver에 audit log를 활성화 하는 문제입니다. api-server manifest에 arg 값을 조절하여 감사 로그를 활성화 하고, HostPath 볼륨을 마운트 시켜 노드의 특정 폴더에서 감사로그를 확인해볼 수 있습니다.

Step 1. 노드에 audit log 저장할 디렉터리 생성하기

mkdir /etc/kubernetes/audit-log

Step 2. kube-apiserver manifest 백업하기

cp /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml

Step 3. kube-apiserver.yaml 수정하기

spec:
  containers:
  - command:
    - kube-apiserver
... 중략
    - --audit-policy-file=/etc/kubernetes/audit-policy/policy.yaml # 정책이 정의된 파일
    - --audit-log-path=/etc/kubernetes/audit-logs/audit.log # 로그 저장 경로 정의, arg 값이 없으면 audit log 비활성화와 같은 의미
    - --audit-log-maxsize=7 # 오래된 감사 로그 파일을 보관할 최대 일수를 정의
    - --audit-log-maxbackup=2 # 보관할 감사 로그 파일의 최대 수를 정의
... 중략
    volumeMounts:
    - mountPath: /etc/kubernetes/audit-policy/policy.yaml
      name: audit
      readOnly: true
    - mountPath: /etc/kubernetes/audit-logs
      name: audit-log
      readOnly: false
... 중략
  volumes:
  - name: audit
    hostPath:
      path: /etc/kubernetes/audit-policy/policy.yaml
      type: File
  - name: audit-log
    hostPath:
      path: /etc/kubernetes/audit-logs
      type: DirectoryOrCreate

Step 4. Audit Log 생성되는지 확인하기

 cat /etc/kubernetes/audit-logs/audit.log

Json Viewer로 확인하면 잘 식별 됨!

감사(auditing)

쿠버네티스 감사(auditing) 는 클러스터의 작업 순서를 문서화하는 보안 관련 시간별 레코드 세트를 제공한다. 클러스터는 사용자, 쿠버네티스 API를 사용하는 애플리케이션 및 컨트롤 플레인 자체

kubernetes.io

[cks][killershell] NodeRestriction 실습

junkmm — Tue, 30 Jul 2024 19:08:39 +0900

문제

The Kubelet on node01 shouldn't be able to set Node labels

starting with node-restriction.kubernetes.io/*
on other Nodes than itself
Verify this is not restricted atm by performing the following actions as the Kubelet from node01

분석하기

api-server의 구성 변경을 검증(제한)하는 admission 적용하는 방법에 대한 실습. node01과 controlplane 총 2대의 워커노드가 있고, node01에서는 controlplane의 노드 라벨을 추가할 수 없도록 하기

Step 1. [admission 적용 전] node01에서 node label 추가해보기 → 잘 작동함

controlplane $ ssh node01
Last login: Tue Jul 30 09:15:19 2024 from 10.244.6.54

node01 $ kubectl label node controlplane killercoda/one=123 # works but should be restricted
node/controlplane labeled

node01 $ kubectl label node node01 node-restriction.kubernetes.io/one=123 # works but should be restricted
node/node01 labeled

Step 2. 매니페스트를 수정해서 static pod(kube-apiserver) 장애 발생시키기

아래 명령으로 kube-apiserver 편집, `spec.containers.command`에 `--enable-admission-plugins=NodeRestriction` 옵션 추가하기

# controlplane 노드에서 실행
vi /etc/kubernetes/manifests/kube-apiserver.yaml

---

spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=172.30.1.2
... 중략 ...
    - --enable-admission-plugins=NodeRestriction

node01에 접속해서 라벨 수정 해보기 → node01 외 다른 노드는 label 추가 안됨

결론

아래 홈페이지를 가보면 api-server의 addmission을 사용해 여러가지 활동에 대한 제약을 줄 수 있음을 알 수 있습니다. 이번 실습에서 자용한 addmission은 `NodeRestriction`입니다. 설명 중 일부를 발췌 해보면 해당 옵션은 검증 작업을 수행하는 옵션이고, Node 및 Pod API 호출 시 요청자 kubelet이 설치된 노드에서만 수정을 허용하는 옵션임을 알 수 있습니다.

Such kubelets will only be allowed to modify their own Node API object, and only modify Pod API objects that are bound to their node.

Admission Controllers Reference

This page provides an overview of Admission Controllers. What are they? An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authoriz

kubernetes.io

[cks][killershell] Apiserver Crash 실습

junkmm — Mon, 29 Jul 2024 20:03:38 +0900

문제

The idea here is to misconfigure the Apiserver in different ways, then check possible log locations for errors.
You should be very comfortable with situations where the Apiserver is not coming back up.
Configure the Apiserver manifest with a new argument --this-is-very-wrong .
Check if the Pod comes back up and what logs this causes.
Fix the Apiserver again.
---
(구글 번역)
여기서의 아이디어는 Apiserver를 다양한 방식으로 잘못 구성한 다음 가능한 로그 위치에 오류가 있는지 확인하는 것입니다.
Apiserver가 다시 작동하지 않는 상황이 매우 편안할 것입니다.
새로운 인수 --this-is-very-wrong 으로 Apiserver 매니페스트를 구성합니다.
Pod가 다시 작동하는지 확인하고 이로 인해 발생하는 로그를 확인하세요.
Apiserver를 다시 수정하세요.

문제 분석하기

kube-apiserver의 매니페스트가 위치한 `/etc/kubernetes/manifests` 폴더에 `kube-apiserver.yaml` 파일을 백업한 뒤 일부러 고장시키고, 복구시키는 방법에 대한 방법 확인하기

Step 1. 매니페스트 백업하기

static pod를 생성하는 위치인 /etc/kubernetes/manifest 폴더 내 kube-apiserver.yaml 파일을 Home dir에 백업합니다.

cp /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.orig

Step 2. 매니페스트를 수정해서 static pod(kube-apiserver) 장애 발생시키기

vi /etc/kubernetes/manifests/kube-apiserver.yaml

`spec.containers.command` 하위에 `--this-is-very-wrong` 이라는 오류를 발생시키는 인자값을 추가 입력한 뒤 저장합니다.

아래와 같이 바로 장애가 발생하는것을 확인할 수 있습니다.

Step 3. kube-apiserver 장애 시 로그 확인 방법

방법 1. `/var/log/pods` 하위 로그 확인

방법 2. `/var/log/containers` 하위 로그 확인

방법 3. `crictl ps -a + crictl logs` 명령으로 확인

방법 4. kubelet logs : `/var/log/syslog` or `journalctl -u kubelet | tail -5` 명령으로 확인

정리

일단 kubectl get pod -A가 안된다면(apiserver가 응답을 못하는 경우), control-plane 노드에 접속해서 kubelet 데몬 상태를 확인 해본다. 그 후 로그를 확인해 봤을 때 6443 포트를 사용하는 kube-apiserver의 문제가 있음을 확인하고, /var/log/pods 혹은 crictl 명령을 사용해 api-server의 로그를 확인하고, 해당 로그 메시지에 맞춰 문제 해결을 진행하자!

[devocen 오픈랩] kubernetes 스터디 1주 - 컨테이너 실습

junkmm — Mon, 13 May 2024 20:46:37 +0900

devocean 오픈랩 Deep Dive Kubernetes 1주차 기록입니다.

오프라인 미팅

5/7(화) 오후 7시 을지로 삼화타워에서 Deep Dive Kubernetes 팀의 오프라인 미팅을 진행했습니다. 스터디 운영자님이신 안승규님 께서 컨테이너와 쿠버네티스에 대한 설명을 진행 해 주셨는데요, 초반 컨테이너에 대한 이론 설명과 간단한 실습 자료를 보여주셨는데 시간관계상 실습을 진행하지 못했어서, 직접 실습 해보며 내용을 정리해보고자 합니다.

Container

Container의 구조

Host O/S 기반에 Container Engine이 컨테이너의 구동을 관리합니다. 컨테이너 엔진은 CPU, RAM, Disk자원을 컨테이너에 할당 시켜주고, 각 컨테이너를 격리하여 프로세스를 구동시킵니다. 컨테이너 엔진은 Host OS 위에서 동작하기 때문에, 컨테이너의 커널 사양에 따라 구동시키지 못하는 경우가 발생할 수 있습니다.

자원의 분배와 격리는 각 각 cgroup, namespace를 사용하여 구현합니다. 프로세스 단위로 격리시켜 컨테이너를 구동하기 때문에 컨테이너는 자신에 할당된 자원만큼만 사용할 수 있습니다. namespace에서 격리되는 자원의 정보는 다음과 같습니다.

호스트 네임 : `uts`
프로세스 ID : `pid`
유저 : `user`
네트워크 : `net`
스토리지 : `mnt`
프로세스간 통신 : `ipc`

실습 1. Container에 대한 기본개념 확인

아래는 init process인 pid 1번에 대한 네임스페이스 정보를 확인하는 명령어 입니다. init process도 네임스페이스를 가지고 있음을 확인해볼 수 있습니다. `echo $$`라는 명령을 실행시켜 `echo` 프로세스의 pid를 조회하고, 해당 pid의 네임스페이스를 확인해보면 init process와 동일한 네임스페이스를 사용중인 것을 확인해볼 수 있습니다.

# pid 1번에 대한 네임스페이스 조회
root@ip-172-31-37-95:~# lsns -p 1
        NS TYPE   NPROCS PID USER COMMAND
4026531834 time      105   1 root /sbin/init
4026531835 cgroup    105   1 root /sbin/init
4026531836 pid       105   1 root /sbin/init
4026531837 user      105   1 root /sbin/init
4026531838 uts        99   1 root /sbin/init
4026531839 ipc       105   1 root /sbin/init
4026531840 net       105   1 root /sbin/init
4026531841 mnt        96   1 root /sbin/init

# echo 명령어의 현재 pid 조회
root@ip-172-31-37-95:/proc# echo $$
1220

# echo 명령어 1220의 네임스페이스 조회
root@ip-172-31-37-95:/proc# lsns -p 1220
        NS TYPE   NPROCS PID USER COMMAND
4026531834 time      108   1 root /sbin/init
4026531835 cgroup    108   1 root /sbin/init
4026531836 pid       108   1 root /sbin/init
4026531837 user      108   1 root /sbin/init
4026531838 uts       102   1 root /sbin/init
4026531839 ipc       108   1 root /sbin/init
4026531840 net       108   1 root /sbin/init
4026531841 mnt        97   1 root /sbin/init

이번 실습으로 각 프로세스는 pid, user, uts 등 네임스페이스 단위로 자원을 할당받는 다는 점과, init process는 `/` 프로세스가 되어 OS단에서 실행되는 프로세스는 모두 init process와 동일한 네임스페이스를 사용한다는 점을 알 수 있었습니다.

실습 2. namespace 생성 - uts

아래는`unshare -u`라는 명령어로 namespace 중 uts를 격리하여 새로운 Child Process를 생성하는 실습입니다.

# pid 1220번 ps를 실행합니다.
root@ip-172-31-37-95:/proc# echo $$
1220

# unshare -u 명령으로 Child Bash Process를 생성합니다.
root@ip-172-31-37-95:/proc# unshare -u

# Child Bash에서 echo $$ 명령으로 ps를 생성합니다.
# 기존 1220 ps가 아닌 1304 ps가 생성됩니다.
root@ip-172-31-37-95:/proc# echo $$
1304

# lsns로 process의 네임스페이스를 비교합니다.
# Child Process인 1304번의 uts 네임스페이스만 달라진 걸 확인해볼 수 있습니다.
root@ip-172-31-37-95:/proc# lsns -p 1304
        NS TYPE   NPROCS   PID USER COMMAND
4026531834 time      107     1 root /sbin/init
4026531835 cgroup    107     1 root /sbin/init
4026531836 pid       107     1 root /sbin/init
4026531837 user      107     1 root /sbin/init
4026531839 ipc       107     1 root /sbin/init
4026531840 net       107     1 root /sbin/init
4026531841 mnt        98     1 root /sbin/init
4026532247 uts         2  1304 root -bash

root@ip-172-31-37-95:/proc# lsns -p 1220
        NS TYPE   NPROCS PID USER COMMAND
4026531834 time      107   1 root /sbin/init
4026531835 cgroup    107   1 root /sbin/init
4026531836 pid       107   1 root /sbin/init
4026531837 user      107   1 root /sbin/init
4026531838 uts        99   1 root /sbin/init
4026531839 ipc       107   1 root /sbin/init
4026531840 net       107   1 root /sbin/init
4026531841 mnt        98   1 root /sbin/init

위 실습으로 unshare는 네임스페이스 중 특정 자원을 격리시켜 Child Process를 생성할 수 있음을 확인 해 봤습니다.

실습 3. namespace 생성 - pid, mnt

아래는 pid, filesystem, mount 네임스페이스를 분리 생성하는 예시입니다. /root/sample_rootfs 라는 폴더를 생성하고, 해당 폴더에 `/bin`, `/lib`등 프로세스가 구동되기 위한 최소한의 파일시스템을 준비 합니다. 그리고 `unshare` 명령으로 mount를 격리시키고, 동시에 `chroot` 명령으로 격리된 프로세스의 파일시스템, 마운트 위치를 /root/sample_rootfs로 설정합니다. 그 후 proc을 /proc에 마운트 시켜 프로세스의 정보를 확인 해 봅니다.

먼저 /root/sample_rootfs를 생성하고 주요 directory를 복사합니다.

# root 로그인 상태에서 Home 디렉토리 이동 후 sample_rootfs 디렉토리를 생성합니다.
root@ip-172-31-37-95:~# cd
root@ip-172-31-37-95:~# mkdir sample_rootfs

# /bin, /lib, /var 등 주요 파일을 sample_rootfs에 복사합니다.
root@ip-172-31-37-95:~# cp -R /bin /root/sample_rootfs/
root@ip-172-31-37-95:~# cp -R /sbin /root/sample_rootfs/
root@ip-172-31-37-95:~# cp -R /lib /root/sample_rootfs/
root@ip-172-31-37-95:~# cp -R /lib64 /root/sample_rootfs/
root@ip-172-31-37-95:~# cp -R /etc /root/sample_rootfs/
root@ip-172-31-37-95:~# cp -R /usr /root/sample_rootfs/
root@ip-172-31-37-95:~# cp -R /var /root/sample_rootfs/

아래 명령으로 Process, Filesystem, Mount를 격리한 Child Process를 생성하고, Chroot로 격리된 파일시스템에 진입합니다. 그 후 프로세스 정보를 확인 합니다.

root@ip-172-31-37-95:~# unshare -p -f -m chroot /root/sample_rootfs

# pwd, ls 명령을 통해 chroot로 파일시스템, 마운트 격리가 잘 됐는지 확인합니다.
root@ip-172-31-37-95:/# pwd
/
root@ip-172-31-37-95:/# ls
bin  etc  lib  lib64  sbin  usr  var

# process 정보를 마운트 하기 위해 proc 폴더를 생성하고, proc 정보를 마운트 시킵니다.
root@ip-172-31-37-95:/# mkdir proc
root@ip-172-31-37-95:/# mount -t proc proc /proc

# lsns -1로 각 자원의 네임스페이스를 확인합니다.
root@ip-172-31-37-95:/# lsns -p 1
        NS TYPE   NPROCS PID USER COMMAND
4026531834 time        2   1 root /bin/bash -i
4026531835 cgroup      2   1 root /bin/bash -i
4026531837 user        2   1 root /bin/bash -i
4026531839 ipc         2   1 root /bin/bash -i
4026531840 net         2   1 root /bin/bash -i
4026532247 uts         2   1 root /bin/bash -i
4026532249 mnt         2   1 root /bin/bash -i
4026532250 pid         2   1 root /bin/bash -i

# ps -ef로 현재 구동중인 process 정보를 확인합니다.
root@ip-172-31-37-95:/# ps -ef
UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0  0 11:33 ?        00:00:00 /bin/bash -i
root          66       1  0 11:39 ?        00:00:00 ps -ef

# exit로 chroot를 빠져나온 뒤, Host OS의 process 정보를 확인 해봅니다.
root@ip-172-31-37-95:/proc# ps -ef
UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0  0 09:38 ?        00:00:04 /sbin/init
root           2       0  0 09:38 ?        00:00:00 [kthreadd]
root           3       2  0 09:38 ?        00:00:00 [pool_workqueue_release]
root           4       2  0 09:38 ?        00:00:00 [kworker/R-rcu_g]
...

이번 실습으로 unshare를 통한 프로세스의 네임스페이스 분리 방법과 process, filesystem 격리 시 구동중인 Host OS의 Process Namespace가 달라지게 되어 `ps -ef`명령을 했을 때 보여지는 정보가 상이했던 것을 확인할 수 있었고, 이를 통해 각 자원별 네임스페이스 분리는 결국 각 각의 프로세스의 격리를 의미한다는 것을 확인해 볼 수 있었습니다.

정리

[EKS] IaC

junkmm — Sat, 27 Apr 2024 19:42:36 +0900

이번 게시글은 가시다님의 AEWS [2기] 스터디 내용을 정리한 포스트 입니다.
이번 게시글은 8 주차의 스터디 내용인 EKS IaC에 대해 살펴봅니다.

Terraform

테라폼은 하시코프사에서 공개한 IaC 도구이다. Terraform Provider는 AWS, GCP, Azure등 다양한 벤더에 대한 배포를 지원한다. 사용자는 테라폼 1개의 문법으로 다양한 프로바이더를 사용하여 여러 벤더사의 클라우드 리소스 배포를 관리할 수 있다.

실습환경 준비

macOS 기준으로 설명합니다.

# tfenv 설치
brew install tfenv

# 설치 가능 버전 리스트 확인
tfenv list-remote

# 테라폼 1.5.1 버전 설치
tfenv install 1.8.1

# 테라폼 1.5.1 버전 사용 설정 
tfenv use 1.8.1

# tfenv로 설치한 버전 확인
tfenv list

# 테라폼 버전 정보 확인
terraform version

# 자동완성
terraform -install-autocomplete
## 참고 .zshrc 에 아래 추가됨
cat ~/.zshrc
autoload -U +X bashcompinit && bashcompinit
complete -o nospace -C /usr/local/bin/terraform terraform

#AWSCLI 설치
brew install awscli

#EKSCTL
brew install eksctl

#KUBECTL
brew install kubernetes-cli

#HELM
brew install helm

VSCode의 Extentions을 설치합니다.

`aws configure`를 구성한 뒤 아래 명령으로 default VPC가 존재하는지 확인합니다.

aws ec2 describe-vpcs --filter 'Name=isDefault,Values=true' | jq

만약 기본 VPC가 없으면 아래 명령으로 생성해야 합니다.

# default VPC를 생성
aws ec2 create-default-vpc

# default Subnet 생성
aws ec2 create-default-subnet --availability-zone ap-northeast-2a
aws ec2 create-default-subnet --availability-zone ap-northeast-2b
aws ec2 create-default-subnet --availability-zone ap-northeast-2c
aws ec2 create-default-subnet --availability-zone ap-northeast-2d

기본 환경을 준비합니다.

mkdir learn-terraform
cd learn-terraform
touch main.tf

Amazon Linux 2 최신 ami id를 찾습니다.

#aws ec2 describe-images --owners self amazon
aws ec2 describe-images --owners self amazon --query 'Images[*].[ImageId]' --output text
aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm-2.0.*-x86_64-gp2" "Name=state,Values=available"
aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm-2.0.*-x86_64-gp2" "Name=state,Values=available" --query 'Images|sort_by(@, &CreationDate)[-1].[ImageId, Name]' --output text
ami-0217b147346e48e84	amzn2-ami-hvm-2.0.20240412.0-x86_64-gp2

aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm-2.0.*-x86_64-gp2" "Name=state,Values=available" --query 'Images|sort_by(@, &CreationDate)[-1].[ImageId]' --output text
ami-0217b147346e48e84

AL2ID=`aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm-2.0.*-x86_64-gp2" "Name=state,Values=available" --query 'Images|sort_by(@, &CreationDate)[-1].[ImageId]' --output text`
echo $AL2ID

터미널 1개를 추가로 열고, 아래 명령으로 EC2 생성을 모니터링 합니다.

# [터미널1] EC2 생성 모니터링
export AWS_PAGER=""
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

테라폼 코드를 작성합니다. HCL 이라고 부르며, Block 단위로 구성되어 있습니다. 아래는 2개의 블록으로 이루어 져 있습니다. Provider는 배포할 타겟의 클라우드 환경을 설정한다고 이해하면 됩니다, resource는 실제 배포할 인프라 자원을 의미합니다.

cat <<EOT > main.tf
provider "aws" {
  region = "ap-northeast-2"
}

resource "aws_instance" "example" {
  ami           = "$AL2ID"
  instance_type = "t2.micro"
}
EOT

Terraform 배포를 진행합니다.

# 초기화
terraform init
ls -al
tree .terraform

# plan 확인
terraform plan

# apply 실행
terraform apply
 Enter a value: yes 입력

AWS cli에서 아래처럼 EC2 list를 확인해볼 수 있습니다. 테라폼을 통해서 EC2 인스턴스를 배포해 보았습니다.

`terraform show` 명령을 통해서도 테라폼에 의해 배포된 리소스 정보를 확인해볼 수 있습니다.

현재 배포되어있는 EC2의 태그정보를 수정해 봅니다.

cat <<EOT > main.tf
provider "aws" {
  region = "ap-northeast-2"
}

resource "aws_instance" "example" {
  ami           = "$AL2ID"
  instance_type = "t2.micro"

  tags = {
    Name = "aews-study"
  }

}
EOT

`terraform plan`후 `terraform apply`를 통해 배포를 실행 해 봅니다. terraform plan의 결과를 보면 In-place 방식으로 업데이트 된다고 안내되어 있어, 배포된 리소스의 중지 없이 배포할 수 있음을 알 수 있습니다.

erraform plan
aws_instance.example: Refreshing state... [id=i-0fe9e466fca30f1cc]

Terraform used the selected providers to
generate the following execution plan. Resource
actions are indicated with the following
symbols:
  ~ update in-place

Terraform will perform the following actions:

  # aws_instance.example will be updated in-place
  ~ resource "aws_instance" "example" {
        id                                   = "i-0fe9e466fca30f1cc"
      ~ tags                                 = {
          + "Name" = "aews-study"
        }
      ~ tags_all                             = {
          + "Name" = "aews-study"
        }
        # (30 unchanged attributes hidden)

        # (8 unchanged blocks hidden)
    }

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

───────────────────────────────────────────────

Note: You didn't use the -out option to save
this plan, so Terraform can't guarantee to take
exactly these actions if you run "terraform
apply" now.

`terraform apply`에 성공하면 아래처럼 EC2 리소스에 name이 확인되는것을 볼 수 있습니다.

`terraform destoy`를 통해 삭제합니다.

[HCL의 표현식 참고]

// 한줄 주석 방법1
# 한줄 주석 방법2

/*
라인
주석
*/

locals {
  key1     = "value1"     # = 를 기준으로 키와 값이 구분되며
  myStr    = "TF ♡ UTF-8" # UTF-8 문자를 지원한다.
  multiStr = <<EOF
  Multi
  Line
  String
  with anytext
EOF

  boolean1    = true   # boolean true
  boolean2    = false  # boolean false를 지원한다.
  deciaml     = 123    # 기본적으로 숫자는 10진수,
  octal       = 0123   # 0으로 시작하는 숫자는 8진수,
  hexadecimal = "0xD5" # 0x 값을 포함하는 스트링은 16진수,
  scientific  = 1e10   # 과학표기 법도 지원한다.

  # funtion 호출 예
  myprojectname = format("%s is myproject name", var.project)

  # 3항 연산자 조건문을 지원한다.
  credentials = var.credentials == "" ? file(var.credentials_file) : var.credentials
}

Terraform Version

테라폼 내에서 버전이 명시되는 terraform, module에서 사용 가능하며 버전에 대한 제약을 둠으로써 언제 실행하든 항상 의도한 정의대로 실행되는 것을 목적으로 합니다.

terraform {
  required_version = "~> 1.3.0" # 테라폼 버전

  required_providers { # 프로바이더 버전을 나열
    random = {
      version = ">= 3.0.0, < 3.1.0"
    }
    aws = {
      version = "4.2.0"
    }
  }

  cloud { # Cloud/Enterprise 같은 원격 실행을 위한 정보
    organization = "<MY_ORG_NAME>"
    workspaces {
      name = "my-first-workspace"
    }
  }

  backend "local" { # state를 보관하는 위치를 지정
    path = "relative/path/to/terraform.tfstate"
  }
}

프로바이더의 버전도 각 벤더 별 상이하게 적용할 수 있습니다. 테라폼 0.13 버전 이전에서는 provider 블록에 함께 버전을 명시했지만, 해당 버전 이후 provider 버전은 terraform 블록에서 required_providers에 정의합니다.

리소스 구성 실습을 진행합니다. 신규 디렉터리를 생성하고 main.tf 파일을 생성합니다.

cd ..
mkdir 2
cd 2

리소스 블록은 resource로 시작합니다. 이후 리소스 블록이 생성할 리소스 유형을 정의합니다. 리소스 유형에는 "프로바이더 이름_제공 리소스 유형" 으로 선언할 수 있습니다.

resource "<리소스 유형>" "<이름>" {
  <인수> = <값>
}

resource "local_file" "abc" {
  content  = "123"
  filename = "${path.module}/abc.txt"
}

main.tf 파일에 아래 내용을 붙여넣고 `terraform init`을 입력합니다.

resource "local_file" "abc" {
  content  = "123"
  filename = "${path.module}/abc.txt"
}

resource "aws_instance" "web" {
  ami = "ami-a1b2c3d4"
  instance_type = "t2.micro"  
}

현재 디렉터리에 숨김 폴더로 .terraform 폴더가 생성되고, 하위에 local과 aws에 관한 provider 다운이 자동으로 된 것을 확인해볼 수 있습니다.

테라폼의 종속성은 resource, module 선언으로 프로비저닝 되는 각 요소의 생성 순서를 자동으로 구분 짓습니다. 관리자가 별도의 종속성을 적용해야 하는 경우 depends_on을 활용해야 합니다.

아래 코드로 main.tf를 수정합니다.

resource "local_file" "abc" {
  content  = "123!"
  filename = "${path.module}/abc.txt"
}

resource "local_file" "def" {
  content  = "456!"
  filename = "${path.module}/def.txt"
}

`terraform apply -auto-approve`를 진행합니다. abc.txt와 def.txt가 생성된 것을 볼 수 있습니다.

`terraform graph > graph-1.dot`명령을 통해 종속성 확인을 해봅니다.

현재는 두개의 resource에 별다른 종속성이 없습니다.

모든 리소스를 제거해 봅니다.

terraform destroy -auto-approve
ls *.txt
terraform state list

리소스 참조값을 설정해 두 개의 리소스 간 암시적 종속성을 부여합니다.

resource "local_file" "abc" {
  content  = "123!"
  filename = "${path.module}/abc.txt"
}

resource "local_file" "def" {
  content  = local_file.abc.content
  filename = "${path.module}/def.txt"
}

`terraform apply -auto-approve`를 통해 배포합니다. 그 후 `terraform graph > graph-2.dot` 명령으로 종속성을 확인해 봅니다.

위와 동일하게 terraform 삭제 후 depends_on으로 명시적인 종속성을 적용해도 동일한 결과가 나옵니다. 원래는 def 리소스가 병렬로 실행되어 별도 종속성이 없어야 하지만 depends_on의 옵션으로 인해 abc가 생성된 뒤 def가 생성되게 됩니다.

resource "local_file" "abc" {
  content  = "123!"
  filename = "${path.module}/abc.txt"
}

resource "local_file" "def" {
  depends_on = [
    local_file.abc
  ]

  content  = "456!"
  filename = "${path.module}/def.txt"
}

리소스 속성 참조는 배포된 리소스의 속성 SG의 ID 같은 정보를 참조할 수 있는 기능입니다. 아래 예시는 namesapce를 생성하고, secret을 배포할 때, Terraform에 의해 배포된 namespace의 이름을 사용하는 예시 입니다.

resource "kubernetes_namespace" "example" {
  metadata {
    annotations = {
      name = "example-annotation"
    }
    name = "terraform-example-namespace"
  }
}

resource "kubernetes_secret" "example" {
  metadata {
    namespace = kubernetes_namespace.example.metadata.0.name # namespace 리소스 인수 참조
    name      = "terraform-example"
  }
  data = {
    password = "P4ssw0rd"
  }
}

데이터 소스 구성은 테라폼으로 정의되지 않은 외부 리소스 또는 저장된 정보를 테라폼 내에서 참조할 때 사용합니다.

resource "local_file" "abc" {
  content  = "123!"
  filename = "${path.module}/abc.txt"
}

data "local_file" "abc" {
  filename = local_file.abc.filename
}

resource "local_file" "def" {
  content  = data.local_file.abc.content
  filename = "${path.module}/def.txt"
}

위 코드를 `terraform apply`하면 아래와 같은 종속관계를 가집니다.

아래 data 블록을 신규 추가하고 `terraform apply`를 재실행 합니다.

data "aws_availability_zones" "available" {
  state = "available"
}

`terraform console`로 외부 data의 정보를 확인해볼 수 있습니다.

변수 선언 방식으로는 입력 변수의 경우 인프라를 구성하는 데 필요한 속성 값을 정의해 코드의 변경 없이 여러 인프라를 생성하는 데 목적이 있습니다. 테라폼에서는 이것을 입력 변수로 정의합니다.

variable "string" {
  type        = string
  description = "var String"
  default     = "myString"
}

variable "number" {
  type    = number
  default = 123
}

variable "boolean" {
  default = true
}

variable "list" {
  default = [
    "google",
    "vmware",
    "amazon",
    "microsoft"
  ]
}

output "list_index_0" {
  value = var.list.0
}

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

variable "map" { # Sorting
  default = {
    aws   = "amazon",
    azure = "microsoft",
    gcp   = "google"
  }
}

variable "set" { # Sorting
  type = set(string)
  default = [
    "google",
    "vmware",
    "amazon",
    "microsoft"
  ]
}

variable "object" {
  type = object({ name = string, age = number })
  default = {
    name = "abc"
    age  = 12
  }
}

variable "tuple" {
  type    = tuple([string, number, bool])
  default = ["abc", 123, true]
}

variable "ingress_rules" { # optional ( >= terraform 1.3.0)
  type = list(object({
    port        = number,
    description = optional(string),
    protocol    = optional(string, "tcp"),
  }))
  default = [
    { port = 80, description = "web" },
  { port = 53, protocol = "udp" }]
}

생성한 변수의 참조는 var."name" 방식으로 참조할 수 있습니다.

variable "my_password" {}

resource "local_file" "abc" {
  content  = var.my_password
  filename = "${path.module}/abc.txt"
}

VPC 배포 실습

신규 디렉터리 생성

# 신규 디렉터리 생성
mkdir my-vpc-ec2
cd my-vpc-ec2

vpc.tf

provider "aws" {
  region  = "ap-northeast-2"
}

resource "aws_vpc" "myvpc" {
  cidr_block       = "10.10.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "t101-study"
  }
}

resource "aws_subnet" "mysubnet1" {
  vpc_id     = aws_vpc.myvpc.id
  cidr_block = "10.10.1.0/24"

  availability_zone = "ap-northeast-2a"

  tags = {
    Name = "t101-subnet1"
  }
}

resource "aws_subnet" "mysubnet2" {
  vpc_id     = aws_vpc.myvpc.id
  cidr_block = "10.10.2.0/24"

  availability_zone = "ap-northeast-2c"

  tags = {
    Name = "t101-subnet2"
  }
}


resource "aws_internet_gateway" "myigw" {
  vpc_id = aws_vpc.myvpc.id

  tags = {
    Name = "t101-igw"
  }
}

resource "aws_route_table" "myrt" {
  vpc_id = aws_vpc.myvpc.id

  tags = {
    Name = "t101-rt"
  }
}

resource "aws_route_table_association" "myrtassociation1" {
  subnet_id      = aws_subnet.mysubnet1.id
  route_table_id = aws_route_table.myrt.id
}

resource "aws_route_table_association" "myrtassociation2" {
  subnet_id      = aws_subnet.mysubnet2.id
  route_table_id = aws_route_table.myrt.id
}

resource "aws_route" "mydefaultroute" {
  route_table_id         = aws_route_table.myrt.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id             = aws_internet_gateway.myigw.id
}

output "aws_vpc_id" {
  value = aws_vpc.myvpc.id
}

배포

# 배포
terraform plan && terraform apply -auto-approve
terraform state list
aws_internet_gateway.myigw
aws_route.mydefaultroute
aws_route_table.myrt
aws_route_table_association.myrtassociation1
aws_route_table_association.myrtassociation2
aws_subnet.mysubnet1
aws_subnet.mysubnet2
aws_vpc.myvpc

terraform state show aws_route.mydefaultroute

# graph 확인 > graph.dot 파일 선택 후 오른쪽 상단 DOT 클릭
terraform graph > graph.dot

# 라우팅 테이블 확인
#aws ec2 describe-route-tables --filters 'Name=tag:Name,Values=t101-rt' --query 'RouteTables[].Associations[].SubnetId'
aws ec2 describe-route-tables --filters 'Name=tag:Name,Values=t101-rt' --output table

보안그룹과 EC2를 배포해 봅니다. sg.tf, ec2.tf

resource "aws_security_group" "mysg" {
  vpc_id      = aws_vpc.myvpc.id
  name        = "T101 SG"
  description = "T101 Study SG"
}

resource "aws_security_group_rule" "mysginbound" {
  type              = "ingress"
  from_port         = 80
  to_port           = 80
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = aws_security_group.mysg.id
}

resource "aws_security_group_rule" "mysgoutbound" {
  type              = "egress"
  from_port         = 0
  to_port           = 0
  protocol          = "-1"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = aws_security_group.mysg.id
}

data "aws_ami" "my_amazonlinux2" {
  most_recent = true
  filter {
    name   = "owner-alias"
    values = ["amazon"]
  }

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-ebs"]
  }

  owners = ["amazon"]
}

resource "aws_instance" "myec2" {

  depends_on = [
    aws_internet_gateway.myigw
  ]

  ami                         = data.aws_ami.my_amazonlinux2.id
  associate_public_ip_address = true
  instance_type               = "t2.micro"
  vpc_security_group_ids      = ["${aws_security_group.mysg.id}"]
  subnet_id                   = aws_subnet.mysubnet1.id

  user_data = <<-EOF
              #!/bin/bash
              wget https://busybox.net/downloads/binaries/1.31.0-defconfig-multiarch-musl/busybox-x86_64
              mv busybox-x86_64 busybox
              chmod +x busybox
              echo "Web Server</h1>" > index.html
              nohup ./busybox httpd -f -p 80 &
              EOF

  user_data_replace_on_change = true

  tags = {
    Name = "t101-myec2"
  }
}

output "myec2_public_ip" {
  value       = aws_instance.myec2.public_ip
  description = "The public IP of the Instance"
}

배포 확인

# 
ls *.tf
terraform plan && terraform apply -auto-approve
terraform state list
data.aws_ami.my_amazonlinux2
aws_instance.myec2
...

terraform state show data.aws_ami.my_amazonlinux2
terraform state show aws_instance.myec2

# 데이터소스 값 확인
terraform console
> 
data.aws_ami.my_amazonlinux2.id
"ami-01c81850a6167bb81"
data.aws_ami.my_amazonlinux2.image_id
data.aws_ami.my_amazonlinux2.name
data.aws_ami.my_amazonlinux2.owners
data.aws_ami.my_amazonlinux2.platform_details
data.aws_ami.my_amazonlinux2.hypervisor
data.aws_ami.my_amazonlinux2.architecture
exit

# graph 확인 > graph.dot 파일 선택 후 오른쪽 상단 DOT 클릭
terraform graph > graph.dot

# 출력된 EC2 퍼블릭IP로 cul 접속 확인
terraform output -raw myec2_public_ip
3.35.214.63

MYIP=$(terraform output -raw myec2_public_ip)
while true; do curl --connect-timeout 1  http://$MYIP/ ; echo "------------------------------"; date; sleep 1; done

삭제 : `terraform destroy -auto-approve`

단일 프로바이더의 다중 정의도 적용할 수 있습니다. 아래 예제는 리전을 다르게 구성한 AWS 프로바이더를 aws_instance에 지정하는 예시입니다.

provider "aws" {
  region = "ap-southeast-1"
}

provider "aws" {
  alias = "seoul"
  region = "ap-northeast-2"
}

resource "aws_instance" "app_server1" {
  ami           = "ami-06b79cf2aee0d5c92"
  instance_type = "t2.micro"
}

resource "aws_instance" "app_server2" {
  provider      = aws.seoul
  ami           = "ami-0ea4d4b8dc1e46212"
  instance_type = "t2.micro"
}

모듈의 경우 테라폼으로 관리하는데 시간이 지날수록 구성이 복잡해지고, 관리하는 리소스가 늘어가게 되는데 모듈은 테라폼 구성의 집합으로 구성해 두어 관리 및 재사용에 용이하도록 합니다. 새로운 폴더를 생성하고 main.tf를 작성합니다.

# main.tf
resource "random_pet" "name" {
  keepers = {
    ami_id = timestamp()
  }
}

resource "random_password" "password" {
  length           = var.isDB ? 16 : 10
  special          = var.isDB ? true : false
  override_special = "!#$%*?"
}

# variable.tf
variable "isDB" {
  type        = bool
  default     = false
  description = "패스워드 대상의 DB 여부"
}

# output.tf
output "id" {
  value = random_pet.name.id
}

output "pw" {
  value = nonsensitive(random_password.password.result) 
}

실행

#
terraform init && terraform plan

# 테스트를 위해 apply 시 변수 지정
terraform apply -auto-approve -var=isDB=true
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
Outputs:
id = "pleased-ghost"
pw = "5Iq3*liXG*DWGkOp"

# 확인
terraform state list
terraform state show random_pet.name
terraform state show random_password.password

# tfstate에 모듈 정보 확인
cat terraform.tfstate | grep module

# graph 확인
terraform graph > graph.dot

자식 모듈 호출을 확인해 봅니다. module을 통해 위에서 정의한 리소스를 재사용합니다. 새로운 폴더를 만들고 main.tf를 생성합니다.

module "mypw1" {
  source = "../modules/terraform-random-pwgen"
}

module "mypw2" {
  source = "../modules/terraform-random-pwgen"
  isDB   = true
}

output "mypw1" {
  value  = module.mypw1
}

output "mypw2" {
  value  = module.mypw2
}

확인

#
cd 06-module-traning/06-01-basic

#
terraform init && terraform plan && terraform apply -auto-approve
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
Outputs:

mypw1 = {
  "id" = "sure-coral"
  "pw" = "W4zEVZ1wXK"
}
mypw2 = {
  "id" = "adapted-troll"
  "pw" = "4WXyjq*o3M6xIg5l"
}

# 확인
terraform state list

# tfstate에 모듈 정보 확인
cat terraform.tfstate | grep module

# terraform init 시 생성되는 modules.json 파일 확인
tree .terraform
.terraform
├── modules
│   └── modules.json
...

## 모듈로 묶여진 리소스는 module이라는 정의를 통해 단순하게 재활용하고 반복 사용할 수 있다.
## 모듈의 결과 참조 형식은 module.<모듈 이름>.<output 이름>으로 정의된다.
cat .terraform/modules/modules.json | jq
{
  "Modules": [
    {
      "Key": "",
      "Source": "",
      "Dir": "."
    },
    {
      "Key": "mypw1",
      "Source": "../4",
      "Dir": "../4"
    },
    {
      "Key": "mypw2",
      "Source": "../4",
      "Dir": "../4"
    }
  ]
}

# graph 확인
terraform graph > graph.dot

Terraform EKS 배포

# 코드 가져오기
git clone https://github.com/gasida/aews-cicd.git
cd aews-cicd/4

# terraform 환경 변수 저장
export TF_VAR_KeyName=[각자 ssh keypair]
export TF_VAR_KeyName='hj42700eks'
echo $TF_VAR_KeyName

# 
terraform init
terraform plan

# 10분 후 배포 완료
terraform apply -auto-approve

vpc.tf

provider "aws" {
  region = var.TargetRegion
}

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~>5.7"

  name = "${var.ClusterBaseName}-VPC"
  cidr = var.VpcBlock
  azs  = var.availability_zones

  enable_dns_support   = true
  enable_dns_hostnames = true

  public_subnets  = var.public_subnet_blocks
  private_subnets = var.private_subnet_blocks

  enable_nat_gateway = true
  single_nat_gateway = true
  one_nat_gateway_per_az = false
  
  map_public_ip_on_launch = true
 
  igw_tags = {
    "Name" = "${var.ClusterBaseName}-IGW"
  }
 
  nat_gateway_tags = {
    "Name" = "${var.ClusterBaseName}-NAT"
  }
 
  public_subnet_tags = {
    "Name"                     = "${var.ClusterBaseName}-PublicSubnet"
    "kubernetes.io/role/elb"   = "1"
  }

  private_subnet_tags = {
    "Name"                             = "${var.ClusterBaseName}-PrivateSubnet"
    "kubernetes.io/role/internal-elb" = "1"
  }

  tags = {
    "Environment" = "${var.ClusterBaseName}-lab"
  }
}

var.tf

variable "KeyName" {
  description = "Name of an existing EC2 KeyPair to enable SSH access to the instances."
  type        = string
}

variable "ClusterBaseName" {
  description = "Base name of the cluster."
  type        = string
  default     = "myeks"
}

variable "KubernetesVersion" {
  description = "Kubernetes version for the EKS cluster."
  type        = string
  default     = "1.29"
}

variable "WorkerNodeInstanceType" {
  description = "EC2 instance type for the worker nodes."
  type        = string
  default     = "t3.medium"
}

variable "WorkerNodeCount" {
  description = "Number of worker nodes."
  type        = number
  default     = 3
}

variable "WorkerNodeVolumesize" {
  description = "Volume size for worker nodes (in GiB)."
  type        = number
  default     = 30
}

variable "TargetRegion" {
  description = "AWS region where the resources will be created."
  type        = string
  default     = "ap-northeast-2"
}

variable "availability_zones" {
  description = "List of availability zones."
  type        = list(string)
  default     = ["ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c"]
}

variable "VpcBlock" {
  description = "CIDR block for the VPC."
  type        = string
  default     = "192.168.0.0/16"
}

variable "public_subnet_blocks" {
  description = "List of CIDR blocks for the public subnets."
  type        = list(string)
  default     = ["192.168.1.0/24", "192.168.2.0/24", "192.168.3.0/24"]
}

variable "private_subnet_blocks" {
  description = "List of CIDR blocks for the private subnets."
  type        = list(string)
  default     = ["192.168.11.0/24", "192.168.12.0/24", "192.168.13.0/24"]
}

eks.tf

data "aws_caller_identity" "current" {}

resource "aws_iam_policy" "external_dns_policy" {
  name        = "${var.ClusterBaseName}ExternalDNSPolicy"
  description = "Policy for allowing ExternalDNS to modify Route 53 records"

  policy = jsonencode({
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "route53:ChangeResourceRecordSets"
        ],
        "Resource": [
          "arn:aws:route53:::hostedzone/*"
        ]
      },
      {
        "Effect": "Allow",
        "Action": [
          "route53:ListHostedZones",
          "route53:ListResourceRecordSets"
        ],
        "Resource": [
          "*"
        ]
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "external_dns_policy_attach" {
  role       = "${var.ClusterBaseName}-node-group-eks-node-group"
  policy_arn = aws_iam_policy.external_dns_policy.arn

  depends_on = [module.eks]
}

resource "aws_security_group" "node_group_sg" {
  name        = "${var.ClusterBaseName}-node-group-sg"
  description = "Security group for EKS Node Group"
  vpc_id      = module.vpc.vpc_id

  tags = {
    Name = "${var.ClusterBaseName}-node-group-sg"
  }
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~>20.0"

  cluster_name = var.ClusterBaseName
  cluster_version = var.KubernetesVersion
  cluster_endpoint_private_access = false
  cluster_endpoint_public_access  = true

  cluster_addons = {
    coredns = {
      most_recent = true
    }
    kube-proxy = {
      most_recent = true
    }
    vpc-cni = {
      most_recent = true
    }
  }

  vpc_id = module.vpc.vpc_id
  enable_irsa = true
  subnet_ids = module.vpc.public_subnets

  eks_managed_node_groups = {
    default = {
      name             = "${var.ClusterBaseName}-node-group"
      use_name_prefix  = false
      instance_type    = var.WorkerNodeInstanceType
      desired_size     = var.WorkerNodeCount
      max_size         = var.WorkerNodeCount + 2
      min_size         = var.WorkerNodeCount - 1
      disk_size        = var.WorkerNodeVolumesize
      subnets          = module.vpc.public_subnets
      key_name         = var.KeyName
      vpc_security_group_ids = [aws_security_group.node_group_sg.id]
      iam_role_name    = "${var.ClusterBaseName}-node-group-eks-node-group"
      iam_role_use_name_prefix = false
      iam_role_additional_policies = {
        "${var.ClusterBaseName}ExternalDNSPolicy" = aws_iam_policy.external_dns_policy.arn
      }
   }
  }

  access_entries = {
    admin = {
      kubernetes_groups = []
      principal_arn     = "${data.aws_caller_identity.current.arn}"

      policy_associations = {
        myeks = {
          policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
          access_scope = {
            namespaces = []
            type       = "cluster"
          }
        }
      }
    }
  }

  tags = {
    Environment = "${var.ClusterBaseName}-lab"
    Terraform   = "true"
  }
}

irsa.tf

locals {
  cluster_oidc_issuer_arn = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:oidc-provider/${replace(module.eks.cluster_oidc_issuer_url, "https://", "")}"
}

module "eks-external-dns" {
  source = "DNXLabs/eks-external-dns/aws"
  version = "0.2.0"

  cluster_name                     = var.ClusterBaseName
  cluster_identity_oidc_issuer     = module.eks.cluster_oidc_issuer_url
  cluster_identity_oidc_issuer_arn = local.cluster_oidc_issuer_arn

  enabled = false

}

module "aws_load_balancer_controller_irsa_role" {
  source  = "terraform-aws-modules/iam/aws//modules/iam-role-for-service-accounts-eks"
  version = "5.3.1"

  role_name = "${var.ClusterBaseName}-aws-load-balancer-controller"

  attach_load_balancer_controller_policy = true

  oidc_providers = {
    ex = {
      provider_arn               = module.eks.oidc_provider_arn
      namespace_service_accounts = ["kube-system:aws-load-balancer-controller"]
    }
  }
}

provider "kubernetes" {
  host                   = module.eks.cluster_endpoint
  token                  = data.aws_eks_cluster_auth.cluster.token
  cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)
}

data "aws_eks_cluster" "cluster" {
  name = module.eks.cluster_name
  depends_on = [module.eks]
}

data "aws_eks_cluster_auth" "cluster" {
  name = module.eks.cluster_name
  depends_on = [module.eks]
}

resource "kubernetes_service_account" "aws_lb_controller" {
  metadata {
    name      = "aws-load-balancer-controller"
    namespace = "kube-system"
    annotations = {
      "eks.amazonaws.com/role-arn" = module.aws_load_balancer_controller_irsa_role.iam_role_arn
    }
  }
}

배포 정보 확인

#
kubectl get node -v=6

# EKS 클러스터 인증 정보 업데이트
CLUSTER_NAME=myeks
aws eks update-kubeconfig --region ap-northeast-2 --name $CLUSTER_NAME
kubectl config rename-context "arn:aws:eks:ap-northeast-2:$(aws sts get-caller-identity --query 'Account' --output text):cluster/$CLUSTER_NAME" "Aews-Labs"

#
kubectl cluster-info
kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone
kubectl get pod -A

기타 설치

# ExternalDNS
MyDomain=<자신의 도메인>
MyDomain=junkmm.site
MyDnzHostedZoneId=$(aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text)
echo $MyDomain, $MyDnzHostedZoneId
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/aews/externaldns.yaml
MyDomain=$MyDomain MyDnzHostedZoneId=$MyDnzHostedZoneId envsubst < externaldns.yaml | kubectl apply -f -

# kube-ops-view
helm repo add geek-cookbook https://geek-cookbook.github.io/charts/
helm install kube-ops-view geek-cookbook/kube-ops-view --version 1.2.2 --set env.TZ="Asia/Seoul" --namespace kube-system
kubectl patch svc -n kube-system kube-ops-view -p '{"spec":{"type":"LoadBalancer"}}'
kubectl annotate service kube-ops-view -n kube-system "external-dns.alpha.kubernetes.io/hostname=kubeopsview.$MyDomain"
echo -e "Kube Ops View URL = http://kubeopsview.$MyDomain:8080/#scale=1.5"

# AWS LB Controller
helm repo add eks https://aws.github.io/eks-charts
helm repo update
helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=$CLUSTER_NAME \
  --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller

# gp3 스토리지 클래스 생성
kubectl apply -f https://raw.githubusercontent.com/gasida/PKOS/main/aews/gp3-sc.yaml

두 번째 EKS 를 배포합니다.

#
cd ..
mkdir 5
cd 5
cp ../4/*.tf .
ls

#
terraform init
terraform apply -auto-approve -var=ClusterBaseName=myeks2 -var=KubernetesVersion="1.28"

# EKS 클러스터 인증 정보 가져오기
CLUSTER_NAME2=myeks2
aws eks update-kubeconfig --region ap-northeast-2 --name $CLUSTER_NAME2 --kubeconfig ./myeks2config

# EKS 클러스터 정보 확인
kubectl --kubeconfig ./myeks2config get node 
kubectl --kubeconfig ./myeks2config get pod -A

삭제

# CLB는 terraform으로 배포하지 않고 직접 수동으로 배포되었으니, 수동으로 삭제를 해주어야 함
helm uninstall kube-ops-view --namespace kube-system

# 클러스터 삭제
terraform destroy -auto-approve

[k8s] Pod의 전략적 배치 - Node Affinity

junkmm — Wed, 17 Apr 2024 18:48:50 +0900

개요

쿠버네티스 환경에서 Pod를 특정 워커 노드에 배치하는 방법을 정리합니다.

구조도

frontend Appilication은 Worker Node 1,3에 backend Application은 Worker Node 2,4에 배치시키려 합니다.

노드에 Label 추가하기

1. 클러스터의 노드 Label 확인

kubectl get nodes --show-labels

결과

NAME                                               STATUS   ROLES    AGE   VERSION               LABELS
ip-10-100-39-3.ap-northeast-3.compute.internal   Ready    <none>   52m   v1.28.5-eks-5e0fdde   ...,kubernetes.io/host=worker1
ip-10-100-42-191.ap-northeast-3.compute.internal   Ready    <none>   52m   v1.28.5-eks-5e0fdde   ...,kubernetes.io/host=worker2
ip-10-100-46-137.ap-northeast-3.compute.internal   Ready    <none>   52m   v1.28.5-eks-5e0fdde   ...,kubernetes.io/host=worker3
ip-10-100-49-146.ap-northeast-3.compute.internal   Ready    <none>   52m   v1.28.5-eks-5e0fdde   ...,kubernetes.io/host=worker4
ip-10-100-50-238.ap-northeast-3.compute.internal   Ready    <none>   52m   v1.28.5-eks-5e0fdde   ...,kubernetes.io/host=worker5

2. 특정 노드에 Label을 추가합니다. 워커노드 2대씩 `tier=front`, `tier=back`으로 할당합니다.

kubectl label nodes ip-10-100-39-3.ap-northeast-3.compute.internal tier=front
kubectl label nodes ip-10-100-42-191.ap-northeast-3.compute.internal tier=front
kubectl label nodes ip-10-100-46-137.ap-northeast-3.compute.internal tier=back
kubectl label nodes ip-10-100-49-146.ap-northeast-3.compute.internal tier=back

3. 워커 노드에 Label이 잘 적용 되었는지 확인합니다.

kubectl get nodes --show-labels

결과

NAME                                               STATUS   ROLES    AGE   VERSION               LABELS
ip-10-100-39-3.ap-northeast-3.compute.internal   Ready    <none>   52m   v1.28.5-eks-5e0fdde   ...,tier=front
ip-10-100-42-191.ap-northeast-3.compute.internal   Ready    <none>   52m   v1.28.5-eks-5e0fdde   ...,tier=front
ip-10-100-46-137.ap-northeast-3.compute.internal   Ready    <none>   52m   v1.28.5-eks-5e0fdde   ...,tier=back
ip-10-100-49-146.ap-northeast-3.compute.internal   Ready    <none>   52m   v1.28.5-eks-5e0fdde   ...,tier=back
ip-10-100-50-238.ap-northeast-3.compute.internal   Ready    <none>   52m   v1.28.5-eks-5e0fdde   ...,kubernetes.io/host=worker5

Node Affinity

Required Affinity

Required Affinity는 Pod가 특정 Label이 있는 노드에만 스케줄되어야 할 때 사용합니다. 아래는 총 2개의 Statefulset을 배포하는 Yaml파일 이고, front Pod는 `requiredDuringSchedulingIgnoredDuringExecution` 옵션을 통해 nginx-front Statefulset은 `tier=front` 라벨이 적용된 워커노드에만 배포하고 , nginx-back Statefulset은 `tier=back` 라벨이 적용된 워커노드에만 배포하게 됩니다.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx-front
spec:
  replicas: 2
  serviceName: nginx-front
  selector:
    matchLabels:
      app: nginx-front
  template:
    metadata:
      labels:
        app: nginx-front
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: tier
                operator: In
                values:
                - front
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx-back
spec:
  replicas: 2
  serviceName: nginx-back
  selector:
    matchLabels:
      app: nginx-back
  template:
    metadata:
      labels:
        app: nginx-back
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: tier
                operator: In
                values:
                - back
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent

위 yaml 파일을 배포하면 아래와 같이 front Statefulset은 `tier=front` Label을 가지고 있는 워커노드, back Statefulset은 `tier=back` Label을 가지고 있는 워커노드에 배치된 것을 확인할 수 있습니다.

배포

kubectl apply -f Nodeaffinity.yaml

확인

kubectl get pod -o wide

결과

NAME            READY   STATUS    RESTARTS   AGE   IP              NODE                                               NOMINATED NODE   READINESS GATES
nginx-back-0    1/1     Running   0          19s   10.100.32.197   ip-10-100-46-137.ap-northeast-3.compute.internal   <none>           <none>
nginx-back-1    1/1     Running   0          18s   10.100.61.48    ip-10-100-49-146.ap-northeast-3.compute.internal   <none>           <none>
nginx-front-0   1/1     Running   0          19s   10.100.33.132   ip-10-100-39-3.ap-northeast-3.compute.internal     <none>           <none>
nginx-front-1   1/1     Running   0          18s   10.100.32.87    ip-10-100-42-191.ap-northeast-3.compute.internal   <none>           <none>

Preferred Affinity

Preferred Affinity는 Pod를 배포할 때 특정 Label이 있는 노드를 선호한다는 것을 의미합니다.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx-front
spec:
  replicas: 2
  serviceName: nginx-front
  selector:
    matchLabels:
      app: nginx-front
  template:
    metadata:
      labels:
        app: nginx-front
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: tier
                operator: In
                values:
                - front
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx-back
spec:
  replicas: 2
  serviceName: nginx-back
  selector:
    matchLabels:
      app: nginx-back
  template:
    metadata:
      labels:
        app: nginx-back
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: tier
                operator: In
                values:
                - back
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent

kubectl apply -f Nodeaffinity_preferrd.yaml

확인

kubectl get pod -o wide

결과

NAME            READY   STATUS    RESTARTS   AGE   IP              NODE                                               NOMINATED NODE   READINESS GATES
nginx-back-0    1/1     Running   0          30s   10.100.45.24    ip-10-100-46-137.ap-northeast-3.compute.internal   <none>           <none>
nginx-back-1    1/1     Running   0          29s   10.100.52.149   ip-10-100-49-146.ap-northeast-3.compute.internal   <none>           <none>
nginx-front-0   1/1     Running   0          30s   10.100.34.117   ip-10-100-39-3.ap-northeast-3.compute.internal     <none>           <none>
nginx-front-1   1/1     Running   0          30s   10.100.39.16    ip-10-100-42-191.ap-northeast-3.compute.internal   <none>           <none>

Required Affinity VS Preferred Affinity

Required와 Prefferd의 핵심적인 차이는 필수(강력), 선호(유연) 입니다. 워커노드에 더이상 Pod를 할당할 수 없는 상황이 왔을 때 Required는 해당 Label이 없는 워커노드에 배치가 안되지만 Prefferd의 경우 Label이 없는 워커노드에도 배치가 가능합니다.

Required 방식 |
아래는 Reqired 방식으로 Replicas를 늘렸을 때의 결과 입니다. 두 대의 워커노드에 더이상 Pod를 배치할 수 없는 상황이 오면, Pod는 Pending 상태로 멈춰있습니다.

NAME             READY   STATUS    RESTARTS   AGE     IP              NODE                                               NOMINATED NODE   READINESS GATES
nginx-back-0     1/1     Running   0          7m54s   10.100.37.243   ip-10-100-46-137.ap-northeast-3.compute.internal   <none>           <none>
...
nginx-back-29    0/1     Pending   0          6m44s   <none>          <none>                                             <none>           <none>
nginx-front-0    1/1     Running   0          7m54s   10.100.33.132   ip-10-100-39-3.ap-northeast-3.compute.internal     <none>           <none>
...
nginx-front-29   0/1     Pending   0          7m10s   <none>          <none>                                             <none>           <none>

Preferred 방식 |
반면 Preferred 방식은 Replicas를 늘려 두 대의 워커노드에 더이상 Pod를 배치할 수 없는 상황이 왔을 때, 특정 Label이 없는 워커노드에도 정상적으로 배치되는 모습을 확인할 수 있습니다.

NAME             READY   STATUS    RESTARTS   AGE   IP              NODE                                               NOMINATED NODE   READINESS GATES
nginx-back-0     1/1     Running   0          89s   10.100.37.243   ip-10-100-46-137.ap-northeast-3.compute.internal   <none>           <none>
...
nginx-back-34    1/1     Running   0          35s   10.100.54.249   ip-10-100-50-238.ap-northeast-3.compute.internal   <none>           <none>
nginx-front-0    1/1     Running   0          89s   10.100.33.132   ip-10-100-39-3.ap-northeast-3.compute.internal     <none>           <none>
...
nginx-front-34   1/1     Running   0          17s   10.100.55.198   ip-10-100-50-238.ap-northeast-3.compute.internal   <none>           <none>

참고

노드에 파드 할당하기

특정한 노드(들) 집합에서만 동작하거나 특정한 노드 집합에서 동작하는 것을 선호하도록 파드를 제한할 수 있다. 이를 수행하는 방법에는 여러 가지가 있으며 권장되는 접근 방식은 모두 레이

kubernetes.io

[Nginx] 사설 인증서로 Proxy 구성하기

junkmm — Wed, 17 Apr 2024 11:03:40 +0900

개요

최근 프로젝트 진행 중 Nginx Proxy 구성 요청을 받아 진행했던 기록을 남깁니다.

문제점

클라이언트에서 인터넷에 운영중인 Web-server에 접근하고 싶어 했으나. 기본적으로 On-prem 환경에서 인터넷 접근이 보안상 불가한 상황이었습니다. 따라서, DX로 연결된 AWS를 통해 Nginx Proxy를 구성하고, AWS 경유해 인터넷에 운영중인 Web-server에 접근하기를 원했습니다.

요구사항

1. Client는 Nginx Proxy를 통해 Public Web-server에 접근 가능해야 합니다.
2. 사용하는 도메인 주소는 총 3개 입니다.
3. Client - Nginx - Origin Web 간의 통신은 HTTPS(보안 웹), WSS(보안 웹소켓)을 사용해야 합니다.
4. Client의 요청 URL을 그대로 Origin Web에 전달해야 합니다.

구성하기

구현 순서

1. 공인 인증서를 사용하는 Web Server, Web Socket Server를 구성합니다.
2. Nginx가 사용할 사설 공인인증서를 발급하고, 클라이언트에 적용합니다.
3. Nginx에 Proxy를 구성합니다.

Web, Web Socket 서버 구성 (아키텍터 상 Web-server)

위 아키텍처 중 Web Server 구성에 관한 부분입니다. 2대의 EC2 Instance를 사용합니다.

Nginx Public Web Server

Nginx 서비스를 설치하고, Certbot을 사용해 Let's Encrypt 공인인증서 발급 후 HTTPS 서비스를 게시합니다. 이를 위해선 공인 DNS를 구성해야 합니다. AWS EC2 Instance의 Amazon Linux 2023을 사용합니다.

1. 관리자 권한을 위해 `sudo su`를 입력합니다.
2. yum 패키지를 통해 nginx를 설치하고, systemctl을 통해 서비스 시작 및 자동 시작을 등록합니다.

  yum update
  yum install nginx
  systemctl enable nginx.service
  systemctl restart nginx.service

3. (선택사항) `curl localhost`를 통해 nginx가 잘 구동중인지 확인합니다.

4. DNS A 레코드를 Nginx 서버의 공인IP로 등록합니다. nslookup을 통해 조회 합니다.

5. Certbot을 통해 Lets's Encrypt 공인인증서 발급 및 HTTPS 서비스를 게시합니다. 아래 명령으로 certbot을 설치합니다.

yum install certbot python-certbot-nginx

nginx 구성 파일에 도메인을 등록합니다. /etc/nnginx/conf.d 디렉토리에 domain-name.conf 라는 파일을 만듭니다. demo.te.kocron.com 이라는 도메인을 사용하는 서비스 구성으로 작성합니다.

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name demo.te.kocron.com;
}

Nginx 서비스를 재기동 합니다.

systemctl restart nginx.service

아래 certbot 명령으로 demo.te.kocron.com에 대한 도메인 등록을 진행합니다. 이메일 주소 입력과 약관을 동의해야 합니다.

certbot --nginx -d demo.te.kocron.com

성공적으로 작업이 완료되면 domain-name.conf 에 구성파일이 아래와 같이 변경되고, 공인인증서를 사용하는 nginx 웹서버가 구성됩니다.

server {
    server_name demo.te.kocron.com;

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/demo.te.kocron.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/demo.te.kocron.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = demo.te.kocron.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    listen 80 default_server;
    listen [::]:80 default_server;
    server_name demo.te.kocron.com;
    return 404; # managed by Certbot
}

`demo1.kocron.com` 도메인에 대해서도 동일하게 구성을 진행합니다.

Web Socket Server

Web Socket Server는 Node.js 를 통해 구동합니다. 먼저 Node를 설치합니다.

sudo yum install yum-utils
sudo yum update
sudo yum install g++ make
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
nvm install --lts
npm install websocket

websocket.js 파일을 생성하고 아래 코드를 붙여 넣습니다.

var WebSocketServer = require('websocket').server;
var http = require('http');
var clients = [];
var idlist = [];
var id = 0;
var array = [];

var server = http.createServer(function(request, response) {
    console.log(new Date() + ' Received request for ' + request.url);
    // 요청 URL 경로가 '/session'인 경우에만 처리
    if (request.url === '/session') {
        console.log(new Date() + ' Received request for session');
        // WebSocket 요청 처리
        wsServer.handleRequest(request, response);
    } else {
        response.writeHead(404);
        response.end();
    }
});
server.listen(9000, function(){
   console.log((new Date()) + 'Server is listening on port 9000')
});

wsServer = new WebSocketServer({
    httpServer: server,
    autoAcceptConnections: false
});

function originIsAllowed(origin) {
    return true;
}

wsServer.on('request', function(request) {
    if (!originIsAllowed(request.origin)) {
        request.reject();
        console.log((new Date()) + 'Connection from origin' + request.origin + 'rejected.');
        return;
    }

    var connection = request.accept(null, request.origin);

    clients.push(connection);
    idlist[request.key] = id++;

    console.log((new Date()) + 'Connection accepted.');
        for(var i=0; i<array.length;i++){
            console.log(array[i]); connection.sendUTF(array[i]);
    }

    connection.on('message', function(message){
        if (message.type === 'utf8'){
            console.log('Received Message: ' + message.utf8Data);
            msg = message.utf8Data;
                        if(msg.indexOf("move") != -1){
                            if(array.length < 50000){
                                array.push(msg);
                            }else{
                                array.shift();
                                array.push(msg);
                            }
                        }else if(msg.indexOf("refresh") != -1){
                            array = [];
                        }else{

                        }
                        clients.forEach(function(cli){
                            cli.sendUTF(msg);
                });
        }
        else if (message.type ==='binary'){
            console.log('Received Binary Message of' + message.binaryData.length + 'bytes');
        }
    });
    connection.on('close', function(reasonCode,description) {
        console.log((new Date() + 'Peer' + connection.remoteAddress + 'desconnected.'));
    });
});

websock.js 파일에 실행 권한을 추가합니다.

chmod +x websock.js

`node websock.js`명령으로 웹소켓 서버를 실행합니다.

웹소켓 테스트는 Simple Web Socket Client 크롬 확장 프로그램을 통해 테스트 합니다.

WebSocket Test Client

A Simple tool to help test WebSocket Service

chromewebstore.google.com

웹소켓의 경우 http -> ws, https -> wss와 매핑된다고 생각하시면 됩니다. 원래라면 인증서를 설정한 wss로 접근해야 하지만, 부득이하게 ws로 테스트 합니다.

server location에 web socket 서버의 주소와 포트번호를 입력하고, [open]을 클릭하면 web socket이 활성화 되며, Request에 메시지를 입력하고 Send를 클릭하면 Message Log에 해당 내용이 출력되는것을 확인할 수 있습니다.

Nginx Proxy가 사용할 사설인증서 구성 (아키텍터 상 Nginx에서 작업)

Client <-> Nginx Proxy 통신에 적용할 사설인증서를 구성합니다. 공인 인증서 대신 사설 인증서를 사용하다 보니, 자체 CA 기관 인증서를 발급하고, Client 단에 신뢰할 수 있는 인증기관 인증서로 설치해야 합니다. 그 후 자체 CA 기관에 Nginx가 사용할 Server 인증서에 대해 서명을 요청하고, 이를 적용합니다. 현재 Sector에서는 자체(root) CA 구성 및 Client 설치에 대해 작성합니다.

아래 구성은 Nginx-Proxy 서버에서 진행해야 합니다. 위에서 구성한 서버외 별도의 EC2 Instance에서 진행합니다.

우선 Self-sigend root CA를 발급합니다. `Enter PEM pass phrase :` 문구가 나오면 비밀번호를 입력합니다.

cd ~ # /home/ec2-user 경로 입니다.
mkdir ssl && cd ssl
openssl genrsa -des3 -out localCA.key 2048

`localCA.key`파일이 생성되면 private key를 이용해서 root CA 인증서를 아래 명령어로 생성합니다.

openssl req -x509 -new -nodes -key localCA.key -sha256 -days 365 -out localCA.pem

인증서 구성 정보를 아래와 같이 입력합니다. `te.kocron.com` 도메인을 사용하는 예시 입니다.

Enter pass phrase for localCA.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:KR
State or Province Name (full name) []:Seoul
Locality Name (eg, city) [Default City]:Shindo-rim
Organization Name (eg, company) [Default Company Ltd]:Cloudmt
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:*.te.kocron.com
Email Address []:demo@cloudmt.co.kr

윈도우 클라이언트에 인증서를 설치하기 위해 `.pem` 파일을 `.crt` 파일로 추출 합니다.

openssl x509 -outform der -in localCA.pem -out localCA.crt

변환된 `.crt` 파일을 scp를 사용해 Windows Client에 옮겨준 뒤 인증서를 설치합니다.

scp -i hakjun_osaka.pem ec2-user@13.208.245.223:/home/ec2-user/ssl/localCA.crt .

Windows로 옮긴 localCA.crt 파일을 실행하고, 다음과 같이 설치합니다.

Nginx Proxy 구성하기 (아키텍터 상 Nginx에서 작업)

위 Self-signed CA를 구성한 EC2 Instance에서 Nginx를 설치하고, Proxy 기능을 구현합니다. 먼저 아래 명령으로 Nginx 서버를 설치합니다.

  yum update
  yum install nginx
  systemctl enable nginx.service
  systemctl restart nginx.service

https 및 wss를 사용하기 위한 서버 인증서를 발급한 뒤 Self-signed CA에게 서명 요청을 진행합니다.

cd ~
cd ssl
openssl genrsa -out server.key 2048

CSR을 생성합니다.

openssl req -new -key server.key -out server.csr

`vim server.ext`를 통해 CA에 인증요청 시 참고 정보를 작성합니다. [alt_names]에서 사용할 도메인 주소를 입력합니다.

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = demo.te.kocron.com
DNS.2 = demo1.te.kocron.com
DNS.3 = demo2.te.kocron.com

아래 명령을 수행하여 pass pharese를 입력면 `demo.te.kocron.com`, `demo1.te.kocron.com`, `demo2.te.kocron.com` 호스트를 `te.kocron.com` CA가 인증하는 인증서를 발급받을 수 있습니다.

openssl x509 -req -in server.csr -CA localCA.pem -CAkey localCA.key \
-CAcreateserial -out server.crt -days 365 -sha256 -extfile server.ext

Nginx Proxy가 사용할 Private 인증서 발급은 완료되었으니, Nginx Proxy 구성을 진행합니다.
우선 생성한 인증서를 nginx 폴더에 붙여넣습니다. 지금 부턴 `sudo su`로 root 권한으로 진행합니다.

sudo su
cp -arp /home/ec2-user/ssl/ /etc/nginx/
cd /etc/nginx/conf.d

`vi server.conf`를 통해 proxy를 구성합니다.

# nginx가 https 요청을 web socket으로 변환하기 위한 변수로 사용됩니다.
map $http_upgrade $connection_upgrade {
        default upgrade;
        '' close;
    }
# upstream은 proxy 대상의 Pool을 지정합니다.
upstream websocket {
        server demo2.te.kocron.com:9000;
    }

server {
# 443 ssl, demo2.te.kocron.com으로 들어오는 패킷에 대해 처리합니다.
        listen 443 ssl;
        server_name  demo2.te.kocron.com;
# ssl 통신을 위한 인증서 구성입니다. rootCA에게 서명받은 인증서 경로를 설정합니다.
        ssl_certificate "/etc/nginx/ssl/server.crt";
        ssl_certificate_key "/etc/nginx/ssl/server.key";
        ssl_session_cache shared:SSL:1m;
        ssl_session_timeout  10m;
        ssl_prefer_server_ciphers on;

# client로 부터 요청받은 모든 URL에 대해 proxy_pass로 http://websocket을 보냅니다.
# websocket은 인증서 적용이 되어있지 않아 http로 구성되었습니다.
        location ~ ^/.*$ {
            proxy_pass http://websocket;
# http -> websocket으로 변환하기 위해 header를 변경합니다.
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header Host $host;
            access_log /var/log/nginx/websocket.log;
        }
    }

server {
# 443 ssl, demo.te.kocron.com으로 들어오는 패킷에 대해 처리합니다.
        listen       443 ssl http2;
        listen       [::]:443 ssl http2;
        server_name  demo.te.kocron.com;
# ssl 통신을 위한 인증서 구성입니다. rootCA에게 서명받은 인증서 경로를 설정합니다.
        ssl_certificate "/etc/nginx/ssl/server.crt";
        ssl_certificate_key "/etc/nginx/ssl/server.key";
        ssl_session_cache shared:SSL:1m;
        ssl_session_timeout  10m;
        ssl_prefer_server_ciphers on;
# client로 부터 요청받은 모든 URL에 대해 proxy_pass를 사용해 https://demo.te.kocron.com 쪽으로 보냅니다.
        location ~ ^/.*$ {
          proxy_pass https://demo.te.kocron.com;
          proxy_set_header Host $host;
        }
    }

    server {
        listen       443 ssl http2;
        listen       [::]:443 ssl http2;
        server_name  demo1.te.kocron.com;

        ssl_certificate "/etc/nginx/ssl/server.crt";
        ssl_certificate_key "/etc/nginx/ssl/server.key";
        ssl_session_cache shared:SSL:1m;
        ssl_session_timeout  10m;
        ssl_prefer_server_ciphers on;

        location = / {
          proxy_pass https://demo1.te.kocron.com/;
          proxy_set_header Host $host;
        }
    }

nginx를 재기동 합니다.

systemctl restart nginx.service

Windows의 hosts파일을 수정합니다. `C:\Windows\System32\drivers\etc\hosts` 경로에서 아래 내용을 추가합니다.(관리자 권한)

# Copyright (c) 1993-2009 Microsoft Corp.
---생략---
13.208.164.94 demo.te.kocron.com demo1.te.kocron.com demo2.te.kocron.com

웹 브라우저로 demo.te.kocron에 접속해 사설인증서로 https 접근이 가능함을 확인합니다.

Proxy의 Access log를 확인해보면 클라이언트 요청을 304 Redirect 한 것을 확인할 수 있고

211.44.192.110 - - [11/Apr/2024:02:08:31 +0000] "GET / HTTP/2.0" 304 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36 Edg/123.0.0.0" "-"

Origin Web-server의 Access log를 확인해보면 Proxy로부터 요청받아 응답하는것을 확인할 수 있습니다.

13.208.164.94 - - [11/Apr/2024:02:08:31 +0000] "GET / HTTP/1.0" 304 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36 Edg/123.0.0.0" "-"

[EKS] CI/CD

junkmm — Tue, 16 Apr 2024 20:32:21 +0900

이번 게시글은 가시다님의 AEWS [2기] 스터디 내용을 정리한 포스트 입니다.
이번 게시글은 7 주차의 스터디 내용인 EKS CI/CD에 대해 살펴봅니다.

EKS 배포

실습을 위해 EKS 클러스터를 배포합니다. AWS 콘솔에 로그인 한 뒤 CloudFormation에서 아래 YAML 파일로 스택을 생성하시면 됩니다. 진행 과정은 아래 링크를 참고해 주세요.

eks-oneclick6.yaml

0.02MB

[EKS] Networking

이번 게시글은 가시다님의 AEWS [2기] 스터디 내용을 정리한 포스트 입니다. 이번 게시글은 2 주차의 스터디 내용인 EKS Networking에 대해 살펴봅니다. EKS 원클릭 배포 사전 준비 AWS 계정 SSH 키 페어 IA

junkmm.tistory.com

배포 확인

Bastion EC2 인스턴스의 공인 IP로 SSH 접근을 시도합니다. 공인 IP는 CloudFormation의 결과에 나오는 출력값 혹은 EC2 메뉴에서 bastion 호스트의 공인IP를 확인합니다.

# ssh -i "Keyname" ec2-user@"Public IP"
ssh -i hj42700eks.pem ec2-user@3.36.133.15

Bastion 접속 후 아래와 같이 기본 설정을 진행합니다.

# default 네임스페이스 적용
kubectl ns default

# 노드 정보 확인 : t3.medium
kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone

# ExternalDNS
MyDomain=<자신의 도메인>
echo "export MyDomain=<자신의 도메인>" >> /etc/profile
MyDomain=junkmm.site
echo "export MyDomain=junkmm.site" >> /etc/profile
MyDnzHostedZoneId=$(aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text)
echo $MyDomain, $MyDnzHostedZoneId
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/aews/externaldns.yaml
MyDomain=$MyDomain MyDnzHostedZoneId=$MyDnzHostedZoneId envsubst < externaldns.yaml | kubectl apply -f -

# kube-ops-view
helm repo add geek-cookbook https://geek-cookbook.github.io/charts/
helm install kube-ops-view geek-cookbook/kube-ops-view --version 1.2.2 --set env.TZ="Asia/Seoul" --namespace kube-system
kubectl patch svc -n kube-system kube-ops-view -p '{"spec":{"type":"LoadBalancer"}}'
kubectl annotate service kube-ops-view -n kube-system "external-dns.alpha.kubernetes.io/hostname=kubeopsview.$MyDomain"
echo -e "Kube Ops View URL = http://kubeopsview.$MyDomain:8080/#scale=1.5"

# AWS LB Controller
helm repo add eks https://aws.github.io/eks-charts
helm repo update
helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=$CLUSTER_NAME \
  --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller

# gp3 스토리지 클래스 생성
kubectl apply -f https://raw.githubusercontent.com/gasida/PKOS/main/aews/gp3-sc.yaml

# 노드 보안그룹 ID 확인
NGSGID=$(aws ec2 describe-security-groups --filters Name=group-name,Values=*ng1* --query "SecurityGroups[*].[GroupId]" --output text)
aws ec2 authorize-security-group-ingress --group-id $NGSGID --protocol '-1' --cidr 192.168.1.100/32

프로메테우스 & 그라파나(admin/prom-operator) 설치, 대시보드 추천 15757 17900 15172

# 사용 리전의 인증서 ARN 확인
CERT_ARN=`aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text`
echo $CERT_ARN

# repo 추가
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

# 파라미터 파일 생성 : PV/PVC(AWS EBS) 삭제에 불편하니, 4주차 실습과 다르게 PV/PVC 미사용
cat <<EOT > monitor-values.yaml
prometheus:
  prometheusSpec:
    podMonitorSelectorNilUsesHelmValues: false
    serviceMonitorSelectorNilUsesHelmValues: false
    retention: 5d
    retentionSize: "10GiB"

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - prometheus.$MyDomain
    paths: 
      - /*
    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/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study
      alb.ingress.kubernetes.io/ssl-redirect: '443'

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

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - grafana.$MyDomain
    paths: 
      - /*
    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/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study
      alb.ingress.kubernetes.io/ssl-redirect: '443'

alertmanager:
  enabled: false
EOT
cat monitor-values.yaml | yh

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

# Metrics-server 배포
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

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

# 그라파나 웹 접속 : 기본 계정 - admin / prom-operator
echo -e "Grafana Web URL = https://grafana.$MyDomain"

Docker

이번 실습에서는 개인 Docker Hub에 컨테이너 이미지를 Push 하기 때문에, Docker에 회원 가입을 진행해야 합니다.

Bastion 호스트에서 간단한 웹 서비스 컨테이너 이미지를 생성하고, Push 해 보도록 하겠습니다.

아래 명령으로 base 이미지인 ubuntu:20.04를 다운로드 받습니다.

docker pull ubuntu:20.04
docker images

실습을 위해 디렉터리를 생성 및 이동합니다.

mkdir -p /root/myweb && cd /root/myweb

`vi Dockerfile` 명령으로 Dockerfile을 생성합니다. NICK 변수를 본인의 이름으로 변경합니다.

FROM ubuntu:20.04
ENV TZ=Asia/Seoul VERSION=1.0.0 NICK=<자신의 닉네임>
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone && \
    sed -i 's/archive.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list && \
    sed -i 's/security.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list && \
    apt-get update && apt-get install -y apache2 figlet && \
    echo "$NICK Web Server $VERSION<br>" > /var/www/html/index.html && \
    echo "<pre>" >> /var/www/html/index.html && \
    figlet AEWS Study >> /var/www/html/index.html && \
    echo "</pre>" >> /var/www/html/index.html
EXPOSE 80
CMD ["usr/sbin/apache2ctl", "-DFOREGROUND"]

`:wq`로 저장 및 편집 종료한 뒤, 터미널에서 아래 명령으로 컨테이너 이미지를 생성합니다.

docker build -t myweb:v1.0.0 .

아래 명령으로 image가 잘 생성되었는지 확인합니다.

docker images

아래 명령으로 컨테이너를 실행시킵니다.

docker run -d -p 80:80 --rm --name myweb myweb:v1.0.0

아래 명령으로 웹 접속 URL을 확인합니다.

curl -s ipinfo.io/ip | awk '{ print "myweb = http://"$1"" }'

아래 명령으로 docker hub에 이미지를 업로드 합니다.

# 도커 이미지 태그 변경
DHUB=<도커 허브 계정>
DHUB=junkmm.site
docker tag myweb:v1.0.0 $DHUB/myweb:v1.0.0
docker images

# 도커 허브 로그인
docker login
Username: <자신의 ID>
Password: <암호>

# push 로 이미지를 저장소에 업로드
docker push $DHUB/myweb:v1.0.0

자신의 Repository에 myweb 저장소가 생기고, v1.0.0 이미지가 생성되었는지 확인합니다.

아래 명령으로 Local 이미지로 실행한 web을 중지하고, Docker Hub에 업로드한 이미지로 컨테이너를 실행시킵니다.

# 컨테이너 종료
docker rm -f myweb
docker ps

# 로컬 이미지 삭제
docker rmi $DHUB/myweb:v1.0.0
docker images

# 
docker run -d -p 80:80 --rm --name myweb $DHUB/myweb:v1.0.0
docker iamges

# 확인
docker ps
curl localhost
curl -s ipinfo.io/ip | awk '{ print "myweb = http://"$1"" }'

# 삭제
docker rm -f myweb

로컬 환경에서 Docker를 통해 Web 서비스를 배포해 보았습니다. 해당 이미지를 이번 CI/CD 실습에 활용 할 예정입니다.

Jenkins

CI(Continuous Intergration)를 위해 Jenkins를 사용합니다. 오픈 소스이 개발 소스를 빌드하거나 배포할 때 사용할 수 있습니다.

설치 및 설정

Bastion 호스트에서 아래 명령어로 Jenkins를 설치합니다.

# 실습 편리를 위해서 root 계정 전환
sudo su -

# Add required dependencies for the jenkins package
# https://docs.aws.amazon.com/corretto/latest/corretto-17-ug/amazon-linux-install.html
sudo yum install fontconfig java-17-amazon-corretto -y
java -version
alternatives --display java
JAVA_HOME=/usr/lib/jvm/java-17-amazon-corretto.x86_64
echo $JAVA_HOME

# 젠킨스 설치
sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io-2023.key
sudo yum upgrade
sudo yum install jenkins -y
sudo systemctl daemon-reload
sudo systemctl enable jenkins && sudo systemctl start jenkins   # 다소 시간 걸림
sudo systemctl status jenkins

Jenkins의 초기 암호를 확인합니다.

# 초기 암호 확인
cat /var/lib/jenkins/secrets/initialAdminPassword

접속 URL을 확인합니다.

curl -s ipinfo.io/ip | awk '{ print "Jenkins = http://"$1":8080" }'

Jenkins URL로 접근하여 위에서 조회한 관리자 비밀번호를 입력합니다.

다음 화면에서 Install suggested plugins를 설치해 플러그인을 설치합니다.

기본 플러그인이 설치됩니다.

Admin 유저를 설정합니다. (admin/qwe123)

기본 사용, Tools 설정

Jenkins 메인 화면 입니다.

Item은 젠킨스에서 사용하는 최소 작업 단위이고, 사람은 Jenkins의 계정 관련 설정, Jenkins 관리는 전역 설정을 적용하는 메뉴 입니다.

Jenkins 기본 사용을 위해 JDK 정의를 진행합니다. Jenkins 관리 -> Tools에 진입합니다.

JDK Installations에서 `Add JDK`를 클릭하고, 아래와 같이 정보를 입력합니다.

첫 번째 Item을 생성합니다. 메인화면 -> Item으로 진입하고, 이름 입력 후 Freestyle project를 선택합니다.

Build Steps -> Add build step -> Excute shell을 선택합니다.

간단한 문장 출력이 될 수 있게 `echo "Aws Workshop Study"`를 입력하고 저장합니다.

지금 빌드를 클릭하여 Jenkins의 Item을 실행합니다.

하단 Build History에 새로운 내역이 생깁니다. 해당 내역에 마우스를 위치하면 아래 사진과 같이 Side Menu가 표시됩니다. Console Output을 클릭합니다.

콘솔 출력에 Excute Shell에 정의한 Welcome to my first project가 찍혀있습니다.

Item(Job) 메뉴로 돌아와 구성 탭에서 Excute shell 부분을 아래와 같이 수정하고, 실행 시킵니다.

다시 Console Output을 확인 해보면, 위에서 정의한 명령어를 실행한 출력값들을 확인해볼 수 있습니다. 이로 인해 Jenkins는 사용자가 정의한 작업을 순서대로 처리하는 특성을 확인해볼 수 있습니다.

위 로그를 보면 Building in workspace라고 정의된 경로가 있습니다. 한국 말로 직역하면 작업 공간이고, 해당 디렉터리에 가보면 touch hello.txt에 의해 hello.txt 파일이 생성되어 있는것을 확인해볼 수 있습니다.

whoami 명령어로 조회한 Linux의 user명은 jenkins로 확인됩니다. 즉 jenkins가 설치된 Bastion호스트의 shell을 jenkins라는 user가 접근하여 위 명령어들을 조회한 것으로 이해가 됩니다.

Docker 사용

Jenkins에서 Docker 빌드를 하기 위해 jenkins 유저가 docker를 실행할 수 있는 권한을 부여해야 합니다.

#docker sock에 666 권한 할당
chmod 666 /var/run/docker.sock
usermod -aG docker jenkins

# Jeknins 유저로 확인
su - jenkins
docker info

# Dockerhub로 로그인 하기
docker login
Username: <자신의 계정명>
Password: <자신의 암호>

Dockerfile을 생성합니다.

# myweb:v2.0.0 컨테이너 이미지 생성을 위한 Dockerfile 준비
# 실습을 위한 디렉터리 생성 및 이동
mkdir -p ~/myweb2 && cd ~/myweb2

# Dockerfile 파일 생성
vi Dockerfile
FROM ubuntu:20.04
ENV TZ=Asia/Seoul VERSION=2.0.0 NICK=<자신의 닉네임>
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone && \
    sed -i 's/archive.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list && \
    sed -i 's/security.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list && \
    apt-get update && apt-get install -y apache2 figlet && \
    echo "$NICK Web Server $VERSION<br>" > /var/www/html/index.html && \
    echo "<pre>" >> /var/www/html/index.html && \
    figlet AEWS Study >> /var/www/html/index.html && \
    echo "</pre>" >> /var/www/html/index.html
EXPOSE 80
CMD ["usr/sbin/apache2ctl", "-DFOREGROUND"]

Jenkins에서 새로운 Item을 생성합니다. Add build step으로 총 2개의 Execute shell을 아래와 같이 생성합니다. 해석하자면 jenkins는 /var/lib/jenkins/myweb2 디렉토리로 이동하고, 해당 dir에서 `docker build`를 진행합니다. 이때 위에서 생성한 Dockerfile을 기반으로 build 합니다.

build가 완료되면 `docker run` 명령을 통해 해당 이미지를 실행시킵니다.

# shell 1
cd /var/lib/jenkins/myweb2
docker build -t myweb:v2.0.0 .

# shell 2
docker run -d -p 80:80 --rm --name myweb myweb:v2.0.0

빌드가 성공했습니다.

아래와 같이 docker image가 생성되고, 실행 중인것을 확인할 수 있습니다.

아래 명령으로 실습 리소스를 삭제합니다.

docker rm -f myweb
docker rmi myweb:v2.0.0

Github 가입

Github에 가입하고 https://github.com/gasida/aews-cicd.git 레포지토리를 포크합니다.

Jenkins Trigger-Project

Git Repo의 변화가 생기면 Jenkins Item(Job)이 실행되는 환경을 실습합니다.

Freestyle project를 생성합니다.

아래와 같이 변수를 추가합니다.(string)

Git 부분을 수정합니다.

빌드 유발을 설정합니다.

빌드 스텝을 설정합니다.

# Shell 1
cd /var/lib/jenkins/myweb2
rm -rf Dockerfile
wget https://raw.githubusercontent.com/$NICK/aews-cicd/main/1/Dockerfile

# Shell 2
cd /var/lib/jenkins/myweb2
docker build --build-arg VERSION=$VERSION -t myweb:$VERSION .
docker run -d -p 80:80 --rm --name myweb -e VERSION=$VERSION myweb:$VERSION

본인의 Github 계정에서 1/Dockerfile 의 Version 부분을 수정합니다.

파라미터와 함께 빌드를 클릭하고, Version을 변경합니다.

완료 후 `curl localhost`로 결과를 확인합니다.

실습 내용을 정리합니다.

docker rm -f myweb
docker rmi myweb:v5.3.1
docker rmi myweb:v1.0.0

Jenkins with Kubernetes

EKS 환경에 배포하는 Jenkins를 구성합니다. 이를 위해 Bastion Jenkins 사용자에서 사전 작업을 진행합니다.

# jenkins 사용자에서 아래 작업 진행
su - jenkins
whoami
mkdir ~/.kube

# root 계정에서 아래 복사 실행
cp ~/.kube/config /var/lib/jenkins/.kube/config
chown jenkins:jenkins /var/lib/jenkins/.kube/config

# jenkins 사용자에서 aws eks 사용(sts 호출 등)을 위한 자격증명 설정
aws configure
AWS Access Key ID [None]: ###
AWS Secret Access Key [None]: ###
Default region name [None]: ap-northeast-2

# jenkins 사용자에서 kubectl 명령어 사용 확인
kubectl get pods -A

Jenkins의 파이프라인으로 Deployment/Service를 배포합니다.

먼저 본인 Github계정의 3/deploy/deployment-svc.yaml에 image 부분을 수정합니다.

Jenkins에서 새로운 Item에 진입 후 Pipeline을 선택합니다.

pipeline 부분에 아래 내용을 입력합니다.

pipeline {
    agent any

    tools {
        jdk 'jdk-17'
    }

    environment {
        DOCKERHUB_USERNAME = 'kimhj4270'
        GITHUB_URL = 'https://github.com/junkmm/aews-cicd.git'
        DIR_NUM = '3'
    }

    stages {
        stage('Container Build') {
            steps {	
                // 릴리즈파일 체크아웃
                checkout scmGit(branches: [[name: '*/main']], 
                    extensions: [[$class: 'SparseCheckoutPaths', 
                    sparseCheckoutPaths: [[path: "/${DIR_NUM}"]]]], 
                    userRemoteConfigs: [[url: "${GITHUB_URL}"]])

                // 컨테이너 빌드 및 업로드
                sh "docker build -t ${DOCKERHUB_USERNAME}/myweb:v1.0.0 ./${DIR_NUM}"
                sh "docker push ${DOCKERHUB_USERNAME}/myweb:v1.0.0"
            }
        }

        stage('K8S Deploy') {
            steps {
                sh "kubectl apply -f ./${DIR_NUM}/deploy/deployment-svc.yaml"
            }
        }
    }
}

지금 빌드를 클릭합니다.

Bastion에서 접속 테스트용 파드를 배포합니다.

# 배포
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: netpod
  labels:
    app: pod
spec:
  containers:
  - name: netshoot-pod
    image: nicolaka/netshoot
    command: ["tail"]
    args: ["-f", "/dev/null"]
  terminationGracePeriodSeconds: 0
EOF

아래 명령어로 myweb pod가 잘 배포되었는지 확인합니다.

kubectl exec -it netpod -- curl myweb:8080

실습 리소스를 삭제합니다.

kubectl delete deploy,svc myweb

Argo Project

Argo는 Kubernetes 환경에서 gitops패턴의 배포 환경을 지원해주는 CNCF 프로젝트 입니다. Argo CD는 쿠버네티스 환경에 배포를 담당하고, Argo Rollouts는 쿠버네티스 배포 시 Blue-Green, Canary 등 무중단 배포를 지원합니다.

ArgoCD

ArgoCD는 API, Repository Service, Application Controller 크게 3가지 서비스가 내장되어 있습니다. API는 Web UI 대시보드를 제공하고, API 서비스를 제공합니다. Repository Server는 Git 연결 및 배포할 yaml을 생성합니다. Application Controller는 K8s 리소스와 Git을 비교하며 Sync를 비교합니다. 동적으로 Git과 k8s를 동기화 할 수 있고, 수동으로 동기화 시킬 수 있습니다.

아래 명령으로 ArgoCD를 설치합니다.

# helm 설치
cat <<EOT > argocd-values.yaml
global:
  domain: argocd.$MyDomain

configs:
  params:
    server.insecure: true

controller:
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true

server:
  ingress:
    enabled: true
    controller: aws
    ingressClassName: alb
    hostname: "argocd.$MyDomain"
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/backend-protocol: HTTP
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":80}, {"HTTPS":443}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/ssl-redirect: '443'
    aws:
      serviceType: ClusterIP
      backendProtocolVersion: GRPC
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true

repoServer:
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true

applicationSet:
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true

notifications:
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true
EOT

kubectl create ns argocd
helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd --version 6.7.11 -f argocd-values.yaml --namespace argocd

확인

Redis는 k8s api와 git 요청을 줄이기 위한 캐싱으로 사용됩니다. notification은 이벤트 알림 및 트리거를 제공하고, Applicationset-controller는 멀티 클러스터를 위한 App 패키징 관리를 위해 사용 됩니다.

`https://argocd.junkmm.site/admin`으로 접속합니다. 아래 명령으로 초기 admin의 암호를 확인합니다.

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d ;echo

admin/위 비밀번호로 로그인 합니다.

NewAPP을 클릭합니다.

아래와 같이 내용을 기입하고 생성합니다.

생성된 Application에 접근합니다.

Sync -> Syncronize를 클릭합니다.

Application이 Health되었습니다.

`kubectl get all -n first`로 조회 시 리소스가 조회된것을 알 수 있습니다.

Github의 Yaml파일을 수정해 보겠습니다. yaml의 label을 추가하고 저장합니다.

Refresh를 누르거나 3분을 기다리면 Status가 OutOfSync로 변경됩니다. Sync를 누르게 되면 Git에서 추가한 labels가 반영된 Deployment가 배포 됩니다.

위와 같이 Gitops를 하기 위해선 배포 yaml 수정을 git에서 진행해야 합니다.

생성한 Application은 Delete를 누른 뒤 아래와 같이 삭제합니다.

위 방식은 Web UI를 통해 구현한 예시입니다. Jenkins와 같은 도구나 CLI환경에서 배포해야 하는경우 argo cli를 설치한 뒤 사용할 수 있습니다.

#
curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
sudo install -m 555 argocd-linux-amd64 /usr/local/bin/argocd
rm -f argocd-linux-amd64

#
argocd version

#
argocd login argocd.$MyDomain
Username: admin
Password: ###
'admin:login' logged in successfully

#
kubectl config get-contexts -o name
hakjunadmin@myeks.ap-northeast-2.eksctl.io
argocd cluster add hakjunadmin@myeks.ap-northeast-2.eksctl.io
y 입력

#
argocd app list
NAME  CLUSTER  NAMESPACE  PROJECT  STATUS  HEALTH  SYNCPOLICY  CONDITIONS  REPO  PATH  TARGET

아래 명령으로 Application을 생성할 수 있습니다.

kubectl config set-context --current --namespace=argocd
argocd app create guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace default

아래 명령으로 sync를 맞출 수 있습니다.

argocd app sync guestbook

Application 삭제

Argo Rollouts

Argo Project 중 하나로 고급 배포 전략을 제공합니다. 그 중 대표적인 것으로 Blue-Green, Canary 배포 전략입니다.

블루-그린

카나리

아래 명령으로 설치를 진행합니다.

#
cat <<EOT > argorollouts-values.yaml
dashboard:
  enabled: true
  ingress:
    enabled: true
    ingressClassName: alb
    hosts:
      - argorollouts.$MyDomain
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/backend-protocol: HTTP
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":80}, {"HTTPS":443}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/ssl-redirect: '443'
EOT

kubectl create ns argo-rollouts
helm install argo-rollouts argo/argo-rollouts --version 2.35.1 -f argorollouts-values.yaml --namespace argo-rollouts

# 확인
kubectl get all -n argo-rollouts
kubectl get crd | grep argo

curl -LO https://github.com/argoproj/argo-rollouts/releases/download/v1.6.4/kubectl-argo-rollouts-linux-amd64
chmod +x ./kubectl-argo-rollouts-linux-amd64
mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

# 설치 확인
kubectl argo rollouts version

아래 yaml을 배포합니다. Canary 배포를 진행하며, 최초 20% 비율로 트래픽을 흘리고, 승인 뒤 40%, 10초 단위로 20% 증가하는 방식의 배포입니다.

spec:
  replicas: 5
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: {}
      - setWeight: 40
      - pause: {duration: 10}
      - setWeight: 60
      - pause: {duration: 10}
      - setWeight: 80
      - pause: {duration: 10}

# Run the following command to deploy the initial Rollout and Service:
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/rollout.yaml
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/service.yaml

rollouts으로 배포된 리소스는 아래 명령어로 확인 가능합니다.

kubectl argo rollouts get rollout rollouts-demo

`https://argorollouts.junkmm.site/rollouts/default`에 접근합니다.

아래의 명령어로 기존 리소스의 컨테이너 이미지를 업데이트 합니다.

kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow

위 yaml의 정의에 따라 관리자의 수동 승인 전 까지는 새로운 버전에 대핸 20%를 유지합니다. 총 5개 파드이니, 1개의 신규 버전과 4개의 기존 버전이 배포됩니다.

상단의 Promote를 클릭합니다.

승인되면 순차적으로 신규버전이 80%가 되기 까지 10초 씩 증가합니다.

rollback을 누르게 되면 기존 버전으로 되돌아 갑니다.

이전(승인 전)으로 되돌아간 생태에서 Abort를 누르면 모든 파드가 완전히 이전 버전으로 배포됩니다.

아래 명령으로 실습 리소스를 삭제합니다.

eksctl delete cluster --name $CLUSTER_NAME && aws cloudformation delete-stack --stack-name $CLUSTER_NAME

[EKS] Security

junkmm — Thu, 11 Apr 2024 20:46:29 +0900

이번 게시글은 가시다님의 AEWS [2기] 스터디 내용을 정리한 포스트 입니다.
이번 게시글은 6 주차의 스터디 내용인 EKS Security에 대해 살펴봅니다.

EKS 배포

eks-oneclick5.yaml

0.02MB

[EKS] Networking

junkmm.tistory.com

배포 확인

# ssh -i "Keyname" ec2-user@"Public IP"
ssh -i hj42700eks.pem ec2-user@3.36.133.15

Bastion 접속 후 아래와 같이 기본 설정을 진행합니다.

# default 네임스페이스 적용
kubectl ns default

# 노드 정보 확인 : t3.medium
kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone

# ExternalDNS
MyDomain=<자신의 도메인>
echo "export MyDomain=<자신의 도메인>" >> /etc/profile
MyDomain=junkmm.site
echo "export MyDomain=junkmm.site" >> /etc/profile
MyDnzHostedZoneId=$(aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text)
echo $MyDomain, $MyDnzHostedZoneId
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/aews/externaldns.yaml
MyDomain=$MyDomain MyDnzHostedZoneId=$MyDnzHostedZoneId envsubst < externaldns.yaml | kubectl apply -f -

# kube-ops-view
helm repo add geek-cookbook https://geek-cookbook.github.io/charts/
helm install kube-ops-view geek-cookbook/kube-ops-view --version 1.2.2 --set env.TZ="Asia/Seoul" --namespace kube-system
kubectl patch svc -n kube-system kube-ops-view -p '{"spec":{"type":"LoadBalancer"}}'
kubectl annotate service kube-ops-view -n kube-system "external-dns.alpha.kubernetes.io/hostname=kubeopsview.$MyDomain"
echo -e "Kube Ops View URL = http://kubeopsview.$MyDomain:8080/#scale=1.5"

# AWS LB Controller
helm repo add eks https://aws.github.io/eks-charts
helm repo update
helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=$CLUSTER_NAME \
  --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller

# gp3 스토리지 클래스 생성
kubectl apply -f https://raw.githubusercontent.com/gasida/PKOS/main/aews/gp3-sc.yaml

# 노드 IP 확인 및 PrivateIP 변수 지정
N1=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2a -o jsonpath={.items[0].status.addresses[0].address})
N2=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2b -o jsonpath={.items[0].status.addresses[0].address})
N3=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2c -o jsonpath={.items[0].status.addresses[0].address})
echo "export N1=$N1" >> /etc/profile
echo "export N2=$N2" >> /etc/profile
echo "export N3=$N3" >> /etc/profile
echo $N1, $N2, $N3

# 노드 보안그룹 ID 확인
NGSGID=$(aws ec2 describe-security-groups --filters Name=group-name,Values=*ng1* --query "SecurityGroups[*].[GroupId]" --output text)
aws ec2 authorize-security-group-ingress --group-id $NGSGID --protocol '-1' --cidr 192.168.1.100/32
aws ec2 authorize-security-group-ingress --group-id $NGSGID --protocol '-1' --cidr 192.168.1.200/32

# 워커 노드 SSH 접속
for node in $N1 $N2 $N3; do ssh -o StrictHostKeyChecking=no ec2-user@$node hostname; done
for node in $N1 $N2 $N3; do ssh ec2-user@$node hostname; done

프로메테우스 & 그라파나(admin / prom-operator) 설치 : 대시보드 추천 15757 17900 15172

# 사용 리전의 인증서 ARN 확인
CERT_ARN=`aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text`
echo $CERT_ARN

# repo 추가
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

# 파라미터 파일 생성 : PV/PVC(AWS EBS) 삭제에 불편하니, 4주차 실습과 다르게 PV/PVC 미사용
cat <<EOT > monitor-values.yaml
prometheus:
  prometheusSpec:
    podMonitorSelectorNilUsesHelmValues: false
    serviceMonitorSelectorNilUsesHelmValues: false
    retention: 5d
    retentionSize: "10GiB"

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - prometheus.$MyDomain
    paths: 
      - /*
    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/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study
      alb.ingress.kubernetes.io/ssl-redirect: '443'

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

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - grafana.$MyDomain
    paths: 
      - /*
    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/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study
      alb.ingress.kubernetes.io/ssl-redirect: '443'

alertmanager:
  enabled: false
EOT
cat monitor-values.yaml | yh

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

# Metrics-server 배포
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

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

# 그라파나 웹 접속 : 기본 계정 - admin / prom-operator
echo -e "Grafana Web URL = https://grafana.$MyDomain"

Kubernetes 인증/인가

Overview | 아래 그림은 kubernetes API를 호출하는 과정을 도식화 한 것입니다. 사용자는 `kubectl`같은 cli 도구로 `kubectl delete namespace demo`와 같은 명령어를 전송할 수 있습니다. 명령을 전달받은 API는 첫 째, 인증/인가를 수행합니다. 이 요청자의 신원을 파악하고, 신원이 파악되었다면 demo namespace를 지울 수 있는지에 대한 권한을 확인합니다. 추 후 validating admission는 demo namespace가 Terminating 중일 때 다른 사용자가 demo namespace에 리소스를 생성하지 못하도록 제약을 걸 수 있습니다.

For example, when a namespace is deleted and subsequently enters the Terminating state, the NamespaceLifecycle admission controller is what prevents any new objects from being created in this namespace.
https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/

User Account의 종류 | 아래 그림은 Kubernetes Api-server를 호출할 수 있는 User Account 종류에 대해 설명하고 있습니다. 사용자(제가)가 가장 많이 사용하는 kubectl로도 API를 호출할 수 있고, 별도의 Kubernetes Dashboard, 혹은 Service Account를 생성하고, 특정 리소스에 할당하여 Kubernetes API를 호출할 수 있습니다.

출처 :  https://kubetm.github.io/k8s/07-intermediate-basic-resource/authentication/

인증 | 아래 그림은 Kubernetes의 인증(Authentication)처리 방법에 대해 설명하고 있습니다. 크게 X.509 Client Certs, kubectl, Service Account 세 가지가 존재합니다.

X.509 Client Certs 방식은 kubeconfig에 CA crt(발급 기관 인증서), Client crt(클라이언트 인증서), Client key(클라이언트 개인키)를 통해 인증하는 방식입니다. 호출 방식은 아래와 같습니다. kubectl이 아닌 `curl`을 통해 API를 호출합니다.

# 출처 : https://coffeewhale.com/kubernetes/authentication/x509/2020/05/02/auth01/
# API 서버 주소 및 포트 설정
API_SERVER_ADDR=XXXX  # 예시) localhost
API_SERVER_PORT=XXX   # 예시) 6443

# kubectl - 신규 X.509 사용자 인증
curl --cacert k8s-rootCA.pem --cert k8s-new-client.pem --key k8s-new-client-key.pem https://$API_SERVER_ADDR:$API_SERVER_PORT/api
# kubectl - 신규 X.509 사용자 인증
kubectl --kubeconfig=$HOME/kubeconfig get pod -n kube-system

kubectl 방식은 사용자 cli를 통해 API를 호출하는 것으로 보통 `~/.kube/config`에 기재된 kubernetes 접속, 인증 정보를 기반으로 API를 호출합니다.

Service Account는 파드의 일부 컨테이너에서 실행되는 애플리케이션 프로세스를 위한 것으로, Token을 사용해 API를 호출할 수 있습니다.

인가 | 인가의 경우 인증을 통해 식별된 안전한 사용자가 수행하는 행위(create, delete 등)에 대해 제어합니다. RBAC방식으로 이를 구현합니다. RBAC은 역할 기반의 권한 관리로, 사용자와 역할을 별개로 선언한 뒤 두가지를 조합(binding)하여 사용자에게 권한을 부여하는 방식으로 kubectl 혹은 API로 관리할 수 있습니다.

간단한 실습으로 인증/인가를 확인해 보겠습니다. dev, infra user, dev, infra namespace를 생성한 뒤 각 사용자는 본인의 namespace에 대해서만 제어할 수 있도록 구성해봅니다.

먼저 dev-team, infra-team 이름의 네임스페이스와 서비스 어카운트를 생성합니다.

# 네임스페이스(Namespace, NS) 생성 및 확인
kubectl create namespace dev-team
kubectl create ns infra-team

# 네임스페이스 확인
kubectl get ns
---
NAME              STATUS   AGE
default           Active   104m
dev-team          Active   3s
infra-team        Active   2s
kube-node-lease   Active   104m
kube-public       Active   104m
kube-system       Active   104m
monitoring        Active   73m

# 네임스페이스에 각각 서비스 어카운트 생성 : serviceaccounts 약자(=sa)
kubectl create sa dev-k8s -n dev-team
kubectl create sa infra-k8s -n infra-team

# 서비스 어카운트 정보 확인
kubectl get sa -n dev-team
kubectl get sa dev-k8s -n dev-team -o yaml | yh
---
apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: "2024-04-11T11:23:06Z"
  name: dev-k8s
  namespace: dev-team
  resourceVersion: "29441"
  uid: 904ccd47-9588-42cc-a73a-b7d59563652a

kubectl get sa -n infra-team
kubectl get sa infra-k8s -n infra-team -o yaml | yh
---
apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: "2024-04-11T11:23:07Z"
  name: infra-k8s
  namespace: infra-team
  resourceVersion: "29446"
  uid: 253d7d10-29d2-4f21-90a6-89979f528448

그 다음 각 네임스페이스에 kubectl 명령을 사용할 수 있는 Pod를 배포합니다. 이 때 `spec.serviceAccountName`을 주어 위에서 생성한 서비스 어카운트를 파드에 매핑합니다.

# 각각 네임스피이스에 kubectl 파드 생성 - 컨테이너이미지
# docker run --rm --name kubectl -v /path/to/your/kube/config:/.kube/config bitnami/kubectl:latest
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: dev-kubectl
  namespace: dev-team
spec:
  serviceAccountName: dev-k8s
  containers:
  - name: kubectl-pod
    image: bitnami/kubectl:1.28.5
    command: ["tail"]
    args: ["-f", "/dev/null"]
  terminationGracePeriodSeconds: 0
EOF

cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: infra-kubectl
  namespace: infra-team
spec:
  serviceAccountName: infra-k8s
  containers:
  - name: kubectl-pod
    image: bitnami/kubectl:1.28.5
    command: ["tail"]
    args: ["-f", "/dev/null"]
  terminationGracePeriodSeconds: 0
EOF

# 확인
kubectl get pod -A
kubectl get pod -o dev-kubectl -n dev-team -o yaml
 serviceAccount: dev-k8s
 ...
kubectl get pod -o infra-kubectl -n infra-team -o yaml
 serviceAccount: infra-k8s
...

# 파드에 기본 적용되는 서비스 어카운트(토큰) 정보 확인
kubectl exec -it dev-kubectl -n dev-team -- ls /run/secrets/kubernetes.io/serviceaccount
kubectl exec -it dev-kubectl -n dev-team -- cat /run/secrets/kubernetes.io/serviceaccount/token
kubectl exec -it dev-kubectl -n dev-team -- cat /run/secrets/kubernetes.io/serviceaccount/namespace
kubectl exec -it dev-kubectl -n dev-team -- cat /run/secrets/kubernetes.io/serviceaccount/ca.crt

# 각각 파드로 Shell 접속하여 정보 확인 : 단축 명령어(alias) 사용
alias k1='kubectl exec -it dev-kubectl -n dev-team -- kubectl'
alias k2='kubectl exec -it infra-kubectl -n infra-team -- kubectl'

# 권한 테스트
k1 get pods # kubectl exec -it dev-kubectl -n dev-team -- kubectl get pods 와 동일한 실행 명령이다!
k1 run nginx --image nginx:1.20-alpine
k1 get pods -n kube-system

k2 get pods # kubectl exec -it infra-kubectl -n infra-team -- kubectl get pods 와 동일한 실행 명령이다!
k2 run nginx --image nginx:1.20-alpine
k2 get pods -n kube-system

# (옵션) kubectl auth can-i 로 kubectl 실행 사용자가 특정 권한을 가졌는지 확인
k1 auth can-i get pods
no

`k1 get pods -n kube-system` 시 아래와 같이 dev-team 서비스 어카운트는 kube-system 네임스페이스에 pods의 list를 확인해볼 수 없다는 오류가 발생합니다.(forbidden)

Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:dev-team:dev-k8s" cannot list resource "pods" in API group "" in the namespace "kube-system"
command terminated with exit code 1

그럼 아래와 같이 각각 네임스페이스에 롤(Role)을 생성한 뒤 서비스 어카운트에 바인딩 하고, 결과를 확인 해 보겠습니다. 여기서 롤(Role,역할)은 apiGroups와 resources로 지정된 리소스에 대해 verbs 권한을 인가 해줌을 정의하고, verbs에는 *(모두 처리), create(생성), delete(삭제), get(조회), list(목록조회), patch(일부업데이트), update(업데이트), watch(변경감시) 옵션이 있습니다.

아래 코드에선 Role 정의 후 Role Binding을 진행합니다.

# 각각 네임스페이스내의 모든 권한에 대한 롤 생성
cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-dev-team
  namespace: dev-team
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
EOF

cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-infra-team
  namespace: infra-team
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
EOF

# 롤 확인 
kubectl get roles -n dev-team
kubectl get roles -n infra-team
kubectl get roles -n dev-team -o yaml
kubectl describe roles role-dev-team -n dev-team
...
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  *.*        []                 []              [*]

# 롤바인딩 생성 : '서비스어카운트 <-> 롤' 간 서로 연동
cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: roleB-dev-team
  namespace: dev-team
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: role-dev-team
subjects:
- kind: ServiceAccount
  name: dev-k8s
  namespace: dev-team
EOF

cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: roleB-infra-team
  namespace: infra-team
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: role-infra-team
subjects:
- kind: ServiceAccount
  name: infra-k8s
  namespace: infra-team
EOF

# 롤바인딩 확인
kubectl get rolebindings -n dev-team
kubectl get rolebindings -n infra-team
kubectl get rolebindings -n dev-team -o yaml
kubectl describe rolebindings roleB-dev-team -n dev-team
...
Role:
  Kind:  Role
  Name:  role-dev-team
Subjects:
  Kind            Name     Namespace
  ----            ----     ---------
  ServiceAccount  dev-k8s  dev-team

서비스 어카운트를 지정한 뒤 파드에서 다시 권한을 테스트 해봅니다.

# 각각 파드로 Shell 접속하여 정보 확인 : 단축 명령어(alias) 사용
alias k1='kubectl exec -it dev-kubectl -n dev-team -- kubectl'
alias k2='kubectl exec -it infra-kubectl -n infra-team -- kubectl'

# 권한 테스트
k1 get pods 
k1 run nginx --image nginx:1.20-alpine
k1 get pods
k1 delete pods nginx
k1 get pods -n kube-system
k1 get nodes

k2 get pods 
k2 run nginx --image nginx:1.20-alpine
k2 get pods
k2 delete pods nginx
k2 get pods -n kube-system
k2 get nodes

# (옵션) kubectl auth can-i 로 kubectl 실행 사용자가 특정 권한을 가졌는지 확인
k1 auth can-i get pods
yes

dev Role에서 namespace를 dev-team으로 지정했기 때문에 아래와 같이 dev-pod에서는 dev-team 네임스페이스에 대한 리소스 조회, 생성이 가능하지만, 이 외 네임스페이스에 대해선 동일하게 forbidden 권한 오류가 발생하며 접근하지 못하는 것을 확인해볼 수 있습니다.

(hakjunadmin@myeks:N/A) [root@myeks-bastion ~]# k1 get pods -n dev-team
NAME          READY   STATUS    RESTARTS   AGE
dev-kubectl   1/1     Running   0          17m
(hakjunadmin@myeks:N/A) [root@myeks-bastion ~]# k1 get pods -n infra-team
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:dev-team:dev-k8s" cannot list resource "pods" in API group "" in the namespace "infra-team"
command terminated with exit code 1

만약 서비스어카운트에 여러 네임스페이스에 대한 역할을 부여하고 싶다면, Role 대신 ClusterRole을 사용해야 합니다.

아래 명령으로 실습 리소스를 삭제합니다.

kubectl delete ns dev-team infra-team

EKS 인증/인가

사용자는 EKS 클러스터에 kubectl 명령을 전송하면, 인증은 AWS IAM에서 처리하고, 인가는 Kubernetes RBAC에서 제어됩니다.

우선 EKS RBAC 분석을 용이하게 하기 위한 krew 플러그인 설치를 진행합니다.

# 설치
kubectl krew install access-matrix rbac-tool rbac-view rolesum whoami

# k8s 인증된 주체 확인
kubectl whoami
arn:aws:iam::6546...:user/hakjunadmin

`access-matrix`는 EKS 리소스에 대한 권한을 확인할 수 있습니다.

# Show an RBAC access matrix for server resources
kubectl access-matrix # Review access to cluster-scoped resources
kubectl access-matrix --namespace default # Review access to namespaced resources in 'default'

`rback-tool lookup`은 사용자 별 역할을 확인해볼 수 있습니다.

# RBAC Lookup by subject (user/group/serviceaccount) name
kubectl rbac-tool lookup
kubectl rbac-tool lookup system:masters
  SUBJECT        | SUBJECT TYPE | SCOPE       | NAMESPACE | ROLE
+----------------+--------------+-------------+-----------+---------------+
  system:masters | Group        | ClusterRole |           | cluster-admin

kubectl rbac-tool lookup system:nodes # eks:node-bootstrapper
kubectl rbac-tool lookup system:bootstrappers # eks:node-bootstrapper
kubectl describe ClusterRole eks:node-bootstrapper

`kubectl rbac-tool whoami`는 현재 사용자 정보에 대해 출력합니다.

`kubectl rolesum`은 서비스어카운트, 사용자, 그룹에 대한 RBAC 정보를 요약하여 알려줍니다.

kubectl rolesum -h
kubectl rolesum aws-node -n kube-system
kubectl rolesum -k User system:kube-proxy
kubectl rolesum -k Group system:masters
kubectl rolesum -k Group system:authenticated

`kubectl rbac-view`는 RBAC 권한을 웹 페이지로 시각화하여 제공합니다.

EKS 인증/인가 부분을 자세히 확인해 보겠습니다.

1. 사용자가 kube-api를 호출할 때 BearerToken(Pre-signed URL)을 함께 전달합니다.

2. kube-api는 admission과 연동된 Webhok Token Authentication에, Token Review를 요청합니다.

3. Webhok은 IAM에 sts GetCallerIdentity를 요청합니다.

4. IAM은 사용자 정보를 Webhok에 전달합니다.

5. Webhok은 IAM으로부터 전달받은 사용자 정보를 aws-auth Configmaps에 확인을 요청합니다.

6. IAM, Configmaps로 부터 사용자 인증이 완료되면, kube-api는 해당 사용자에 대한 권한을 확인합니다.

7. 사용자 보유 권한 내 요청이 확인되면 요청을 승인합니다.

출처 : https://devlos.tistory.com/75

위 과정을 상세히 확인해보겠습니다. 먼저 Token입니다. 아래 aws cli를 입력하면 Token값을 반환 합니다. Token은 만료 기간이 있습니다. 기간이 만료되면 토큰이 노출되더라도 실제 사용은 불가능합니다.

aws eks get-token --cluster-name $CLUSTER_NAME | jq

Bastion 호스트에서 `cat ~/.kube/config` 명령으로 kubeconfig 파일을 확인 해 보겠습니다. kubectl을 요청할 때 cluster의 endpoint를 확인할 수 있고, 하단 users 정보에는 위에서 사용한 `aws eks get-token`명령을 사용하는것을 확인할 수 있습니다. 따라서 kubectl 명령을 보낼때, Token을 발급받아 사용하는 것임을 알 수 있습니다.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: L...K
    server: https://A4.gr7.ap-northeast-2.eks.amazonaws.com
  name: myeks.ap-northeast-2.eksctl.io
contexts:
- context:
    cluster: myeks.ap-northeast-2.eksctl.io
    user: hakjunadmin@myeks.ap-northeast-2.eksctl.io
  name: hakjunadmin@myeks.ap-northeast-2.eksctl.io
current-context: hakjunadmin@myeks.ap-northeast-2.eksctl.io
kind: Config
preferences: {}
users:
- name: hakjunadmin@myeks.ap-northeast-2.eksctl.io
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - eks
      - get-token
      - --output
      - json
      - --cluster-name
      - myeks
      - --region
      - ap-northeast-2
      command: aws
      env:
      - name: AWS_STS_REGIONAL_ENDPOINTS
        value: regional
      provideClusterInfo: false

아래 그림은 API 호출 예제라고 합니다.

위에서 발급한 토큰을 jwt.io 페이지에서 디코드를 진행 해보면, 아래와 같은 DATA가 확인되는것을 확인할 수 있습니다.

"https://sts.ap-northeast-2.amazonaws.com/?
Action=GetCallerIdentity&
Version=2011-06-15&
X-Amz-Algorithm=AWS4-HMAC-SHA256&
X-Amz-Credential=AK%2Fap-northeast-2%2Fsts%2Faws4_request&
X-Amz-Date=20240412T144854Z&
X-Amz-Expires=60&
X-Amz-SignedHeaders=host%3Bx-k8s-aws-id&
X-Amz-Signature=0a4"

위 API호출을 받은 EKS API는 Token Review를 Webhook token authenticator에 요청합니다. AWS IAM은 해당 호출을 인증 완료한 뒤 User/Role에 대한 ARN을 반환합니다.

쿠버네티스 RBAC 인가는 IAM User/Role이 확인되면 k8s aws-auth configmaps에서 mapping 정보를 확인하게 됩니다. aws-auth 컨피그맵에 IAM 사용자, 역할ARN, K8S 오브젝트로 권한을 확인한 뒤 인가 허가가 되면 최종적으로 동작을 수행합니다.

참고로 EKS를 생성한 IAM principal은 aws-auth와 상관없이 kubernetes-admin Username으로 system:masters 그룹에 권한을 가집니다.

# Webhook api 리소스 확인 
kubectl api-resources | grep Webhook
mutatingwebhookconfigurations                  admissionregistration.k8s.io/v1        false        MutatingWebhookConfiguration
validatingwebhookconfigurations                admissionregistration.k8s.io/v1        false        ValidatingWebhookConfiguration

# validatingwebhookconfigurations 리소스 확인
kubectl get validatingwebhookconfigurations
NAME                                        WEBHOOKS   AGE
aws-load-balancer-webhook                   3          70m
eks-aws-auth-configmap-validation-webhook   1          93m
kube-prometheus-stack-admission             1          68m
vpc-resource-validating-webhook             2          93m

kubectl get validatingwebhookconfigurations eks-aws-auth-configmap-validation-webhook -o yaml | kubectl neat | yh
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: eks-aws-auth-configmap-validation-webhook
webhooks:
- admissionReviewVersions:
  - v1
  clientConfig:
    caBundle: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURCVENDQWUyZ0F3SUJBZ0lJV3NiR1dNRFN1c3d3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TkRBME1USXhOREE1TVRSYUZ3MHpOREEwTVRBeE5ERTBNVFJhTUJVeApFekFSQmdOVkJBTVRDbXQxWW1WeWJtVjBaWE13Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLCkFvSUJBUUNpak9CRGloaXFNSkVOdlp4VHFWZEJmZERJN090dGtjWXhvbnlOcjlzbjJ3c3loNVR5cFdpbSt0eDYKZTQrQnZ5ZkRpMGk0bXVCVzhHZm9PZFovZFQ0d3ZOckl4bFYxckNEOE9XRUNPNWQyR29QeGs2RWlHUitsVzlqZgpXL1BWWHVMa0UvVHVJYUlRaS8vT09OU3Y2SnNkdW0yQUdwaDRvdjl5cmcwa1dxTy9LdVdmUEJwelBya3BsTjhuCkJ2ZmZMSXpBZFpLOEFJdzlyOE1PZ05vVnNqd0hnalBzU0R6cGpqck9YZWZaZ3p3ZFZHZEFaTDlCNWV4cTFKeU8KWHZkbHA0Lytnb3djcTZtMWw1WDJhQ1l3MTByUlVIRTMwdjM5U21zaEJFajFkTG0vNWVUWDBuL1FheVlzYXN5RApNTVcxbnBFNS9WekFOVm5JdHBrTlZ5OXRzVXhqQWdNQkFBR2pXVEJYTUE0R0ExVWREd0VCL3dRRUF3SUNwREFQCkJnTlZIUk1CQWY4RUJUQURBUUgvTUIwR0ExVWREZ1FXQkJTaWFKU2x6TUV4ZG9QSDhWcWdZYnNoV0dYVkJUQVYKQmdOVkhSRUVEakFNZ2dwcmRXSmxjbTVsZEdWek1BMEdDU3FHU0liM0RRRUJDd1VBQTRJQkFRQldKNHlGV1ZobgpUNlFHTmZ3bC9ybHNYMEZtU2FkT1JnWCtjaDR6dUlaZUNoY3Ziek1wbVNNUEhyZXdBWGhTUnZIc2hxeDdIbTRoCmxNeWE1SGRrajllOVdlNCt2a3ZuZkY1Y3FjODBybnNJczVTM2hVMDhRNnhVRFpGMmVPY1J4RURtWlovcEk4bHYKSFl4U1ZsRGtycWdYVHhNbzNnZVVCenlPVm1telVUa1BBWGM2QmVESHhKZUVDZ1kvWFVYVERGK0JPaW9OMDhCVgozVW56QTd3bzdtNHA4WGsrOWtpMm81SkJVZmo1MDVNSkxxdEpFVlgvQVQ0MXhxOHpSQThNQVhmZnZMNENEYWFzCmpmMXc2aHZMNUlwejluTDUwZjMxdDRTTFAvcEVYOWU1TXlwb0lmZWwrMVZwblpQTmpBQnpzM1VaSldXRG9BeUIKMktMZXQvdVdCMk4wCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    url: https://127.0.0.1:21375/validate
  failurePolicy: Ignore
  matchConditions:
  - expression: (request.name == "aws-auth")
    name: aws-auth-configmap
  matchPolicy: Equivalent
  name: eks-aws-auth-configmap-validation-webhook.amazonaws.com
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: kube-system
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - UPDATE
    resources:
    - configmaps
    scope: '*'
  sideEffects: None
  timeoutSeconds: 5


# aws-auth 컨피그맵 확인
kubectl get cm -n kube-system aws-auth -o yaml | kubectl neat | yh
apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::6546:role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-nexe8GYoQa63
      username: system:node:{{EC2PrivateDNSName}}
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
#---<아래 생략(추정), ARN은 EKS를 설치한 IAM User , 여기 있었을경우 만약 실수로 삭제 시 복구가 가능했을까?---
  mapUsers: |
    - groups:
      - system:masters
      userarn: arn:aws:iam::111122223333:user/admin
      username: kubernetes-admin

# EKS 설치한 IAM User 정보 >> system:authenticated는 어떤 방식으로 추가가 되었는지 궁금???
{Username: "arn:aws:iam::6546:user/hakjunadmin",
 UID:      "aws-iam-authenticator:6546:AI",
 Groups:   ["system:authenticated"],
 Extra:    {accessKeyId:  ["AKIAZQ3DNPORYDDXLK27"],
            arn:          ["arn:aws:iam::6546:user/hakjunadmin"],
            canonicalArn: ["arn:aws:iam::6546:user/hakjunadmin"],
            principalId:  ["AIDAZQ"],
            sessionName:  [""]}}
...

# system:masters , system:authenticated 그룹의 정보 확인
kubectl rbac-tool lookup system:masters
kubectl rbac-tool lookup system:authenticated
kubectl rolesum -k Group system:masters
kubectl rolesum -k Group system:authenticated

# system:masters 그룹이 사용 가능한 클러스터 롤 확인 : cluster-admin
kubectl describe clusterrolebindings.rbac.authorization.k8s.io cluster-admin
Name:         cluster-admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  cluster-admin
Subjects:
  Kind   Name            Namespace
  ----   ----            ---------
  Group  system:masters

# cluster-admin 의 PolicyRule 확인 : 모든 리소스  사용 가능!
kubectl describe clusterrole cluster-admin
Name:         cluster-admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  *.*        []                 []              [*]
             [*]                []              [*]

# system:authenticated 그룹이 사용 가능한 클러스터 롤 확인
kubectl describe ClusterRole system:discovery
kubectl describe ClusterRole system:public-info-viewer
kubectl describe ClusterRole system:basic-user
kubectl describe ClusterRole eks:podsecuritypolicy:privileged

그럼 데브옵스 신입 사원을 위한 myeks-bastion-2에 설정을 진행해보겠습니다. aws iam user를 생성하고, EKS 클러스터에 접근할 수 있도록 구성해 봅니다. 현재 Bastion에서 IAM 유저를 생성하고, Access Key 발급 및 권한 부여를 합니다.

(hakjunadmin@myeks:N/A) [root@myeks-bastion ~]# aws iam create-user --user-name testuser
{
    "User": {
        "Path": "/",
        "UserName": "testuser",
        "UserId": "###",
        "Arn": "arn:aws:iam::###:user/testuser",
        "CreateDate": "2024-04-12T15:53:36+00:00"
    }
}
(hakjunadmin@myeks:N/A) [root@myeks-bastion ~]# aws iam create-access-key --user-name testuser
{
    "AccessKey": {
        "UserName": "testuser",
        "AccessKeyId": "###",
        "Status": "Active",
        "SecretAccessKey": "###+###",
        "CreateDate": "2024-04-12T15:53:42+00:00"
    }
}
(hakjunadmin@myeks:N/A) [root@myeks-bastion ~]# aws iam attach-user-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --user-name testuser

Bastion2 호스트에 접속 후 testuser의 AccessKey로 aws configure를 진행합니다.

testuser가 kubectl 명령을 사용할 수 있게 설정합니다.

eksctl create iamidentitymapping --cluster $CLUSTER_NAME --username testuser --group system:masters --arn arn:aws:iam::$ACCOUNT_ID:user/testuser

aws-auth를 확인해보면 아래와 같이 추가된 것을 확인할 수 있습니다.

  mapUsers: |
    - groups:
      - system:masters
      userarn: arn:aws:iam::##:user/testuser
      username: testuser

Bastion2에서 아래 명령으로 Kubeconfig를 생성합니다.

aws eks update-kubeconfig --name $CLUSTER_NAME --user-alias testuser

Bastion2 에서도 kubectl명령을 사용할 수 있게 되었습니다.

configmap의 중요성을 확인해보기 위해 aws-auth에 매핑된 그룹을 바꿔보겠습니다.

kubectl edit cm -n kube-system aws-auth

system:authenticated으로 수정

수정 뒤 아래와 같이 권한이 없어 조회가 불가능함을 확인합니다.

아래 명령으로 IAM 맵핑을 삭제할 수도 있습니다. 아래 명령을 수행하면 aws-auth 컨피그맵에 testuser의 내용이 삭제됩니다.

eksctl delete iamidentitymapping --cluster $CLUSTER_NAME --arn  arn:aws:iam::$ACCOUNT_ID:user/testuser

EC2 Instance Profile | (IAM Role)에 매핑된 K8S RBAC 확인해보기, 최근 추가된 기능

노드에 매핑관 Role을 확인해봅니다. 워커노드 각각 별도의 Role을 사용하고 있음을 확인합니다.

# 노드에 STS ARN 정보 확인 : Role 뒤에 인스턴스 ID!
for node in $N1 $N2 $N3; do ssh ec2-user@$node aws sts get-caller-identity --query Arn; done
"arn:aws:sts::65:assumed-role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-nexe8GYoQa63/i-051140852d9fddf15"
"arn:aws:sts::65:assumed-role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-nexe8GYoQa63/i-038360583545cfdae"
"arn:aws:sts::65:assumed-role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-nexe8GYoQa63/i-006b15c6dca84673f"

aws-auth 컨피그맵을 확인해보면, mapRoles: 필드에서 rolearn:으로 인스턴스에 할당된 Role에 대해 사용자 인증을 해주고 있는것을 확인할 수 있습니다.

kubectl describe configmap -n kube-system aws-auth

그럼 워커노드에 할당된 역할 정보를 불러와 aws cli를 사용하는 파드를 배포한 뒤 aws cli를 작동해 보겠습니다.

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

# 파드 생성 확인
kubectl get pod -owide

# 파드 이름 변수 지정
APODNAME1=$(kubectl get pod -l app=awscli-pod -o jsonpath={.items[0].metadata.name})
APODNAME2=$(kubectl get pod -l app=awscli-pod -o jsonpath={.items[1].metadata.name})
echo $APODNAME1, $APODNAME2

# awscli 파드에서 EC2 InstanceProfile(IAM Role)의 ARN 정보 확인
kubectl exec -it $APODNAME1 -- aws sts get-caller-identity --query Arn
kubectl exec -it $APODNAME2 -- aws sts get-caller-identity --query Arn

# awscli 파드에서 EC2 InstanceProfile(IAM Role)을 사용하여 AWS 서비스 정보 확인 >> 별도 IAM 자격 증명이 없는데 어떻게 가능한 것일까요?
# > 최소권한부여 필요!!! >>> 보안이 허술한 아무 컨테이너나 탈취 시, IMDS로 해당 노드의 IAM Role 사용 가능!
kubectl exec -it $APODNAME1 -- aws ec2 describe-instances --region ap-northeast-2 --output table --no-cli-pager
kubectl exec -it $APODNAME2 -- aws ec2 describe-vpcs --region ap-northeast-2 --output table --no-cli-pager
 
# EC2 메타데이터 확인 : IDMSv1은 Disable, IDMSv2 활성화 상태, IAM Role - 링크
kubectl exec -it $APODNAME1 -- bash
-----------------------------------
아래부터는 파드에 bash shell 에서 실행
curl -s http://169.254.169.254/ -v
...

# Token 요청 
curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" ; echo
curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" ; echo

# Token을 이용한 IMDSv2 사용
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/ ; echo
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/ ; echo
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/meta-data/iam/security-credentials/ ; echo

# 위에서 출력된 IAM Role을 아래 입력 후 확인
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/meta-data/iam/security-credentials/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-nexe8GYoQa63
{
  "Code" : "Success",
  "LastUpdated" : "2024-04-12T16:13:46Z",
  "Type" : "",
  "AccessKeyId" : "",
  "SecretAccessKey" : "",
  "Token" : "",
  "Expiration" : "2024-04-12T22:25:02Z"
}
## 출력된 정보는 AWS API를 사용할 수 있는 어느곳에서든지 Expiration 되기전까지 사용 가능

# 파드에서 나오기
exit
---

기존에 권한 관리를 쉽게 적용한 방법

AWS EKS 액세스 구성모드가 EKS API 및 ConfigMap 이면 정책 중복 시 EKS API가 우선시 된다. 결론적으로 Configmap보다 EKS API를 사용하게 되며, 최근들어 API 사용을 권장한다고 합니다.

EKS API 호출 방법을 확인해보겠습니다.

aws eks update-cluster-config --name $CLUSTER_NAME --access-config authenticationMode=API

액세스가 EKS API 인증모드로 변경되었습니다.

기존에 EKS를 생성한 User가 EKS클러스터에 접근 가능한 이유는 해당 User에 대한 액세스 정책으로 `AmazonEKSClusterAdminPolicy`를 보유하고 있기 때문입니다.

액세스 정책 별 접근 가능한 권한(크게 4 가지)은 링크에서 확인 가능합니다.

# 맵핑 클러스터롤 정보 확인
kubectl get clusterroles -l 'kubernetes.io/bootstrapping=rbac-defaults' | grep -v 'system:'

그럼 testuser를 API방식으로 사용하기위한 설정을 적용합니다.

# testuser 의 access entry 생성
aws eks create-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser
{
    "accessEntry": {
        "clusterName": "myeks",
        "principalArn": "arn:aws:iam::6:user/testuser",
        "kubernetesGroups": [],
        "accessEntryArn": "arn:aws:eks:ap-northeast-2:65:access-entry/myeks/user/65/testuser/54c76c1d-e41a-812d-3347-fad17fdffab8",
        "createdAt": "2024-04-14T01:13:00.394000+09:00",
        "modifiedAt": "2024-04-14T01:13:00.394000+09:00",
        "tags": {},
        "username": "arn:aws:iam::654654143395:user/testuser",
        "type": "STANDARD"
    }
}

aws eks list-access-entries --cluster-name $CLUSTER_NAME | jq -r .accessEntries[]
arn:aws:iam::654654143395:role/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-c1AQaMSrbK4x
arn:aws:iam::654654143395:user/hakjunadmin
arn:aws:iam::654654143395:user/testuser


# testuser에 AmazonEKSClusterAdminPolicy 연동
aws eks associate-access-policy --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy --access-scope type=cluster

{
    "clusterName": "myeks",
    "principalArn": "arn:aws:iam::654:user/testuser",
    "associatedAccessPolicy": {
        "policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy",
        "accessScope": {
            "type": "cluster",
            "namespaces": []
        },
        "associatedAt": "2024-04-14T01:13:14.146000+09:00",
        "modifiedAt": "2024-04-14T01:13:14.146000+09:00"
    }
}

#
aws eks list-associated-access-policies --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser | jq
aws eks describe-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser | jq

Bastion2에서 testuser로 kubectl이 가능한것을 확인할 수 있습니다.

EKS API를 사용해 IAM User를 액세스 정책과 연동해 EKS 연결방법을 확인 해 보았습니다. 아래 명령으로 access entry를 제거합니다.

aws eks delete-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser

이번에는 미리 만들어진 정책을 사용하지 않고, 사용자 지정 Role을 매핑하여 적용하는 것을 실습해보겠습니다. viewr, admin role 2개를 생성합니다.

#
cat <<EoF> ~/pod-viewer-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-viewer-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["list", "get", "watch"]
EoF

cat <<EoF> ~/pod-admin-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-admin-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["*"]
EoF

kubectl apply -f ~/pod-viewer-role.yaml
kubectl apply -f ~/pod-admin-role.yaml

#
kubectl create clusterrolebinding viewer-role-binding --clusterrole=pod-viewer-role --group=pod-viewer
kubectl create clusterrolebinding admin-role-binding --clusterrole=pod-admin-role --group=pod-admin

test user를 viewer와 연결합니다.

aws eks create-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser --kubernetes-group pod-viewer

test user는 kubectl get pod 는 가능하지만 delete pod는 불가능 합니다.

testuser의 권한을 admin으로 수정합니다.

aws eks update-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser --kubernetes-group pod-admin | jq -r .accessEntry

pod delete가 가능해 집니다.

EKS IRSA & Pod Identitty

EKS의 Pod가 AWS S3등 AWS 리소스를 사용할 때 AWS STS/IAM과 IAM OIDC를 사용해 인증/인가를 처리하는 방식입니다. 기존 인스턴스 프로필, 액세스 키 사용시 키 노출로 인한 보안 허점을 보완할 수 있는 방법입니다.

우선 Pod의 Token 처리 방법을 확인해 보겠습니다.

# Create the Secrets:
## Create files containing the username and password:
echo -n "admin" > ./username.txt
echo -n "1f2d1e2e67df" > ./password.txt

## Package these files into secrets:
kubectl create secret generic user --from-file=./username.txt
kubectl create secret generic pass --from-file=./password.txt

# 파드 생성
kubectl apply -f https://k8s.io/examples/pods/storage/projected.yaml

# 파드 확인
kubectl get pod test-projected-volume -o yaml | kubectl neat | yh

IRSA는 파드에 할당하여 사용하는 서비스 어카운트입니다. 파드에 Role이 매핑되어 있어 최소권한부여를 만족할 수 있습니다.

상세 과정을 도식화 하면 아래와 같습니다.

실습으로 내용을 확인해 보겠습니다. 먼저 파드를 생성하고 서비스 어카운트는 별도 지정해보지 않도록 구성해보겠습니다. 아래 파드는 s3 ls 명령을 입력하는 파드입니다.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: eks-iam-test1
spec:
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      args: ['s3', 'ls']
  restartPolicy: Never
  automountServiceAccountToken: false
  terminationGracePeriodSeconds: 0
EOF

`automountServiceAccountToken`이 `false`로 설정되어 있어 Pod에 서비스어카운트를 별도 할당하지 않게 됩니다. 권한이 없어, Cloud Trail에서 Access Denied가 발생한 것을 확인할 수 있습니다.

두 번째 파드를 생성해보겠습니다.

# 파드2 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: eks-iam-test2
spec:
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      command: ['sleep', '36000']
  restartPolicy: Never
  terminationGracePeriodSeconds: 0
EOF

# 확인
kubectl get pod
kubectl describe pod
kubectl get pod eks-iam-test2 -o yaml | kubectl neat | yh
kubectl exec -it eks-iam-test2 -- ls /var/run/secrets/kubernetes.io/serviceaccount
kubectl exec -it eks-iam-test2 -- cat /var/run/secrets/kubernetes.io/serviceaccount/token ;echo

# aws 서비스 사용 시도
kubectl exec -it eks-iam-test2 -- aws s3 ls

# 서비스 어카운트 토큰 확인
SA_TOKEN=$(kubectl exec -it eks-iam-test2 -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)
echo $SA_TOKEN

https://jwt.io/에서 토큰 정보를 확인합니다.

기본 서비스 어카운트는 생성되어 파트에 Project로 Service Account의 토큰이 마운트 되었지만, 다시 Cloud Trail 로그를 확인해보면 아직 Access Denied입니다.

세 번째 파드를 생성해 봅니다.

아래 명령으로 IAM과 K8S 서비스어카운트를 매핑합니다.

# Create an iamserviceaccount - AWS IAM role bound to a Kubernetes service account
eksctl create iamserviceaccount \
  --name my-sa \
  --namespace default \
  --cluster $CLUSTER_NAME \
  --approve \
  --attach-policy-arn $(aws iam list-policies --query 'Policies[?PolicyName==`AmazonS3ReadOnlyAccess`].Arn' --output text)

my-sa를 사용하는 Pod로 배포합니다.

# 파드3번 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: eks-iam-test3
spec:
  serviceAccountName: my-sa
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      command: ['sleep', '36000']
  restartPolicy: Never
  terminationGracePeriodSeconds: 0
EOF

aws s3 ls조회가 가능해 졌습니다.

Pod 내용을 보면 projected에 seviceAccount 부분이 변경된걸 확인할 수 있습니다.

kubectl get pod eks-iam-test3 -o yaml | kubectl neat | yh

위와같이 생성하면 AWS 콘솔 역할에서 아래 내용을 확인할 수 있습니다. OIDC주소는 Public이기 때문에 보안 위협이 될 수 있는데 Condition에 있는 서비스 어카운트를 *로 변경하면, Token이 발급되어 보안에 위협이 생길 수 있다고 합니다.

Pod Identity는 OIDC Provider를 개선한 방식입니다. Add-on을 추가하고 사용하기만 하면 됩니다.

Pod-Identity를 설치합니다.

aws eks create-addon --cluster-name $CLUSTER_NAME --addon-name eks-pod-identity-agent

# 확인
eksctl get addon --cluster $CLUSTER_NAME

해당 Add-on을 배포하면, eks-pod-identity-agent가 배포됩니다. 해당 파드는 워커노드의 호스트 네트워크를 사용하고, local에서만 접근 가능한 169.254.170.23주소에 80번 포트로 서비스를 게시하고, 파드들은 이쪽으로 credential 요청을 전송합니다.

이 기능을 사용하려면 노드그룹이 사용하는 역할에 AmazonEKSWorkerNodePolicy 정책 부분에 eks-auth 부분이 추가 되어 있어야 합니다.

podientity를 생성합니다.

eksctl create podidentityassociation \
--cluster $CLUSTER_NAME \
--namespace default \
--service-account-name s3-sa \
--role-name s3-eks-pod-identity-role \
--permission-policy-arns arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
--region $AWS_REGION

파드를 배포합니다. s3 조회가 정상적으로 작동합니다.

# 서비스어카운트, 파드 생성
kubectl create sa s3-sa

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: eks-pod-identity
spec:
  serviceAccountName: s3-sa
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      command: ['sleep', '36000']
  restartPolicy: Never
  terminationGracePeriodSeconds: 0
EOF

OWASP Kubernetes Top Ten

mysql 배포

cat <<EOT > mysql.yaml
apiVersion: v1
kind: Secret
metadata:
  name: dvwa-secrets
type: Opaque
data:
  # s3r00tpa55
  ROOT_PASSWORD: czNyMDB0cGE1NQ==
  # dvwa
  DVWA_USERNAME: ZHZ3YQ==
  # p@ssword
  DVWA_PASSWORD: cEBzc3dvcmQ=
  # dvwa
  DVWA_DATABASE: ZHZ3YQ==
---
apiVersion: v1
kind: Service
metadata:
  name: dvwa-mysql-service
spec:
  selector:
    app: dvwa-mysql
    tier: backend
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 3306
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dvwa-mysql
spec:
  replicas: 1
  selector:
    matchLabels:
      app: dvwa-mysql
      tier: backend
  template:
    metadata:
      labels:
        app: dvwa-mysql
        tier: backend
    spec:
      containers:
        - name: mysql
          image: mariadb:10.1
          resources:
            requests:
              cpu: "0.3"
              memory: 256Mi
            limits:
              cpu: "0.3"
              memory: 256Mi
          ports:
            - containerPort: 3306
          env:
            - name: MYSQL_ROOT_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: dvwa-secrets
                  key: ROOT_PASSWORD
            - name: MYSQL_USER
              valueFrom:
                secretKeyRef:
                  name: dvwa-secrets
                  key: DVWA_USERNAME
            - name: MYSQL_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: dvwa-secrets
                  key: DVWA_PASSWORD
            - name: MYSQL_DATABASE
              valueFrom:
                secretKeyRef:
                  name: dvwa-secrets
                  key: DVWA_DATABASE
EOT
kubectl apply -f mysql.yaml

Web서버 배포

cat <<EOT > dvwa.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: dvwa-config
data:
  RECAPTCHA_PRIV_KEY: ""
  RECAPTCHA_PUB_KEY: ""
  SECURITY_LEVEL: "low"
  PHPIDS_ENABLED: "0"
  PHPIDS_VERBOSE: "1"
  PHP_DISPLAY_ERRORS: "1"
---
apiVersion: v1
kind: Service
metadata:
  name: dvwa-web-service
spec:
  selector:
    app: dvwa-web
  type: ClusterIP
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dvwa-web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: dvwa-web
  template:
    metadata:
      labels:
        app: dvwa-web
    spec:
      containers:
        - name: dvwa
          image: cytopia/dvwa:php-8.1
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "0.3"
              memory: 256Mi
            limits:
              cpu: "0.3"
              memory: 256Mi
          env:
            - name: RECAPTCHA_PRIV_KEY
              valueFrom:
                configMapKeyRef:
                  name: dvwa-config
                  key: RECAPTCHA_PRIV_KEY
            - name: RECAPTCHA_PUB_KEY
              valueFrom:
                configMapKeyRef:
                  name: dvwa-config
                  key: RECAPTCHA_PUB_KEY
            - name: SECURITY_LEVEL
              valueFrom:
                configMapKeyRef:
                  name: dvwa-config
                  key: SECURITY_LEVEL
            - name: PHPIDS_ENABLED
              valueFrom:
                configMapKeyRef:
                  name: dvwa-config
                  key: PHPIDS_ENABLED
            - name: PHPIDS_VERBOSE
              valueFrom:
                configMapKeyRef:
                  name: dvwa-config
                  key: PHPIDS_VERBOSE
            - name: PHP_DISPLAY_ERRORS
              valueFrom:
                configMapKeyRef:
                  name: dvwa-config
                  key: PHP_DISPLAY_ERRORS
            - name: MYSQL_HOSTNAME
              value: dvwa-mysql-service
            - name: MYSQL_DATABASE
              valueFrom:
                secretKeyRef:
                  name: dvwa-secrets
                  key: DVWA_DATABASE
            - name: MYSQL_USERNAME
              valueFrom:
                secretKeyRef:
                  name: dvwa-secrets
                  key: DVWA_USERNAME
            - name: MYSQL_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: dvwa-secrets
                  key: DVWA_PASSWORD
EOT
kubectl apply -f dvwa.yaml

Ingress 배포

cat <<EOT > dvwa-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
    alb.ingress.kubernetes.io/group.name: study
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
    alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/ssl-redirect: "443"
    alb.ingress.kubernetes.io/success-codes: 200-399
    alb.ingress.kubernetes.io/target-type: ip
  name: ingress-dvwa
spec:
  ingressClassName: alb
  rules:
  - host: dvwa.$MyDomain
    http:
      paths:
      - backend:
          service:
            name: dvwa-web-service
            port:
              number: 80
        path: /
        pathType: Prefix
EOT
kubectl apply -f dvwa-ingress.yaml
echo -e "DVWA Web https://dvwa.$MyDomain"

접속 (admin/admin)

Create Database 클릭

재 로그인 (admin/password)

DVWA Security 수준 Low로 저장

Command Injection 공격 유형 |

사용자가 입력한 명령어 그대로 shell 스크립트를 실행할 수 있음을 확인했을 때

아래처럼 EC2의 인스턴스 프로필을 요청하는 방식으로 취약점이 생길 수 있다.

Kubelet 미흡한 인증/인가 설정 시 위험 |

(hakjunadmin@myeks:N/A) [root@myeks-bastion ~]# ssh ec2-user@$N1 sudo ss -tnlp | grep kubelet
LISTEN 0      4096        127.0.0.1:10248      0.0.0.0:*    users:(("kubelet",pid=3024,fd=16))
LISTEN 0      4096                *:10250            *:*    users:(("kubelet",pid=3024,fd=13))

# 데모를 위해 awscli 파드 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: myawscli
spec:
  #serviceAccountName: my-sa
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      command: ['sleep', '36000']
  restartPolicy: Never
  terminationGracePeriodSeconds: 0
EOF

Bastion2에서 kubeletfct 설치 및 사용

# 기존 kubeconfig 삭제
rm -rf ~/.kube

# 다운로드
curl -LO https://github.com/cyberark/kubeletctl/releases/download/v1.11/kubeletctl_linux_amd64 && chmod a+x ./kubeletctl_linux_amd64 && mv ./kubeletctl_linux_amd64 /usr/local/bin/kubeletctl
kubeletctl version
kubeletctl help

# 노드1 IP 변수 지정
N1=<각자 자신의 노드1의 PrivateIP>
N1=192.168.1.206

# 노드1 IP로 Scan
kubeletctl scan --cidr $N1/32

# 노드1에 kubelet API 호출 시도
curl -k https://$N1:10250/pods; echo
Unauthorized

Node 1 접속 후 kubelet-config.json 수정

# 노드1 접속
ssh ec2-user@$N1
-----------------------------
# 미흡한 인증/인가 설정으로 변경
sudo vi /etc/kubernetes/kubelet/kubelet-config.json
...
"authentication": {
    "anonymous": {
      "enabled": true
...
  },
  "authorization": {
    "mode": "AlwaysAllow",
...

# kubelet restart
sudo systemctl restart kubelet
systemctl status kubelet
-----------------------------

Bastion2에서 kubeletct 사용, 기존에 접근 안되던 부분들이 접근 가능해 짐.

# 파드 목록 확인
curl -s -k https://$N1:10250/pods | jq

# kubelet-config.json 설정 내용 확인
curl -k https://$N1:10250/configz | jq

# kubeletct 사용
# Return kubelet's configuration
kubeletctl -s $N1 configz | jq

# Get list of pods on the node
kubeletctl -s $N1 pods

# Scans for nodes with opened kubelet API > Scans for for all the tokens in a given Node
kubeletctl -s $N1 scan token

# 단, 아래 실습은 워커노드1에 myawscli 파드가 배포되어 있어야 실습이 가능. 물론 노드2~3에도 kubelet 수정하면 실습 가능함.
# kubelet API로 명령 실행 : <네임스페이스> / <파드명> / <컨테이너명>
curl -k https://$N1:10250/run/default/myawscli/my-aws-cli -d "cmd=aws --version"

# Scans for nodes with opened kubelet API > remote code execution on their containers
kubeletctl -s $N1 scan rce

# Run commands inside a container
kubeletctl -s $N1 exec "/bin/bash" -n default -p myawscli -c my-aws-cli
--------------------------------
export
aws --version
aws ec2 describe-vpcs --region ap-northeast-2 --output table --no-cli-pager
exit
--------------------------------

# Return resource usage metrics (such as container CPU, memory usage, etc.)
kubeletctl -s $N1 metrics

Kyverno

Kubernetes Native Policy Management

Kyverno

Kyverno is a policy engine designed for Kubernetes

kyverno.io

동작 |

Mutating, Validating admission 과정에서 허용/차단 정책을 제공해 준다. kyverno는 rule의 집합으로 사용됨.

설치, EKS에서 사용 시 kube-system ns에 배포된 리소스는 대상에서 제외

cat << EOF > kyverno-value.yaml
config:
  resourceFiltersExcludeNamespaces: [ kube-system ]

admissionController:
  serviceMonitor:
    enabled: true

backgroundController:
  serviceMonitor:
    enabled: true

cleanupController:
  serviceMonitor:
    enabled: true

reportsController:
  serviceMonitor:
    enabled: true
EOF
kubectl create ns kyverno
helm repo add kyverno https://kyverno.github.io/kyverno/
helm install kyverno kyverno/kyverno --version 3.2.0-rc.3 -f kyverno-value.yaml -n kyverno

# 확인
kubectl get all -n kyverno
kubectl get crd | grep kyverno
kubectl get pod,svc -n kyverno

# (참고) 기본 인증서 확인 https://kyverno.io/docs/installation/customization/#default-certificates
# step-cli 설치 https://smallstep.com/docs/step-cli/installation/
wget https://dl.smallstep.com/cli/docs-cli-install/latest/step-cli_amd64.rpm
sudo rpm -i step-cli_amd64.rpm

#
kubectl -n kyverno get secret
kubectl -n kyverno get secret kyverno-svc.kyverno.svc.kyverno-tls-ca -o jsonpath='{.data.tls\.crt}' | base64 -d
kubectl -n kyverno get secret kyverno-svc.kyverno.svc.kyverno-tls-ca -o jsonpath='{.data.tls\.crt}' | base64 -d | step certificate inspect --short


#
kubectl get validatingwebhookconfiguration kyverno-policy-validating-webhook-cfg -o jsonpath='{.webhooks[0].clientConfig.caBundle}' | base64 -d | step certificate inspect --short

프로메테우스 확인

그라파나 대시보드 확인 15804

cluster policy 생성, pod 라벨에 team이 있어야 함.

kubectl create -f- << EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-team
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "label 'team' is required"
      pattern:
        metadata:
          labels:
            team: "?*"
EOF

디플로이먼트 생성을 시도했으나, 생성 실패

key가 team인 label 추가 후 재배포 성공

validation 리포트 확인

Mutating |

파드를 대상으로 mutate 정책으로 라벨을 추가로 할당

kubectl create -f- << EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-labels
spec:
  rules:
  - name: add-team
    match:
      any:
      - resources:
          kinds:
          - Pod
    mutate:
      patchStrategicMerge:
        metadata:
          labels:
            +(team): bravo
EOF

파드 생성 시, team: bravo가 자동 추가됨

key에 team으로 지정하고 생성하면 value는 Override되어 들어간다.

Generation |

kubectl -n default create secret docker-registry regcred \
  --docker-server=myinternalreg.corp.com \
  --docker-username=john.doe \
  --docker-password=Passw0rd123! \
  --docker-email=john.doe@corp.com
  
kubectl create -f- << EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: sync-secrets
spec:
  rules:
  - name: sync-image-pull-secret
    match:
      any:
      - resources:
          kinds:
          - Namespace
    generate:
      apiVersion: v1
      kind: Secret
      name: regcred
      namespace: "{{request.object.metadata.name}}"
      synchronize: true
      clone:
        namespace: default
        name: regcred
EOF

새로운 namespace 생성 후 secret을 확인해보면, regcred 시크릿이 자동으로 생성된 것을 확인할 수 있다.