ssunw

001. Loki Logging Stack 구성 요소

ssunw — Thu, 4 Dec 2025 10:32:28 +0900

Loki 개요 (Loki Overview)

Loki는 Prometheus에서 영감을 받아 만들어진 수평 확장형(horizontally scalable), 고가용성(highly available), 멀티테넌트(multi-tenant) 로그 집계 시스템이다.

Prometheus가 pull 기반 메트릭을 중심으로 설계된 것과 달리, Loki는 push 기반으로 로그를 수집하며 비용 효율성과 확장성을 핵심 목표로 한다.

Loki는 기존 로그 시스템처럼 로그 본문(log content)을 색인하지 않는다. 대신 로그 스트림별 메타데이터(label)만 색인하고, 실제 로그 데이터는 압축된 chunk 형태로 S3/GCS 같은 오브젝트 스토리지에 저장한다. 이 구조 덕분에 인덱스가 매우 작고 운영 비용이 낮아진다.

로그 스트림(log stream)은 동일한 label 셋을 공유하는 로그 집합을 의미한다. 효율적인 쿼리를 위해서는 적절한 label 설계가 매우 중요하다.

Loki Logging Stack 구성 요소

일반적인 Loki 기반 로깅 환경은 다음 세 가지 요소로 구성된다.

1. Agent (Promtail 또는 Grafana Alloy 등)

로그를 수집(scrape)
label을 붙여 스트림으로 구성
HTTP API를 통해 Loki 서버로 push

2. Loki 서버

로그 ingest 및 저장
쿼리 수행
단일 노드, Simple Scalable, Microservices 세 가지 모드 중 하나로 배포 가능

3. Grafana

로그 시각화
쿼리 실행(LogQL)
CLI 기반(LogCLI, Loki API) 조회도 가능

Loki 주요 특징

1. 확장성

Raspberry Pi 단일 노드부터 하루 페타바이트 규모까지 확장
읽기/쓰기 경로를 분리하여 개별적으로 스케일 아웃
필요 시 Kubernetes 마이크로서비스 형태로 각 컴포넌트 분리 가능

2. 멀티테넌시

하나의 Loki 인스턴스를 여러 테넌트가 공유
테넌트 간 로그/쿼리는 완전히 격리
Agent 단계에서 tenant ID를 설정하여 활성화

3. 타사 에이전트 지원

여러 외부 로그 수집기가 plugin 형태로 Loki에 로그 전송
기존 로깅 파이프라인을 유지하면서도 Loki를 도입 가능

4. 효율적인 저장 구조

chunk 기반 고압축 저장
로그 본문을 색인하지 않아 인덱스 크기가 작음
오브젝트 스토리지를 메인 저장소로 사용하여 비용 효율성 확보
SSD/HDD 중심의 로컬 저장 방식 대비 운영 복잡성 감소

5. LogQL

PromQL과 유사한 문법
로그 조회뿐만 아니라 로그 기반 메트릭 생성 가능
로그 기반 Alerting 구성에 유용

6. Alerting

Loki Ruler가 쿼리를 지속적으로 평가
결과에 따라 경보(Alert) 또는 액션 실행
Prometheus Alertmanager 또는 Grafana Alerting과 연동 가능

7. Grafana 생태계 통합

Grafana, Mimir, Tempo와 자연스럽게 연동
로그·메트릭·트레이스 상호 연관 분석이 용이해 e2e Observability 확보 가능

ssunw — Tue, 23 Jan 2024 23:10:57 +0900

http://www.linkedin.com/in/seongwoo-choi

쿠버네티스에서 동시성 제어와 리소스의 일관성을 보장하는 방법

ssunw — Sat, 20 Jan 2024 21:28:11 +0900

resourceVersion 개념

쿠버네티스는 최적화 된 Concurrency 를 달성하기 위해 resourcVersion 개념을 사용하며, 모든 쿠버네티스 리소스는 메타데이터에 resourceVersion 이라는 필드를 갖는다.

다시 말해, resourceVersion 은 클라이언트가 kubernetes 오브젝트가 변경된 시점을 확인하는 데 사용할 수 있는 내부 버전을 식별하는 문자열이다.

동작

etcd 의 record 가 업데이트 될 때, 이전에 저장된 value 와 비교하여 크로스 체크를 하는데, 만약 매치되지 않은 value 일 경우 409 status code 를 반환하며, object 가 수정될 경우 API 서버에 의해 resourceVersion 이 변경된다.

만약 PUT 작업(리소스 변경 시)의 경우, 시스템은 resourceVersion 의 현재 값이 지정된 값과 일치하는지 확인하여 읽기/수정/쓰기 라는 일련의 Cycle 에서 해당 리소스에 다른 변경(실패한 이력 말고 성공한 이력)이 없었는지 확인한다.

resourceVersion 은 etcd 의 mod_revision 에 의해 지원된다.

resourceVersion 의 값을 예측하는 방법은 일반적으로 API 서버로 GET 요청을 보내는 방법밖에 없다.
GET 요청으로 값을 예측하는 방법은 반드시 클라이언트에서 불투명하게 처리되어야 하고, 서버로 수정되지 않은채 전달되어야 한다.

즉, resourceVersion 은 namespace 나 kubernetes 상의 다른 리소스와 관련된 값이 아니라는 것이다.

resouceVersion 의 값은 etcd 의 시퀀서와 값이 일치하도록만 되어 있지만, 나중에는 kind 나 namespace 별로 상태를 샤딩하거나 다른 스토리지 시스템으로 포팅하는 것처럼 resourceVersion 의 구현이 변경될 것으로 예상된다.

만약 PUT 요청을 통해 리소스를 변경하는 도중에 confilct 이 발생할 경우, client 는 API 서버로 GET 요청을 통해 리소스를 다시 가져온 뒤, 변경 사항을 새로 적용한다.

이 메카니즘을 사용하면 여러 요청이 동시에 들어와 경합이 발생하더라도 문제 없이 해결할 수 있다.

동시에 리소스를 변경하는 케이스

아래와 같은 시퀀스가 병렬로 발생하면, Foo.Bar 에 대한 변경 사항이나 Foo.Baz 에 대한 변경 사항이 손실될 수 있다. 이를 막기 위해 나온 개념이 위에서 설명한 resourceVersion 이다.

동시에 Foo 를 변경하는 케이스

resourceVersion 을 지정할 경우, 누가 리소스에 값을 Write 하든, 리소스를 성공적으로 변경하든 API 서버는 크게 신경쓰지 않는다.

단지, 두 client 중에 하나가 실패하고 특정 client 의 Foo 가 저장된다는 것만을 알면 된다.

이런 성질을 이용하여 resourceVersion 은 캐싱이 됐을 때 읽기 후 쓰기 일관성을 위해 향후 다른 작업(ex. GET, DELETE)의 전제 조건으로 사용될 수 있다.

예를 들어, "Watch" 작업은 API 서버에 쿼리 매개변수를 사용해서 특정 resourceVersion 을 갖는 값을 가져오고, 해당 리소스가 변경되어 resourceVersion 이 변경될 경우를 감지한다.

활용

이 처럼 resourceVersion 을 잘 이해하면, go-client 라이브러리를 사용하여 resourceVersion 이 변경되는 것을 감지하여 사이드카 컨테이너를 강제로 injection 하거나, 특정 annotaion 이나 label 을 강제로 injection 하는 등의 작업을 할 수 있을 것으로 생각한다.

golang http 패키지

ssunw — Mon, 27 Nov 2023 14:23:21 +0900

http.Servemux & http.HandleFunc

ServeMux는 HTTP 요청 멀티플렉서이다. 여기서 멀티플렉서는 라우터, 컨트롤러랑 동일한 뜻을 갖고 있다고 보면 된다.

수신되는 각 요청의 URL 을 등록된 패턴과 비교하고, URL과 가장 일치하는 패턴의 핸들러를 호출한다.

MVC 패턴의 Controller 역할이라고 보면 된다.

또한 ServeMux는 URL Request Path 와 Host Header 를 임의로 처리하는데, 포트 번호를 제거하거나 반복되는 슬래시가 포함된 요청을 동등하고 깔끔한 URL로 리 다이렉션한다.

아래는 server.go 에 작성된 http 패키지 코드이다.

// DefaultServeMux is the default ServeMux used by Serve.
var DefaultServeMux = &defaultServeMux

var defaultServeMux ServeMux

// HandleFunc registers the handler function for the given pattern
// in the DefaultServeMux.
// The documentation for ServeMux explains how patterns are matched.
func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
	DefaultServeMux.HandleFunc(pattern, handler)
}

HandleFunc 메소드는 DefaultServeMux 의 HandleFunc 를 사용한다.

mux := http.NewServeMux()
mux.HandleFunc("/", handlerFunc)

http.HandleFunc("/", handlerFunc)

http.HandlFunc() 메소드는 ServeMux 구조체의 메소드이다. 그래서 mux 를 새로 생성하여 HandleFunc 를 구현할 수도 있다.

http.HandlerFunc

아래 코드는 server.go 에 작성된 http 패키지 코드이다.

http 패키지를 보면 HandlerFunc 라는 함수 타입을 선언했는데 해당 타입은 ResponseWriter 와 *Request 를 매개변수로 갖는 함수 타입이다. 즉 구조체 타입을 생성하는 것 말고도 함수 타입을 생성할 수 있다.

함수 타입은 다른 타입과 동일하게 취급된다. 중요한 점이자 신기한 점은 함수 타입이 구조체 타입처럼 메소드를 가질 수 있다는 점이다.

그래서 http.HandleFunc 타입은 스스로를 호출하는 ServeHTTP 메소드를 구현할 수 있다.

http.HandleFunc 은 http.HandlerFunc 를 매개변수로 받는다. http.HandlerFunc 는 함수 타입이며, ServeHTTP 라는 메소드를 갖는다.

ServeHTTP 메소드를 구현하기 때문에 HandlerFunc 는 Handler 인터페이스이다.

http.Handler 는 ServeHTTP(ResponseWriter, *Request) 메소드를 갖는 인터페이스 타입이다.

type Handler interface {
	ServeHTTP(ResponseWriter, *Request)
}

// The HandlerFunc type is an adapter to allow the use of
// ordinary functions as HTTP handlers. If f is a function
// with the appropriate signature, HandlerFunc(f) is a
// Handler that calls f.
type HandlerFunc func(ResponseWriter, *Request)

// ServeHTTP calls f(w, r).
func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
	f(w, r)
}

pathHandler 는 http.HandlerFunc 타입의 메서드 시그니처와 일치하기 때문에 HandlerFunc로 변환되어 router 변수에 할당된다.

여기서 메서드 시그니처는 함수 또는 메서드의 형태를 설명하는 것으로 메서드의 이름, 매개변수 유형, 반환 유형 등을 포함한다.

pathHandler 함수가 http.HandlerFunc 의 메서드 시그니처를 따르는 것을 확인할 수 있다.

다시 말해 func(w http.ResponseWriter, r *http.Request) 와 같은 형태를 가지면 http.HandlerFunc 타입으로 변환되어 http.Handler 인터페이스를 구현하는데 사용할 수 있다.

func pathHandler(w http.ResponseWriter, r *http.Request) {
	switch r.URL.Path {
	case "/":
		homeHandler(w, r)
	case "/contact":
		contactHandler(w, r)
	default:
		pageNotFoundHandler(w, r)
	}
}

func main() {
  var router http.HandlerFunc
  router = pathHandler
  fmt.Println("Starting the server on :3000...")
  http.ListenAndServe(":3000", router)
}


func main() {
  fmt.Println("Starting the server on :3000...")
  // int(r) 이나 float64(a) 처럼 pathHandelr 를 변환하는 것이다.
  // 즉, router 변수를 선언하고 pathHandler 를 값으로 넣은 것을 
  // http.HandleFunc(pathHandler) 로 줄인 것
  http.ListenAndServe(":3000", http.HandlerFunc(pathHandler)) 
}

http.ListenAndServe 와 Interface

아래는 server.go 에 작성된 http 패키지 코드이다.

// A Handler responds to an HTTP request.
//
// ServeHTTP should write reply headers and data to the ResponseWriter
// and then return. Returning signals that the request is finished; it
// is not valid to use the ResponseWriter or read from the
// Request.Body after or concurrently with the completion of the
// ServeHTTP call.
//
// Depending on the HTTP client software, HTTP protocol version, and
// any intermediaries between the client and the Go server, it may not
// be possible to read from the Request.Body after writing to the
// ResponseWriter. Cautious handlers should read the Request.Body
// first, and then reply.
//
// Except for reading the body, handlers should not modify the
// provided Request.
//
// If ServeHTTP panics, the server (the caller of ServeHTTP) assumes
// that the effect of the panic was isolated to the active request.
// It recovers the panic, logs a stack trace to the server error log,
// and either closes the network connection or sends an HTTP/2
// RST_STREAM, depending on the HTTP protocol. To abort a handler so
// the client sees an interrupted response but the server doesn't log
// an error, panic with the value ErrAbortHandler.
type Handler interface {
	ServeHTTP(ResponseWriter, *Request)
}

...

// ListenAndServe listens on the TCP network address addr and then calls
// Serve with handler to handle requests on incoming connections.
// Accepted connections are configured to enable TCP keep-alives.
//
// The handler is typically nil, in which case the DefaultServeMux is used.
//
// ListenAndServe always returns a non-nil error.
func ListenAndServe(addr string, handler Handler) error {
	server := &Server{Addr: addr, Handler: handler}
	return server.ListenAndServe()
}

http.ListenAndServe 메소드는 Handler 인터페이스를 매개변수로 입력받는다.

Handler 인터페이스는 ServeHttp(ResponseWriter, *Request) 메소드를 구현하면 Handler 인터페이스로 취급을 할 수 있다.

아래 코드처럼 Router 구조체를 만들고 해당 구조체가 ServeHttp(ResponseWriter, *Request) 메소드를 구현하여 Handler 인터페이스 타입이 됐다.

그래서 http.ListenAndServe 메소드에 매개변수로 router 를 입력할 수 있다.

추가적으로 Router 구조체에 필드를 추가하여 ServeHTTP 메소드에서 구조체 필드를 가져와 사용하는 등의 작업을 할 수 있다.(db 커넥션 등..)

package main

import (
	"fmt"
	"net/http"
)

type Router struct {
}

func (s Router) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	switch r.URL.Path {
	case "/":
		homeHandler(w, r)
	case "/contact":
		contactHandler(w, r)
	default:
		pageNotFoundHandler(w, r)
	}
}

func main() {
	var router Router
	fmt.Println("Starting the server on :3000!")
	http.ListenAndServe(":3000", router)
}

Redis Eviction

ssunw — Wed, 8 Nov 2023 18:34:42 +0900

Redis에서 데이터를 저장할 때 메모리가 부족할 경우 "eviction"이 발생할 수 있다.

Eviction은 Redis가 메모리를 확보하기 위해 일부 데이터를 제거하는 프로세스를 의미하고, 일반적으로 이러한 eviction은 다음과 같은 이유로 발생할 수 있다..

메모리 한계 도달: Redis는 메모리가 가득 차면 eviction 정책을 트리거하여 데이터를 삭제한다. 이때 Redis는 설정된 eviction 정책에 따라 어떤 데이터를 삭제할지 결정한다.
maxmemory 설정: Redis에서는 메모리 사용량을 제한하는 maxmemory 옵션이 있고, 이 옵션을 설정하면 Redis는 설정된 한계에 도달했을 때 eviction을 수행하여 메모리 사용량을 제한한다.
expire 설정: 데이터가 만료되면(설정된 TTL이 만료되는 경우) Redis는 eviction을 수행하여 만료된 데이터를 삭제한다.
LRU(Least Recently Used) 정책: Redis는 LRU 정책을 사용하여 가장 최근에 사용되지 않은 데이터를 삭제한다. 이는 데이터가 오랫동안 사용되지 않은 경우 eviction을 유발할 수 있다.

Eviction은 메모리 관리를 위해 필수적인 과정이지만, 잘못된 eviction 정책 설정 또는 메모리 부족으로 인해 예상치 못한 데이터 손실이 발생할 수 있다. 따라서 Redis를 운영할 때는 메모리 사용량을 모니터링하고 적절한 eviction 정책을 설정하여 데이터 손실을 방지해야 한다.

Redis Eviction 을 방지하는 가장 쉬운 방법은 인스턴스 타입을 높여 가용 메모리를 늘리는 방법이다..

jvm heap memory

ssunw — Tue, 31 Oct 2023 21:17:10 +0900

jvm heap memory

java -XX:InitialRAMPercentage=60.0 -XX:MaxRAMPercentage=60.0 -jar myapp.jar
- java heapsize 를 할당받은 메모리의 60% 로 설정
java -XX:+PrintFlagsFinal -version | grep HeapSize
- 리눅스에서 자바 max 힙사이즈 크기 확인

자바 애플리케이션의 최대 힙 메모리 크기를 퍼센테이지로 가져갈 때 몇 퍼센트를 가져가는 것이 좋은지 여부는 애플리케이션의 특성에 따라 다릅니다. 일반적으로 애플리케이션이 사용하는 메모리 크기의 60~70%를 최대 힙 메모리 크기로 설정하는 것이 좋다.

이렇게 하면 애플리케이션이 충분한 메모리를 사용할 수 있으면서도 메모리 부족 오류가 발생할 가능성을 줄일 수 있다.

그러나 애플리케이션의 특성에 따라 최대 힙 메모리 크기를 더 높거나 낮게 설정해야 할 수도 있다.

예를 들어, 애플리케이션이 많은 양의 메모리를 사용하는 경우 최대 힙 메모리 크기를 더 높게 설정해야 한다.
반대로, 애플리케이션이 적은 양의 메모리를 사용하는 경우 최대 힙 메모리 크기를 더 낮게 설정해야 한다.

최대 힙 메모리 크기를 설정할 때는 애플리케이션의 성능 테스트를 통해 최적의 크기를 찾는 것이 좋다.

자바 힙메모리 사이즈란?

자바 힙 메모리 크기는 자바 가상 머신이 할당할 수 있는 최대 메모리 크기를 결정 한다.

힙 메모리는 자바 객체를 저장하는 데 사용되므로, 힙 메모리 크기가 클수록 더 많은 자바 객체를 저장할 수 있다.
그러나 힙 메모리 크기가 너무 크면 네이티브 메모리 부족 오류가 발생할 수 있다. 따라서 애플리케이션의 특성에 맞는 적절한 힙 메모리 크기를 설정하는 것이 중요하다.

일반적으로 애플리케이션이 사용하는 메모리 크기의 60~70%를 최대 힙 메모리 크기로 설정하는 것이 좋다.
이렇게 하면 애플리케이션이 충분한 메모리를 사용할 수 있으면서도 메모리 부족 오류가 발생할 가능성을 줄일 수 있다.

다음은 힙 메모리 크기가 애플리케이션에 미치는 영향에 대한 몇 가지 예시다.

힙 메모리 크기가 너무 작으면 애플리케이션이 충분한 메모리를 사용할 수 없어 성능이 저하될 수 있다.
힙 메모리 크기가 너무 크면 메모리 부족 오류가 발생할 수 있다.
힙 메모리 크기가 적절하면 애플리케이션이 충분한 메모리를 사용할 수 있어 성능이 향상될 수 있다.

GC가 발생하지 않았는데 Java 애플리케이션이 OOM이 발생했다면, 다음과 같은 원인이 있을 수 있다.

Max Heapsize가 너무 크다. Max Heapsize는 애플리케이션이 사용할 수 있는 최대 heap 크기를 지정한다. Max Heapsize가 너무 크면 애플리케이션이 너무 많은 메모리를 사용해서 OOM이 발생할 수 있다.
애플리케이션이 메모리를 너무 많이 사용한다. 애플리케이션이 너무 많은 메모리를 사용하면 OOM이 발생할 수 있다. 애플리케이션이 메모리를 많이 사용하는지 확인하고, 메모리 사용량을 줄일 수 있는 방법을 찾아야 한다.
애플리케이션에 메모리 누수가 있다. 애플리케이션에 메모리 누수가 있으면 OOM이 발생할 수 있다. 메모리 누수가 있는지 확인하고, 메모리 누수를 수정해야 한다.
운영 체제의 메모리 제한이 있다. 운영 체제의 메모리 제한이 있으면 OOM이 발생할 수 있다. 운영 체제의 메모리 제한을 확인하고, 애플리케이션이 사용할 수 있는 메모리량을 늘려야 한다.

SGP(Security Group for Pod)

ssunw — Tue, 31 Oct 2023 21:12:44 +0900

SGP

VPC CNI 는 노드(instance)의 ENI 와 연결된 보안 그룹을 사용한다.

즉, Node 에 띄워지는 모든 Pod 들은 Node 의 보안 그룹을 사용하게 된다.

이 말은 Node 보안 그룹을 Pod 가 사용하기 때문에 불필요한 리소스에 접근을 할 수 있게 된다.

그러나 Security Group for Pods 를 사용하면 개별 Pod 에 Security Group 을 사용할 수 있게 된다.

VPC CNI 에서 ENABLE_POD_ENI=true 를 설정하면 vpc cni 애드온이 각 클러스터의 노드에 vpc.amazonaws.com/has-trunk-attached=true Lable 을 추가한다.

“aws-k8s-trunk-eni” 라는 trunk interface 를 생성하여 노드에 연결한다. 노드의 인스턴스 타입에 따라 브랜치 네트워크 인터페이스 갯수와 IP capacity 가 달라진다.

m5.large 타입의 경우 ENI 를 최대 29개 사용할 수 있다. 즉, 최대 29개의 Pod 가 뜰 수 있다는 것이다. 노드의 최대 파드 수를 조정할 수 있기는 하다.

Amazon EC2 노드에 사용 가능한 IP 주소 증량 - Amazon EKS

관리형 노드 그룹은 maxPods의 값에 최대 수를 적용합니다. vCPU가 30개 미만인 인스턴스의 경우 최대 수는 110이고 다른 모든 인스턴스의 경우 최대 수는 250입니다. 이 최대 수는 접두사 위임의 활성

docs.aws.amazon.com

SGP 를 할당받은 pod 가 node의 kubelet 에서 probe(startup 이나 readiness) 통신이 안 될 경우, DISABLE_TCP_EARLY_DEMUX=true 로 변경해야 한다.(initContainer 섹션에서 DISABLE_TCP_EARLY_DEMUX의 값을 true로 변경)

elasticache network exceeded

ssunw — Tue, 31 Oct 2023 21:11:44 +0900

redis

redis, memcached network exceeded 가 발생할 경우
- latency 가 밀린다.
- worker 가 일을 다하고 있어서, 과부하 상태가 된다.(php의 경우 fpm 을 max 까지 사용)
redis memory 가 꽉 찼을 경우 어떤 일이 발생?
- eviction 발생 ⇒ 키가 버려짐(LRU 방식)
- swap memory 를 많이 사용하게 됨(why? 사용 가능한 메모리가 적기 때문)
- 어떤 키를 제거할까? ⇒ get cmd 를 오랫동안 하지 않는 key, set cmd 한지 오래된 key?, ttl, key expire 등… 전략은 다양하다.

HikariPoolConnection Error

ssunw — Tue, 31 Oct 2023 21:09:40 +0900

HikariPoolConnection Error

DB CPU 사용률이 95% 까지 치솟자 애플리케이션에서 HikariPoolConnetion Error 발생 => Connectio Timeout 발생 ⇒ AWS Target Group 에 연결된 애플리케이션이 Kill(exit signal) Signal 을 통해 종료 ⇒ ALB 단에서 502 를 응답

Elasticache NetworkBytes In/Out

ssunw — Tue, 31 Oct 2023 21:08:00 +0900

Elasticache Redis

Redis NetworkBytes In/Out 이 높을 경우 생기는 문제
1. 네트워크 정체: Redis 서버가 대량의 수신 및 발신 데이터를 처리하는 경우 높은 네트워크 바이트 입출력은 네트워크 정체를 나타낼 수 있습니다. 이는 전체 네트워크 성능에 영향을 미치고 대기 시간이 증가하거나 응답 시간이 느려질 수 있습니다.
2. 대역폭 사용량 증가: 높은 네트워크 바이트 입/출력은 Redis 서버가 네트워크를 통해 많은 양의 데이터를 전송하고 있음을 의미합니다. 이것은 특히 Redis가 많은 수의 클라이언트에 서비스를 제공하거나 상당한 데이터 로드를 처리하는 시나리오에서 상당한 네트워크 대역폭을 소비할 수 있습니다.
3. 잠재적인 성능 영향: Redis 서버가 높은 네트워크 트래픽을 처리하는 데 어려움을 겪고 있는 경우 성능이 저하될 수 있습니다. 네트워크 바이트 입/출력이 증가하면 CPU 및 메모리와 같은 서버 리소스에 추가 부담이 가해져 대기 시간이 길어지고 응답 시간이 느려질 수 있습니다.
4. 네트워크 최적화의 필요성: 네트워크 바이트 입출력이 지속적으로 높은 경우 잠재적인 네트워크 최적화 전략을 조사할 가치가 있습니다. 여기에는 Redis 서버 구성 최적화, 네트워크 인프라 개선 또는 빈번한 네트워크 요청의 필요성을 줄이기 위한 캐싱 메커니즘 구현이 포함될 수 있습니다.
Redis Commands Metric
- Redis에서 "commands" 메트릭은 Redis 서버에서 실행한 총 명령 수의 측정값
- Redis 서버의 워크로드 및 사용량을 모니터링하고 이해하는 데 유용한 메트릭

ec2 인스턴스 기반에서 동작하는 java application 502 발생

ssunw — Tue, 31 Oct 2023 21:05:33 +0900

ec2 인스턴스에서 java 애플리케이션이 OOM 이 나면서 실제 애플리케이션에 접근할 때 502 를 떨구지만, ASG 는 healthy 상태로 판단하고 인스턴스 교체를 안 할 수 있다.
- OOM 이 발생해도 인스턴스 상태체크를 통과할 수 있는 원인 중 하나는 Java 프로세스가 OS전체 메모리가 아닌 정해놓은 heap 메모리에 도달하게 되면 해당 프로세스는 OOM이 발생되어 해당 프로세스만 Kill이 되는데요, 이때 시스템 전체 메모리 사용률이 과도하게 사용되지 않는다면 인스턴스 통신에는 문제가 없기 때문에 인스턴스 상태체크는 통과하게 됩니다.
```
지속적으로 발생할 경우 프로세스의 Heap 메모리 사용량을 조정해볼수 있지만 Auto Scaling 그룹에 Elastic Load Balancing 상태 확인을 추가하여 EC2의 상태체크 뿐 아니라 Elastic Load Balancing 상태 검사에도 실패할 경우에 인스턴스를 비정상으로 간주하여 교체할 수 있습니다. ALB의 경우 Application 의 상태체크를 하기 때문에 이 방법을 고려하여 추가해 보시길 바랍니다.
이 부분은 Network 의 범위이기 때문에 Linux profile의 엔지니어로써 Best Effort 로 최대한 관련 자료를 제공드린 점 양해해 주시면 감사하겠습니다.
```

pods/exec 서브리소스 권한

ssunw — Fri, 31 Mar 2023 11:26:02 +0900

jenkins agent pod 를 사용하면서 pod 에 적절한 권한을 부여하는 과정에 pods/exec 의 권한에 대해 알아볼 기회가 생겼습니다.

pods/exec 의 get/watch/list 권한과 get/watch/list/create 권한의 차이점은 다음과 같습니다.

1. get/watch/list 권한을 부여했을 때:

- 파드 내부의 컨테이너에서 실행되는 명령 경로에 대한 정보를 가져올 수 있습니다.

- 파드에 대한 리소스 사용량 정보, 실행 중인 컨테이너의 상태 정보 등을 가져올 수 있습니다.

- 작업자의 작업에 대한 초기 진단 및 디버깅을 수행할 수 있습니다.

- 컨테이너의 리소스 정보를 모니터링하고 관리할 수 있습니다.

2. get/watch/list/create 권한을 부여했을 때:

- create 서브리소스에 대한 권한을 갖게 되며, 파드 내부의 컨테이너에서 실행할 명령 경로를 지정할 수 있습니다.

- 작업자의 작업에 대한 모니터링, 진단 및 디버깅, 그리고 컨테이너의 리소스 관리를 수행할 수 있으면서도 보안 요소를 고려합니다.

- 따라서, 보안을 강화하기 위해서는 권한 설정 시에 파드 내부 상세 정보를 기반으로 적절한 권한 부여 및 서비스 계정 설정을 수행해야 합니다.

즉, get/watch/list/create 권한을 부여하면 파드 내부의 컨테이너를 직접적으로 조작할 수 있는 권한을 가지게 되며, 보안 상의 고려사항이 더욱 중요해집니다. 이에 반해, get/watch/list 권한은 파드 내부의 상태 정보 및 리소스 사용량 정보를 가져올 수 있지만, 직접적으로 컨테이너를 조작하는 권한은 없습니다.

'파드 내부의 컨테이너에서 실행할 명령 경로'는 exec API를 사용하여 쿠버네티스 클러스터에서 작동되고 있는 Pod의 컨테이너에서 실행할 Shell 명령어 또는 프로세스를 지정합니다.예를 들어, 다음 명령은 nginx라는 컨테이너가 실행되고 있는 Pod의 /var/log/nginx/access.log 파일의 일부분을 확인합니다.

$ kubectl exec <pod-name> -c nginx -- tail -f /var/log/nginx/access.log

위 명령에서 exec API는 쿠버네티스 클러스터 내에서 실행되고 있는 Pod에 지정한 Shell 명령어 tail -f /var/log/nginx/access.log를 실행시키라고 지시하게 됩니다.

즉, 이 과정에서 get/watch/list/create 서브리소스 엔드포인트를 통해 컨테이너의 로그를 확인하거나 컨테이너에 명령을 전송합니다.

따라서, 파드 내부의 컨테이너에서 실행할 명령 경로를 지정할 수 있다는 것은 쿠버네티스 클러스터에서 실행 중인 파드의 컨테이너에서 Shell 명령어 또는 프로세스를 실행할 수 있다는 것을 의미합니다.

AWS IAM

ssunw — Tue, 18 Oct 2022 21:27:27 +0900

Policy

AWS IAM 정책은 5가지 형태의 구조를 가지고 있다.

Effect
Principal
Resources
Action
Condition

누가(Principal) 대상(Resources)에 작업(Action)을 조건(Condition)에 따라 허용(Effect)할지 말지를 정해 놓은 정책이다. 이 정책이 적용할 대상은 Identity 가 될 수도 resource 가 될 수도 있다.

Identity 기반 정책

누가(Principal) 대상(Resource)에 작업(Action)을 조건(Condition)에 따라 허용여부(Effect)를 결정하는 것

간단히 말하자면 행위자(사람)에게 부여하는 정책이다.

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": "s3:GetObject",
			"Resource": "arn:aws:s3:::bizhub.hy"
		}
	]
}

위 정책은 “bizhub.hy 라는 s3 버킷에 읽기 권한을 부여함” 이라는 정책이다. 그런데 누가? Principal 이 빠져있다. 왜냐하면 이 정책은 사용자에게 부여하기만 하면 그 사용자는 “bizhub.hy 라는 s3 버킷에 읽기 권한을 부여함” 이라는 권한을 흭득하기 때문이다.

여기서 말하는 사용자는 IAM user, group, SAML 인증된 사용자 등을 의미한다.

일일이 누가(Principal)을 정의하지 않아도 되기 때문에 모듈화 되어 재활요이 가능하다는 특징이 있다.

만약 100명의 유저에게 “bizhub.hy 라는 s3 버킷에 읽기 권한을 부여함” 정책을 주려면 100개의 정책을 만들어 일일이 누구에게를 지정해야 할 것이다.

사용자, 그룹 등 대상에게 정책을 추가하기만 하면 된다.

Resource 기반 정책

대상(Resource)이 누구(Principal)에 작업(Action)을 조건(Condition)에 따라 허용 여부(Effect)를 결정하는 것

대상에게 부여되는 정책입니다.

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "AllowS3GetObject",
			"Effect": "Allow",
			"Principal": {
				"AWS": "arn:aws:iam:123456789:user/a-user-1"
			},
			"Action": "S3:GetObject",
			"Resource": "arn:aws:s3:::bizhub.hy"
		}
	]
}

위 정책은 “bizhub.hy 라는 S3 버킷에 읽기 권한을 계정 123456789 의 a-user-1 에게 부여함” 이라는 정책이다.

identity 기반 정책과 다르게 Principal 이라는 “누구”가 정의되어야 한다.

identity 기반 정책인 정의된 정책들을 유저에게 부여했다면 리소스 기반 정책은 해당하는 대상에 직접 정의해야 한다.

S3 콘솔의 버킷 정책에서 정의할 수 있다.

사람에게 정책을 부여해야 할지 똔느 대상에게 정책을 부여해야 할지 또는 둘 다에게 부여해야 할지 고민될 것이다.

예를 들어 Account1 의 사용자 user-1 과 s3 버킷 myS3 가 있다고 가정하고 이들에게 읽기 권한을 주고자 한다.

Account1 의 user1 는 Account1 의 myS3 에 대해 읽기 권한을 허용함

Account1 의 myS3 에는 Account1 의 user1 에게 읽기 권한을 허용함

둘 중 하나의 정책만 부여되기만 하면 권한을 부여 받을 수 있다.

그런데 만약, Account2 계정의 user-2 가 Account1 계정의 S3 버킷 myS3 에 읽기 권한을 얻고자 한다면?

Account2 의 user-2 는 Account1 의 myS3 에 읽기 권한을 허용함

Account1 의 myS3 에는 Account2 의 user-2 에게 읽기 권한을 허용함

IAM 의 정책이 사용자(Identity) 와 자원(Resource) 에 부여됨과 차이점에 대해 알 수 있었다. 정책의 경우 한 번 부여되게 되면 영구적으로 권한을 가지게 된다는 특징을 가지고 있어 보안상 우려가 될 수 있다.

Condition 을 통해 특정 아이피, 특정 시간대에만 권한을 허용해 줄 수 있지만 기능이 한정적이다. 권한을 임시적으로 부여할 수 있는 역할(Role) 이 존재한다.

Role

정책은 역할과 IAM 사용자에게 부여할 수 있다. 정책은 한 사람, 한 그룹 단위로 할당해주지만 역할은 다수의 사람이 역할을 맡을 수 있다.

액세스 키 또는 암호를 알고 있다면 일부로 이를 바꾸지 않는 한 영원한 크레덴셜이다.

임시 보안 자격 증명은 유효한 시간이 지난 후에는 사용 불가능한 크레덴셜이다. IAM 사용자가 역할을 맡는다는 것은 임시 보안 자격 증명을 통해 임시적인 시간(에를 들어, 1시간) 동안만 역할을 맡고 그 이후에는 역할을 반납한다.

정책은 한 번 부여한 뒤 회수하지 않는 한 영구적으로 권한을 부여받는다.

IAM 사용자가 S3 버킷에 접근하고 싶을 때, 두 가지 방식으로 권한을 부여할 수 있다.

정책을 사용자에게 할당한다.
역할을 위임받는다.

아래와 같은 정책을 생성한다. bizhubcentrify 라는 s3 버킷에 대해 읽기 쓰기 권한을 얻는 정책을 만들고 이 정책을 IAM 사용자에게 할당한다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ReadWrite",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::bizhubcentrify"
            ]
        },
        {
            "Sid": "AllowList",
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets",
                "s3:GetBucketLocation"
            ],
            "Resource": "*"
        }
    ]
}

Sid : 아주 간단하게 보자면 제목, 부제 정도로 생각하면 될 것 같다.

Effect : 해당 Resource 에 Action 을 허용할 것인지 거부할 것인지를 작성한다.

Resource : 내가 접근하고자 하는 AWS Resource 에 대한 arn 을 작성한다. 이 부분은 더 찾아볼 것

정책(Policy)이 아닌 역할(Role)을 통해 권한을 부여받는 방식

역할을 생성한 뒤 정책을 연결한다. 그리고 이 역할을 IAM 사용자에게 임시적으로 부여할 것이다.

IAM 사용자가 S3AccessS3 assume 역할을 위임받은 것을 볼 수 있다. 이 역할은 1시간 뒤에 반납되게 된다. 1시간 뒤에는 다시 아무런 권한을 가지지 못한 상태로 남게 된다.

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": {
				"AWS": "arn:aws:iam::598944169130:user/root"
			},
			"Action": "sts:AssumeRole"
		}
	]
}

Principal : AWS: arn…. → 해당 iam user 에게 모든 권한을 OPEN

Action : sts:AssumeRole → 임시 권한이라는 뜻

역할을 사용하게 되면 정책을 부여하는 방식과 권한을 따로 회수하지 않아도 되는 장점이 있다. 예를 들어 s3 버킷에 파일 하나를 업로드하려 할 때 s3 버킷 쓰기 역할을 위임받은 후 필요한 작업을 완료하면 된다. 1시간이 지난 후 자동으로 역할에서 해제된다.

정책은 부여, 회수를 통해 권한 관리가 가능하다. AWS 에서는 사용자에게 부여된 정책이 언제 사용되고 얼마 동안 사용되지 않은지를 보여주는 Access manager 를 통해 정책의 관리를 도와주고 있다.

그만큼 정책관리는 매우 중요한 업무이고 역할을 통해 권한 관리를 하게 되면 관리 측면에서 매우 편해진다.

정책과 역할을 잘 관리할 수 있느냐는 클라우드 보안에 있어 매우 중요한 부분을 차지하고 있다.

SLA/SLO/SLI

ssunw — Mon, 17 Oct 2022 19:29:24 +0900

SLA/SLO/SLI

SLI 란 서비스의 성능 또는 안정성에 대한 정량적 측정이다. SLI 는 하나 이상의 모니터 기반 또는 메트릭 기반이다.

SLO 란 특정 기간 동안의 SLI 에 대한 목표 백분율이다.

SLA 란 클라이언트의 신뢰성 기대와 이를 충족하지 못한 서비스 제공자의 결과를 규정하는 클라이언트와 서비스 제공자 간의 명시적 또는 묵시적 합의

KPI(Key Performance Indicator)

KPI 는 성공을 측정하는데 사용될 수 있는 메트릭이다.

KPI 는 목표나 목적과는 다른, 목표를 달성하는 과정 중에 있는지 측정하는 메트릭이다. 따라서 수반하는 목표가 필요하다. 또한 KPI 를 모니터링하는 것은 목표를 달성하기 위해 필수적이다.

SMART 법칙
- Specific: KPI 는 구체적이어야 한다.
- Measurable: 모니터링하기 위해서 KPI 는 측정 가능해야 한다.
- Acheivable: 100% 는 성취하기 어렵다.
- Relevent: 관련있지 않은 KPI 는 목표 달성을 이끌어 낼 수 없다.
- Time-bound: 99% available-Per Year? Per month? Per day?

종류

Business KPI
- Return on Investment (ROI)
- Earning before interest and taxes (EBIT)
- Employee turnover, Customer churn
Technical or Software KPI
- Page view, User registration, Clickthroughs, Checkouts

Service Level

Indicators → Objectives → Agreement

SLI(Service Level Indicators)

Link

서비스의 측정 가능한 특성, A KPI

SLI 는 시간이 정해지고 측정 가능해야 한다.

ex) availability (i. e., how many requests are succeeding), latency (i.e., how long a request takes), throughput, correctness, data freshness, etc.)

적절한 SLI 설정

사용자가 직접 대면하는 서비스의 경우 주로 가용성, 응답 시간 그리고 처리량이 중요하다. 즉, 요청에 올바르게 응답할 수 있는지, 응답 시간은 얼마나 오래 걸리는지, 얼마나 많은 요청을 처리할 수 있는지가 중요하다는 뜻이다.
저장소 시스템의 경우 주로 응답 시간, 가용성 그리고 내구성이 중요하다. 즉, 데이터를 읽고 쓰는 데 어느 정도의 시간이 걸리는지, 필요할 때 데이터에 액세스할 수 있는지, 데이터는 안전하게 저장되어 있는지 등이 중요하다.
데이터 처리 파이프라인 같은 빅데이터 시스템은 처리량과 종단 간 응답 시간이 중요하다. 즉, 얼마나 많은 데이터를 처리할 수 있는지, 데이터가 유입된 이후로 작업을 완료하기까지의 시간은 얼마나 걸리는지(일부 파이프라인은 개별 처리 단계별로 목표 응답 시간을 설정하기도 한다.) 등이 중요하다.
모든 시스템은 정확성(correctness) 역시 중요하다. 올바른 응답이 리턴되었는지, 올바른 데이터를 조회했는지, 분석은 정확히 이루어졌는지 등을 고려해야 한다. 정확성은 시스템의 상태를 추적하기 위한 척도로서 매우 중요하지만 인프라스트럭처보다는 시스템의 데이터에 대한 것이므로 이를 달성하기 위해 SRE 가 관여하지는 않는다.

What to Measure: Using SLIs

성공 HTTP request 수 / 총 HTTP request (성공률) (Number of successful HTTP requests / total HTTP requests)
속도가 100ms 미만인 성공한 gRPC request / 총 gRPC request (Number of gRPC calls that completed successfully in < 100 ms / total gRPC requests)
전체 corpus 를 사용한 검색 결과 수 / 총 검색 결과 수, (Number of search results that used the entire corpus / total number of search results, including those that degraded gracefully)
10분 이내의 최신 재고 데이터를 사용한 상품 검색의 “재고 확인 횟수” request / 총 재고 확인 request (Number of “stock check count” requests from product searches that used stock data fresher than 10 minutes / total number of stock check requests)
사용자가 서비스 에러 없이 사용한 시간[분] / 총 사용자 사용 시간[분] (Number of “good user minutes” according to some extended list of criteria for that metric / total number of user minutes)

SLI 범위는 0% ~ 100% 이며, 0% 는 아무 것도 작동하지 않는 것이고, 100% 는 아무것도 손상되지 않은 것이다. 이 척도를 통해 매우 직관적으로 오류 예산(error budget)을 계산할 수 있다. SLO 는 목표로 하는 백분율이고 오류 예산은 100%에서 SLO 를 뺀 값이다.

예를 들어, SLO 가 99.9% 인 경우에, 한달 동안 3백만 개의 요청을 수신하는 서비스의 경우 한달 동안 3,000(0.1%) 개의 오류 예산(error budget) 을 가질 수 있다.

SLI 에서 I 는 측정 방법과 관계없이 사용자에게 중요하다고 생각하는 값이다.

SLI 사양

ex) Ratio of home page requests that loaded in < 100 ms

SLI 구현

단일 SLI 사양에는 여러 SLI 구현이 있을 수 있으며 각각은 품질(고객의 사용 경험을 얼마나 정확하게 포착하는지), 적용 범위(모든 경험을 얼마나 잘 포착하는지) 등에서 장단점(비용 등..)이 있다.

SLI 및 SLO 에 대한 첫 번째 시도가 정확할 필요는 없다. 가장 중요한 목표는 무언가를 제자리에 놓고 측정하고 피드백 루프를 설정하여 개선할 수 있도록 하는 것이 중요하다.

SLI 측정 방법 선택

이상적인 측정 방법으로는 고객 서비스 환경과 가장 근접하며 최소한의 노력만으로 측정할 수 있는 측정 방법을 선택해야 한다. 다음은 시간이 지남에 따라 구현하는 데 필요한 노력을 들여야 하는 순으로 나열한 것이다.

애플리케이션 서버 exports 및 인프라 metric 사용. 일반적으로 이런 metric 은 바로 접근할 수 있고 값을 빠르게 제공한다. 몇몇 툴에서는 기본적으로 SLO 를 설정해주는 도구가 포함되어 있다.
클라이언트 계측 사용(APM). 기존 시스템에는 일반적으로 내장된 클라이언트 계측이 없으므로 클라이언트 계측을 제공하는 APM 제품군 또는 FE 프레임워크를 사용하면 고객 만족도에 대한 유용한 정보를 빠르게 얻을 수 있다.
로그 처리 사용. 만약 로그가 있는 경우 로그 처리가 가장 좋은 방법이 될 수 있다.
합성 테스트 구현. 고객이 서비스를 사용하는 방법에 대한 기본 사항을 이해한 상태에서 서비스 수준을 테스트한다. 이 테스트는 트래픽이 적은 서비스처럼 쉽게 관측할 수 없는 장애들을 찾는데 도움이 될 수 있다.

SLI 구성 요소 유형

SLI 설정을 시작하는 가장 쉬운 방법은 시스템을 몇 가지 일반적인 유형의 구성 요소로 추상화하는 것입니다. 그런 다음 각 구성 요소에 대해 제안된 SLI 목록을 사용하여 서비스와 가장 관련성이 높은 항목을 선택할 수 있습니다. 요청 기반, pipelinem, Storage Type 이 존재.

해당 앱은 사용자의 핸드폰에서 클라우드 상의 HTTP API 와 상호작용 한다. 이 API 는 영구적인 스토리지 시스템에 변동사항을 작성하고, 파이프라인은 주기적으로 API 를 실행하여 데이터를 일자별로 쿼리하여 가장 높은 점수를 리그 테이블에 데이터를 저장한다.

이 점수 데이터는 3개의 분리된 DB 중 리그 테이블 DB 에 create 된다. 그리고 이 저장된 데이터들을 모바일 앱이나 웹사이트에서 사용할 수 있다.

또한, API 를 통해 게임이나 웹사이트에서 사용하는 사용자 정보를 유저 DB 에 저장 및 업로드한다.

이러한 아키텍쳐 구조에서, 우리는 사용자가 시스템과 어떻게 상호작용하는지 생각해 볼 수 있다. 그리고 어떤 종류의 SLI 가 다양한 관점의 유저 경험을 측정할 것인지 생각해야 한다.

사용자에게 가장 중요한 기능을 나타내는 SLI 타입을 선택하는 것이 좋다.

일반적인 사용자 경험과 long tail 법칙을 모두 포착하기 위해 여러 등급의 SLOs 로 여러 타입의 SLIs 를 사용하는 것이 좋다.

예를 들어, 90% 의 사용자들이 100ms 안으로 request 를 처리할 때, 10% 의 사용자들은 request 를 처리하는데 10초가 걸린다.

latency 기반 SLO 는 다양한 임계값을 설정하여 user base 를 포착한다. 90% 의 request 는 100ms 보다 빠르고 99% 의 request 는 400ms 보다 빠르다.

이런 원칙은 사용자의 서비스 경험을 측정하는 매개변수가 있는 모든 SLI 에 적용된다.

아래 테이블 2-1 은 다양한 유형의 서비스에서 사용할 수 있는 공통 SLIs 이다.

SLI 구현

첫 SLI 를 구현할 때는 최소한의 작업이 필요한 SLI 를 구현한다.

SLI 를 측정하기 위한 정보로는 availability, latency 를 사용할 수 있고, availability 를 측정하기 위해서는 성공/실패 상태를 알아야 하고, slow requests 의 경우 request 를 처리하는 시간을 알아야 한다. 즉, SLI 를 위해서는 해당 정보를 알기 위한 충분한 metric 들을 계측할 수 있어야 한다는 것이다.

클라우드 기반의 서비스를 사용할 경우 availability, latency 를 클라우드 기반의 모니터링 대시보드에서 사용할 수도 있다.(CloudWatch 메트릭을 바탕으로 자동 생성해주는 대시보드 등..)

이제 각각의 장단점이 존재하는 예제 아키텍쳐의 SLI 구현을 위한 다양한 옵션들을 확인해보자.

API and HTTP server availability and latency

HTTP status code 기반으로 SLI 를 구현할 수 있다. 쉽게 말하자면 availability SLI 는 successful 한 requests 의 비율이고, latency SLI 는 정의된 임계값보다 빠른 requests 의 비율이다.

SLI 는 구체적이고 측정가능해야 한다. What to Measure: Using SLIs 에 있는 잠재적인 SLI 후보군들을 요약하자면, SLI 로 아래와 같은 sources 를 하나 이상 사용할 수 있다.

Application server logs
Load balancer monitoring
Black-box monitoring
Client-side instrumentation

첫 SLI 를 구현할 때는 최소한의 작업이 필요한 SLI 를 구현하는 것이 좋다.

Pipeline freshness, coverage, and correctness

리그 DB 의 테이블을 업데이트하는 파이프라인의 경우, 데이터에 데이터가 업데이트 된 시간의 timestamp 를 포함한 watermark 가 기록된다. 아래 몇가지 SLI 구현 예제를 확인하자.

리그 DB 에서 주기적으로 새로운 레코드의 총합과 모든 레코드의 총합을 계산하는 쿼리를 실행한다. 이렇게 쿼리를 실행할 경우 얼마나 많은 사용자가 데이터를 확인하든 상관 없이 오래된(stale) 레코드를 확인할 수 있고 처리할 수 있다(의역).(This will treat each stale record as equally important, regardless of how many users saw the data.)
리그 DB 의 모든 클라이언트가 새로운 데이터를 Read 할 때 timestamp 가 적힌 watermark 를 확인하고 데이터가 request 됐음을 알리는 metric counter 를 증가시킨다. 만약 데이터가 미리 정의된 임계값보다 최신일 경우 다른 카운터를 증가시킨다.

위 두가지 options 들은 client-side 에서 구현이다. 그렇기 때문에 사용자 경험과 훨씬 더 밀접하게 연관된 SLI 를 제공한다.

해당 파이프라인은 처리해야 하는 레코드 수와 성공적으로 처리한 레코드 수를 exports 한다. 만약 파이프라인이 잘못 구성되었다면 이로 인해 올바른 메트릭을 잃을 수 있다.

correctness 를 측정하기 위한 몇 가지의 접근법이 존재한다.

known outputs 를 시스템 상에 밀어 넣었을 때 나오는 출력값이 기댓값과 일치하는 비율을 계산한다. 즉, 올바른 응답값을 받았는지에 대한 비율을 계산한다.(Inject data with known outputs into the system, and count the proportion of times that the output matches our expectations.)
데이터를 입력 받아 정확한 결과를 계산하기 위한 방법으로 파이프라인 자체의 중복을 제거하는 방법이 있다.(가격이 비싸기 때문에 적합하지 않다.)입출력 쌍을 사용하여 올바른 응답값의 비율을 계산한다. (Use a method to calculate correct output based on input that is distinct from our pipeline itself (and likely more expensive, and therefore not suitable for our pipeline). Use this to sample input/output pairs, and count the proportion of correct output records. This methodology assumes that creating such a system is both possible and practical.)

척도의 표준화

우리는 각각의 척도들의 최우선 원칙이 무엇인지를 매번 고민할 필요가 없도록 SLI 들에 대한 일반적인 정의를 표준화하기를 권장한다. 표준화된 정의 템플릿을 따르는 모든 수치들은 개별 SLI 의 명세서에서 생략해도 무방하다. 예를 들어보자.

집계 간격: '평균 1분'
집계 범위: '하나의 클러스터에서 수행되는 모든 태스크들'
측정 빈도: '매 10초'
집계에 포함할 요청들: '블랙박스 모니터링 잡이 수집한 HTTP GET 요청들'
데이터의 수집 방식: '모니터링 시스템에 의해 서버에서 수집'
데이터 액세스 응답 시간: '데이터의 마지막 바이트가 전송된 시간'

이처럼 모든 범용 지표에 대해 재사용 가능한 SLI 템플릿을 설정해두면 많은 노력을 절감할 수 있다. 또한 모든 사람들이 특정 SLI 가 의미하는 바를 좀 더 쉽게 이해할 수 있다.

SLO(Service Level Objectives)

Link

SLOs allow you to quantifiably measure customer happiness ⇒ 사용자 경험을 정량적으로 측정할 수 있게 해준다.

주어진 SLI 로 성취하고 싶은 목표나 숫자 지표 ex) 95%, 99% or 99.99% availability

SLO 는 성취 가능하고 관련 있어야 한다. 가능한 높은 목표를 세우는 것이 아니라, 사용자를 만족시킬 만큼에서 가격 효율적인 SLO 를 선택해야 한다. SLO 가 높을수록 높은 비용과 노력을 초래하기 때문이다.

SLO process overview

사용자 경험과 결제같은 비즈니스 측면에서 악영향을 끼칠 수 있는 metric 리스트를 뽑는다.
사용자 경험을 가장 정확하게 추적하기 위해서 SLI 로 사용할 metric 을 정한다.
SLO 목표 값과 SLO 측정 기간을 정한다.
SLI, SLO 및 오류 예산(error budget) 콘솔을 생성한다.
SLO 알람을 생성한다.

Step 1: 사용자 경험과 결제같은 비즈니스 측면에서 악영향을 끼칠 수 있는 action 리스트를 뽑는다.

사용자들이 서비스를 사용할 때 어떤 action 들이 있는지 생각한다. 온라인 이커머스 서비스이기 때문에 사용자들이 실제로 어떤 action 들을 하는지 생각해보면 아래와 같다.

상품 목록
결제
장바구니 추가

해당 액션들의 중요도를 따라 리스트 순위를 정해야 한다. 이커머스 서비스이기 때문에 사용자가 물건을 구매하는 것이 가장 중요하다.

결제
장바구니 추가
상품 목록

상품 목록의 우선 순위가 제일 밑인 것이 의아할 수 있다. 하지만 상품 목록은 결국 결제와 장바구니 추가에 의존하기 때문이다(아마 비즈니스에 대한 뜻 인 듯). 결제나 장바구니 추가보다 상품 목록이 더 중요하다고 말할 수 있을까?

중요하다고 생각한다면 상품 목록이 있어야 물건을 장바구니에 추가하고, 결제를 할 수 있다고 생각하는 것일 수 있다.

상품 목록은 하루종일 띄워져 있다. 그러나 장바구니에 물건을 추가하고 결제를 하는 작업은 그렇지 않다. 그렇기 때문에 구매 흐름에 따라 물건을 장바구니에 담고 결제를 하는 작업은 비즈니스 상 매우매우 중요한 작업이다.

step 2: 사용자 경험을 가장 정확하게 추적하기 위해 SLI 로 사용할 indicators 를 결정한다.

SLI 를 위한 다양한 indicators 중에 하나를 선택한다.

availability(request 성공 횟수), latency(request 지연율), 처리량, correctness, data freshness 등이 있다.

SLI 등식은 올바른 이벤트 / 유효한 이벤트 * 100 이다.

결제라는 중요한 이벤트에 대해서 SLI 를 측정하기 위해서는 어떤 과정들이 일어나는지 확인할 필요가 있다.

고객이 매장에서 제품을 구매하는 과정을 상상해보자. 먼저, 고객들은 어떤 물건을 살지 탐색하고 찾는다. 그 후에 물건을 카트에 담는다. 마지막으로 결제를 진행한다.

만약 고객들이 결제하는 과정까지 진행했다면 고객의 비즈니스를 확보했다고 할 수 있다. 그렇기 때문에 고객이 물건을 결제할 수 있도록 하는 것이 무척이나 중요하다.

Availability SLI

우리는 고객이 우리 서비스의 결제 기능을 사용하는 것을 목표로 하기 때문에 Availability SLI 를 선택할 것 이다. 우리가 원하는 것은 가용성 측면에서 결제 서비스가 얼마나 잘 수행되고 있는지를 알려주는 메트릭이다.

이커머스 플랫폼의 경우, 얼마나 많은 사용자가 결제를 시도했고 얼마 만큼의 request 가 실제로 성공했는지 모니터링 하기를 원한다. 즉, 성공한 request 의 수가 "good(올바른, 양호한)" 메트릭이다.

구체적으로 무엇을 측정하고 어디서 측정할 것인지가 중요하므로 availability SLI 는 다음과 같아야 한다.

(전체 요청 - HTTP Status 5XX 오류) / 전체 요청 * 100

3XX, 4XX 가 제외되는 이유는 서비스(서버)의 오류를 나타내는 이벤트를 계산하려 하기 때문에 전체 request 에서 3XX 리다이렉션, 4XX 오류를 제외한 5XX 만 체크한다.

Latency SLI

Link

고객들이 결제할 때 임계값 안의 시간으로 주문에 대한 response 가 오는지 체크한다. 즉, successful response 를 받는데 걸리는 시간을 측정하여 latency SLI 로 설정한다. 결제 비즈니스 상 response 가 반환되는 임계값을 500ms 로 설정한다. 즉, response latency 의 99% 는 500ms 이내에 수행되어야 한다.

"일반적으로 99번째 백분위수 지연 시간(p99)은 중앙값 지연 시간(median, p50)의 3~5배를 초과해서는 안 된다"

이전 백분위수를 기준으로 지연 시간 임곗값을 결정한 다음 각 버킷에 속하는 요청 수를 측정하는 것이 좋다.

Step 3: SLO 목표 설정 및 SLO 측정 기간 결정

예를 들어 한 달 동안 10,000개의 HTTP 요청이 있고 그 중 9,990개만 SLI 설정에 따라 성공적인 response 를 반환하는 경우 해당 월의 가용성은 9,990/10,000 or 99.9% 이다.

alert 가 의미 있도록 달성 가능한 SLO 를 설정하는 것이 중요하다. 보통 SLO 를 설정할 때는 historical trends 에서 시작하여 대다수의 고객들이 서비스에 만족하고 있다고 가정하는 것이 좋다. 즉, 비즈니스 상에서 원하는 목표와 수치를 설정하는 것이 이상적이다.

SLO 를 100% 만족하는 것은 현실성이 없으며 기대할 수도 없다. 이를 충족하려 하면 혁신과 배포의 속도가 저하되며 높은 비용을 소비하거나 지나치게 보수적인 솔루션이 된다. 그래서 오류 예산(error budget: SLO 를 만족하지 못하는 비율)을 산정하고 이를 일단위 혹은 주단위로 추적하는 것이 훨씬 더 나은 방안이다. 오류 예산(error budget) 역시 다른 SLO 들을 만족하기 위한 또 다른 SLO 일 뿐이다.

어떤 SLO 를 달성하지 못한 비율은 사용자가 인지한 서비스의 상태에 대한 유용한 척도가 된다. SLO 들을 일단위 혹은 주단위로 추적해서 트렌드를 파악하고 잠재적인 문제가 실제로 발생하기 전에 미리 그 조짐을 파악하는 것은 매우 유용하다.

목표치, 즉 SLO 를 설정하는 것은 순수한 기술적 활동이라고 보기는 어렵다. 그 이유는 SLI 와 SLO 를 어떻게 설정하는지가 제품과 사업에 영향을 미치기 때문이다.

현재의 성능을 기준으로 목표를 설정하지 말 것

시스템의 장점과 한계를 이해하는 것이 기본이므로 이것을 고려하지 않고 목표치를 설정하면 목표치를 달성하기 위해 시스템에 엄청난 노력을 투입하게 되고 결국 방대한 재설계 없이는 시스템의 향상이 불가능하게 된다.

최대한 단순하게 생각할 것

SLI 를 복잡하게 집계하면 시스템의 성능 변화를 명확하게 반영하지 못하고 그 원인을 파악하기 어렵게 된다.

자기 만족에 얽매이지 말 것

응답 시간의 저하 없이 시스템의 부하를 '무한정' 확장하는 것은 상당히 매력적인데다 '언제든지' 가능하기는 하지만 이런 요구는 현실성이 없다. 이런 이상을 실현 가능한 시스템은 디자인하고 구축하는 데 긴 시간을 필요로 할 뿐 아니라 운영 비용도 엄청나다. 게다가 십중팔구 사용자가 만족할 수 있는 수준을 필요 이상으로 초과할 것이다.

가능한 적은 수의 SLO 를 설정할 것

시스템의 특성을 잘 확인할 수 있는 최소한의 SLO 를 선택하는 것이 중요하다. 그리고 선택한 SLO 를 옹호할 수 있어야 한다. 만일 특정 SLO 를 인용했음에도 불구하고 우선순위에 대한 논의에서 밀린다면 그 SLO 는 굳이 설정할 필요가 없는 것이다. 그러나 제품의 모든 특성이 SLO 로 선정하기에 적합한 것은 아니다. SLO 를 이용해서 '사용자의 만족'을 정의하는 것은 상당히 어렵다.

처음부터 완벽하게 하려고 하지 말 것

SLO 정의와 목표는 시간이 지남에 따라 시스템의 동작을 살피면서 언제든지 다시 정의할 수 있다. 처음부터 지나치게 높은 목표를 설정해서 나중에 가서야 달성이 불가능한 것을 발견하고 그 목표를 완화하는 것보다는 우선은 조금 느슨한 목표를 설정한 후 조금씩 강화하는 것이 낫다.

SLA(Service Level Agreements)

만약 서비스가 특정 기대를 못 미쳤을 때, 고객 보상을 제공해주는 구속력있는 계약 = more restrictive version of SLO

SLA 에는 만약 서비스가 특정 가용성을 또는 퍼포먼스 기준을 유지하지 못했을 때 제공자에 가해지는 penalty 에 대해 적는다. 그리고 SLA 가 깨지면 고객은 제공자로부터 보상을 받는다.

모든 서비스에 SLA 가 있어야 하는 것은 아니지만 SLO 는 있어야 하며 SLO 의 기준은 SLA 보다 높아야 한다.

만약 SLA 가 95% availabilty 일 경우 SLO 는 95% availabilty 보다 높아야 한다는 것이다.

아래는 SLI, SLO, SLA 에 대한 예시이다.

SLI 로는 200 응답에 대한 latency 를 잡았고 SLO 로는 99% 의 latency(p99) 가 200ms 보다 작아야 한다. 또한, SLA 로는 99% latency 가 300ms 를 초과할 경우 보상을 지불하도록 설정됐다.

SLA/SLO/SLI 란?

ssunw — Fri, 30 Sep 2022 19:48:45 +0900

SLA/SLO/SLI

KPI(Key Performance Indicator)

KPI 는 성공을 측정하는데 사용될 수 있는 메트릭이다.

SMART 법칙
- Specific: KPI 는 구체적이어야 한다.
- Measurable: 모니터링하기 위해서 KPI 는 측정 가능해야 한다.
- Acheivable: 100% 는 성취하기 어렵다.
- Relevent: 관련있지 않은 KPI 는 목표 달성을 이끌어 낼 수 없다.
- Time-bound: 99% available-Per Year? Per month? Per day?

종류

Business KPI
- Return on Investment (ROI)
- Earning before interest and taxes (EBIT)
- Employee turnover, Customer churn
Technical or Software KPI
- Page view, User registration, Clickthroughs, Checkouts

Service Level

Indicators → Objectives → Agreement

SLI(Service Level Indicators)

서비스의 측정 가능한 특성, A KPI

SLI 는 시간이 정해지고 측정 가능해야 한다.

ex) Availability

SLO(Service Level Objectives)

주어진 SLI 로 성취하고 싶은 목표나 숫자 지표

ex) 95%, 99% or 99.99% availability

SLO 는 성취 가능하고 관련 있어야 한다.

가능한 높은 목표를 세우는 것이 아니라, 사용자를 만족시킬 만큼에서 가격 효율적인 SLO 를 선택해야 한다. SLO 가 높을수록 높은 비용과 노력을 초래하기 때문이다. SLO 를 최소화 해야 하고 어플리케이션이 SLO 를 크게 능가해서는 안된다.

SLA(Service Level Agreements)

만약 서비스가 특정 기대를 못 미쳤을 때, 고객 보상을 제공해주는 구속력있는 계약 = more restrictive version of SLO

모든 서비스에 SLA 가 있어야 하는 것은 아니지만 SLO 는 있어야 하며 SLO 의 기준은 SLA 보다 높아야 한다.

만약 SLA 가 95% availabilty 일 경우 SLO 는 95% availabilty 보다 높아야 한다는 것이다.

아래는 SLI, SLO, SLA 에 대한 예시이다.

SLI/SLO/SLA

SLI 로는 200 응답에 대한 latency 를 잡았고 SLO 로는 99% 의 latency 가 200ms 보다 작아야 한다. 또한, SLA 로는 99% latency 가 300ms 를 초과할 경우 보상을 지불하도록 설정됐다.

[Spring Boot] 아파치 카프카

ssunw — Tue, 30 Aug 2022 23:13:01 +0900

아파치 카프카는 ActiveMQ, Artemis, RabbitMQ 와 유사한 메시지 브로커이다. 그러나 카프카는 특유의 아키텍쳐를 가지고 있다.

카프카는 높은 확장성을 제공하는 클러스터로 실행되도록 설계되었다. 그리고 클러스터의 모든 카프카 인스턴스에 걸쳐 토픽을 파티션으로 분할하여 메시지를 관리한다. RabbitMQ 가 거래소와 큐를 사용해서 메시지를 처리하는 반면, 카프카는 토픽만 사용한다.

카프카의 토픽은 클러스터의 모든 브로커에 걸쳐 복제된다. 클러스터의 각 노드는 하나 이상의 토픽에대한 리더로 동작하며, 토픽 데이터를 관리하고 클러스터의 다른 노드로 데이터를 복제한다.

카프카 아키텍처

각 토픽은여러 개의 파티션으로 분할될 수 있다. 이 경우 클러스터의 각 노드는 한 토픽의 하나 이상의 파티션(토픽 전체가 아니다)의 리더가 된다.

카프카는 특유의 아키텍처를 갖고 있으므로 해당 아키텍쳐에 대해 깊게 파고들어야 한다. 여기서는 스프링을 사용하여 카프카로부터 메시지를 전송 및 수신하는 방법에 대해 초점을 둔다.

카프카 사용을 위한 스프링 설정

카프카를 사용해서 메시지를 처리하려면 이에 적합한 의존성을 빌드에 추가해야 한다. 그러나 JMS 나 RabbitMQ 와 달리 카프카는 스프링 부트 스타터가 없지만 의존성을 추가하면 된다.

<dependency>
    <groupId>org.springframework.kafka</groupId>
    <artifactId>spring-kafka</artifactId>
</dependency>

이처럼 의존성을 추가하면 스프링 부트가 카프카 사용을 위한 자동 구성을 해준다. 이제부터 kafkaTemplate 을 주입하고 메시지를 전송, 수신하면 된다.

그러나 메시지를 전송 및 수신하기에 앞서 카프카를 사용할 때 편리한 몇 가지 속성을 알면 좋다. 특히 kafkaTemplate 은 기본적으로 localhost 에서 실행되면서 9092 포트를 리스닝하는 카프카 브로커를 사용한다. 애플리케이션을 개발할 때는 로컬의 카프카 브로커를 사용하면 좋다. 그러나 프로덕션 환경에서 사용할 때는 다른 호스트와 포트로 구성해야 한다.

spring.kafka.bootstrap-servers 속성에는 카프카 클러스터로의 초기 연결에 사용되는 하나 이상의 카프카 서버들의 위치를 설정한다. 예를 들어, 클러스터의 카프카 서버 중 하나가 kafka.test.com 에서 실행되고 9092 포트를 리스닝한다면, 이 서버의 위치를 다음과 같이 YAML 파일에 구성할 수 있다.

spring:
    kafka:
        bootstrap-servers:
        - kafka.test.com:9092

spring.kafka.bootstrap-servers 는 복수형이며, 서버 리스트를 받으므로 클러스터의 여러 서버를 지정할 수 있다.

spring:
    kafka:
        bootstrap-servers:
        - kafka.test.com:9092
        - kafka.test.com:9093
        - kafka.test.com:9094

이제는 프로젝트에 카프카 설정이 되었으므로 메시지를 전송, 수신할 준비가 되었다.

KafkaTemplate 을 사용해서 메시지 전송하기

KafkaTemplate 을 사용해서 Order 객체를 카프카로 전송해보자.

아래 메시지 전송 메소드를 확인해보자.

ListenableFuture<SendResult<K, V>> send(String topic, V data);
ListenableFuture<SendResult<K, V>> send(String topic, K key, V data);
ListenableFuture<SendResult<K, V>> send(String topic, Integer partition, K key, V data);
ListenableFuture<SendResult<K, V>> send(String topic, Integer partition, Long timestamp, K key, V data);
ListenableFuture<SendResult<K, V>> send(ProducerRecord<K, V> record);
ListenableFuture<SendResult<K, V>> send(Message<?> message);
ListenableFuture<SendResult<K, V>> sendDefault(V data);
ListenableFuture<SendResult<K, V>> sendDefault(K key, V data);
ListenableFuture<SendResult<K, V>> sendDefault(Integer partition, K key, V data);
ListenableFuture<SendResult<K, V>> sendDefault(Integer partition, Long timestamp, K key, V data);

KafkaTemplate 은 제너릭 타입을 사용하고, 메시지를 전송할 때 직접 도메인 타입을 처리할 수 있다. 따라서 모든 send() 메소드가 컨버팅 기능을 갖고 있다고 생각하면 된다. 카프카에서 메시지를 전송할 때는 메시지가 전송되는 방법을 알려주는 다음 매개 변수를 지정할 수 있다.

메시지가 전송될 토픽(send() 에 필요)
토픽 데이터를 쓰는 파티션(optional)
레코드 전송 키(optional)
타임 스탬프(optional, 기본값은 System.currentTimeMillis())
페이로드(메시지에 적재된 순수한 데이터, 여기서는 Order 객체, required)

토픽과 페이로드는 가장 중요한 매개변수들이다. 파티션과 키는 send() 와 sendDefault() 에 매개변수로 제공되는 추가 정보일 뿐 KafkaTemplate 을 사용하는 방법에는 거의 영향을 주지 않는다. 여기서는 지정된 토픽에 메시지 페이로드를 전송하는 데 초점을 둘 것이다.

send() 메서드에는 ProducerRecord 를 전송하는 것이 있다. ProducerRecord 는 모든 선행 매개변수들을 하나의 객체에 담은 타입이다. 또한, Message 객체를 전송하는 send() 메소드도 있지만 이 경우 도메인 객체를 Message 객체로 변환해야 한다. 보통 ProducerRecord 나 Message 객체를 생성 및 전송하는 것보다는 다른 send() 메소드 중 하나를 사용하는 것이 더 간편하고 쉽다.

KafkaTemplate 과 send() 메소드를 사용하여 주문 데이터를 전송하기 위한 코드는 아래와 같다.

@Service
@RequiredArgsConstructor
public class KafkaOrderMessagingService implements OrderMessagingService {

    private final KafkaTemplate<String, Order> kafkaTemplate;

    @Override
    public void sendOrder(Order order) {
        kafkaTemplate.send("my.orders.topic", order);
    }
}

sendOrder() 메소드는 주입된 KafkaTemplate 의 send() 메소드를 사용하여 my.orders.topic 이라는 이름의 토픽으로 Order 객체를 전송한다. 만일 기본 토픽을 설정한다면 sendOrder() 메소드를 더 간단하게 만들 수 있다. 기본 토픽을 설정하는 방법은 아래처럼 YAML 파일에 정의하는 방법이다.

spring:
    kafka:
        template:
            default-topic: my.orders.topic

그 다음 sendOrder() 메소드에서 send() 대신 sendDefault() 메소드를 호출하면 된다. 이 때는 토픽 이름을 인자로 전달하지 않는다.

@Override
public void sendOrder(Order order) {
    kafkaTemplate.sendDefault(order);
}

카프카 리스너 작성

send() 와 sendDefault() 메소드 외에도 KafkaTemplate 은 메시지를 수신하는 메소드를 제공하지 않는다. 따라서 스프링을 사용해서 카프카 토픽의 메시지를 가져오는 유일한 방법은 메시지 리스너를 작성하는 것이다.

카프카의 경우 메시지 리스너는 @KafkaListener 어노테이션이 지정된 메소드에 정의된다. @KafkaListener 는 @JmsListener 나 @RabbitListener 와 거의 유사하며, 동일한 방법으로 사용된다. 아래 코드를 확인하자.

@Component
@RequiredArgsConstructor
public class OrderListener {

    private final KitchenUI ui;

    @KafkaListener(topics="my.orders.topic")
    public void handle(Order order) {
        ui.displayOrder(order);
    }
}

my.orders.topic 이라는 이름의 토픽에 메시지가 도착할 때 자동 호출되어야 한다는 것을 나타내기 위해 handle() 메소드에는 @KafkaListenr 어노테이션이 지정되었다. 그리고 페이로드인 Order 객체만 handle() 의 인자로 받는다. 그러나 메시지의 추가적인 메타데이터가 필요하다면 ConsumerRecord 나 Message 객체도 인자로 받을 수 있다.

다음의 handle() 메서드에는 수신된 메시지의 파티션과 타임스탬프를 로깅하기 위해 ConsumerRecord 를 인자로 받는다.

@KafkaListener(topics="my.orders.topic")
public void handle(Order order, ConsumerRecord<Order> record) {
    log.info("Received from partition {} with timestamp {}", record.partition(), record.timestamp());
    ui.displayOrder(order);
}

이와 유사하게 ConsumerRecord 대신 Message 객체를 요청하여 같은 일을 처리할 수 있다.

@KafkaListener(topics="my.orders.topic")
public void handle(Order order, Message<Order> message) {
    MessageHeaders headers = message.getHeaders();
    log.info("Received from partition {} with timestamp {}", headers.get(KafkaHeaders.RECEIVED_PARTITION_ID), headers.get(KafkaHeaders.RECEIVED_TIMESTAMP));
    ui.displayOrder(order);
}

메시지 페이로드는 ConsumerRecord.value() 나 Message.getPayload() 를 사용해도 받을 수 있다. handle() 의 매개변수로 직접 Order 객체를 요청하는 대신 ConsumerRecord 나 Message 객체를 통해 Order 객체를 요청할 수 있다.

[Spring Boot] Spring Cloud Eureka Server

ssunw — Wed, 24 Aug 2022 18:44:26 +0900

유레카란?

마이크로서비스가 서로를 찾을 때 사용되는 서비스 레지스트리의 이름이다. 유레카는 마이크로서비스 애플리케이션에 있는 모든 서비스의 중앙 집중 레지스트리로 작동한다. 유레카 자체도 마이크로서비스로 생각할 수 있고 더 큰 애플리케이션에서 서로 다른 서비스들이 서로를 찾는 데 도움을 주는 것이 목적이다.

유레카의 역할 때문에 서비스를 등록하는 유레카 서비스 레지스트리를 가장 먼저 설정하는 것이 좋다.

서비스 인스턴스가 시작될 때 해당 서비스는 자신의 이름을 유레카에 등록한다. 동일한 이름을 갖는 서비스 인스턴스가 여러개 생성될 수 있다.

어느 순간 다른 서비스가 some-service 를 사용해야 할 때 이 때 some-service 의 특정 호스트 이름과 포트 정보를 other-service 코드에 하드 코딩하지 않는다. 대신 other-service 는 some-service 라는 이름을 유레카에서 찾으면 된다. 그러면 유레카는 모든 some-service 인스턴스의 정보를 알려준다.

다음으로 oter-service 는 some-service 의 어떤 인스턴스를 사용할지 결정해야 한다. 이때 특정 인스턴스를 매번 선택하는 것을 피하기 위해 클라이언트 측에서 동작하는 로드 밸런싱 알고리즘을 사용한다. 이 때 사용될 수 있는 것이 넷플릭스 프로젝트인 리본(Ribbon)이다.

some-service 의 인스턴스를 찾고 선택하는 것은 other-service 가 해야할 일이지만, 이것을 리본에게 맡길 수 있다. 리본은 other-service 를 대신하여 some-service 인스턴스를 선택하는 클라이언트 측의 로드 밸런서이다. 그리고 other-service 는 리본이 선택하는 인스턴스에 대해 필요한 요청을 하면 된다.

유레카 서버 스타터 의존성을 아래와 같이 설정한다.


<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
    </dependency>
</dependencies>
...

유레카 스타터 의존성이 지정되었으므로 이제 유레카 서버를 활성화시킨다. 애플리케이션이 시작되는 부트스트랩 클래스에서 @EnableEurekaServer 어노테이션을 추가한다.

@SpringBootApplication
@EnableEurekaServer
public class ServiceRegistryApplication {

    public static void main(String[] args) {
        SpringApplication.run(ServiceRegistryApplication.class, args);
    }

}

이제 애플리케이션을 실행하고 localhost:8080 포트로 접속을 하면 유레카 웹 대시보드가 나올 것이다.

유레카 대시보드에서 여러 정보를 제공하는데 특히 어떤 서비스 인스턴스가 유레카에 등록되었는지를 알려준다.

따라서 서비스를 등록할 때 기대한 대로 잘됐는지 확인하기 위해 유레카 대시보드를 확인하면 된다. 현재는 아무 서비스도 등록되지 않았기 때문에 "No instances available' 메시지가 나올 것이다.

유레카 구성하기

하나보다는 여러 개의 유레카 서버가 함께 동작하는 것이 안전하므로 SPOF 를 방지하기 위해서 유레카 서버들이 클러스터로 구성되는 것이 좋다. 기본적으로 유레카는 다른 유레카 서버로부터 서비스 레지스트리를 가져오거나 다른 유레카 서버의 서비스로 자기 자신을 등록할 수 있다.

프로덕션 설정에서는 유레카의 고가용성이 바람직하다. 그러나 개발 시에 두 개 이상의 유레카 서버를 실행하는 것은 불편하기도하고 불필요하다. 개발 목적으로는 하나의 유레카 서버면 충분하기 때문이다. 유레카 서버를 올바르게 구성하지 않으면 30초마다 예외의 형태로 로그 메시지를 출력한다. 유레카는 30초 마다 다른 유레카 서버와 통신하면서 자신이 작동 중임을 알리고 레지스트리 정보를 공유하기 때문이다.

개발 환경에서 유레카 환경 설정을 구성하는 코드는 아래와 같다. application.yaml 에 아래처럼 구성하자.

server:
  port: 8761
eureka:
  instance:
    hostname: localhost
  client:
    fetchRegistry: false
    registerWithEureka: false
    serviceUrl:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

server.port 속성을 8761 로, eureka.instance.hostname 속성을 localhost 로 설정했다. 유레카가 실행되는 호스트 이름과 포트를 나타낸다. 이 속성은 생략가능하고 만약 지정하지 않았다면 유레카가 환경 변수를 참고하여 생성한다.
속성 값을 확실하게 알려주기 위해서 지정하는 것을 권장한다.

eureka.client.fetchRegistry 와 eureka.client.regiterWithEureka 는 유레카와 상호 작용하는 방법을 알려주기 위해 다른 마이크로 서비스에 설정할 수 있는 속성들이다. 유레카도 마이크로 서비스이기 때문에 이 두 속성은 유레카 서버가 다른 유레카 서버와 상호 작용하는 방법을 알려주기 위해 사용할 수 있다.

이 두 속성의 기본값은 true 이다. 즉, 해당 유레카 서버가 다른 유레카 서버로부터 레지스트리 정보를 가져오며, 다른 유레카 서버의 서비스로 자신을 등록해야 한다는 것을 나타낸다. 여기서는 개발 환경 구성이기 때문에 다른 유레카 서버들이 필요 없으므로 두 속성의 값을 false 로 설정했다.

마지막으로 eureka.client.serviceUrl 속성을 설정했다. 이 속성은 영역(zone) 이름과 이 영역에 해당하는 하나 이상의 유레카 서버 URL 을 포함하고 이 값은 Map 에 저장된다. Map 의 키인 defualtZone 은 클라이언트(여기서는 유레카 자기 자신)가 자신이 원하는 영역을 지정하지 않았을 때 사용된다.

여기서는 유레카가 하나만 있으므로 defaultZone 에 해당하는 URL 이 유레카 자신의 URL 을 나타내며, 중괄호 안에 지정된 다른 속성(eureka.instance.hostname 과 server.port)의 값으로 대체된다. 따라서 defualtZone 은 http://localhost:8761/eureka/ 가 된다.

자체-보존 모드

eureka.server.enableSelfPreservation 속성이 있다. 유레카 서버는 서비스 인스턴스(유레카 서버의 클라이언트)가 자신을 등록하고 등록 생신 요청을 30초마다 전송하기를 기대한다.

즉, 해당 서비스가 정상적으로 동작하고 있는지 확인하는 것이다. 일반적으로 세 번 갱신하는 동안 서비스 인스턴스로부터 등록 갱신 요청을 유레카 서버가 받지 못하면 해당 서비스 인스턴스의 등록을 췻고하게 된다. 레지스트리에서 서비스 인스턴스가 삭제되는 것이다.

이렇게 중단되는 서비스의 개수가 임계값을 초과하면 유레카 서버는 네트워크 문제가 생긴 것으로 간주하고 레지스트리에 등록된 나머지 서비스 데이터를 보존하기 위해 자체-보존 모드가 된다. 따라서 추가적인 서비스 인스턴스의 등록 취소가 방지된다.

프로덕션 환경에서는 자체-보존 모드를 true 로 설정하는 것이 좋다. 실제로 네트워크 문제가 생겨서 유레카로의 갱신 요청이 중단되었을 때 나머지 활성화 된 서비스들의 등록 취소를 방지할 수 있기 때문이다.

하지만, 유레카를 처음 시작한 상태에 어떤 서비스도 등록되지 않았을 때는 오히려 문제가 발생할 수 있다. 이때는 eureka.server.enableSelfPreservation 속성을 false 로 설정하여 자체-보존 모드를 비활성화시킬 수 있다.

eureka:
    ...
    serviceUrl:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
  server:
    enableSelfPreservation: false

네트워크 문제 외에도 여러 가지 이유로 유레카가 갱신 요청을 받을 수 없는 개발 환경에서는 이 속성을 false 로 설정하는 것이 유용하다. 서비스 인스턴스들의 상태가 자주 변경될 수 있는 개발 환경에서 자체-보존 모드를 활성화하면 중단된 서비스의 등록이 계속 유지되어 다른 서비스가 해당 서비스를 사용하려고 할 때 문제를 발생시킬 수 있기 때문이다.

개발 환경에서는 자체-보존 모드를 비활성화 시켜도 좋지만 프로덕션 환경에서는 활성화해야 한다.

프로덕션 환경의 스프링 클라우드 서비스

마이크로 서비스를 프로덕션 환경으로 배포할 때는 고려해야 할 부분이 많다. 유레카의 고가용성과 보안은 개발 시에는 중요하지 않은 관점이지만, 프로덕션에서는 매우 중요하다.

두 개 이상의 유레카 인스턴스를 구성하는 가장 쉽고 간단한 방법은 application.yaml 파일에 스프링 프로파일을 지정하는 것이다. 그리고 한 번에 하나씩 프로파일을 사용해서 유레카를 두 번 시작시키면 된다.

아래 코드는 스프링 프로파일을 사용해서 두 개의 유레카 서버를 구성했다.


eureka:
  client:
    service-url:
      defaultZone: http://${other.eureka.host}:${other.eureka.port}/eureka

---
spring:
  profiles: eureka-1
  application:
    name: eureka-1

server:
  port: 8761

eureka:
  instance:
    hostname: eureka1.tacocloud.com

other:
  eureka:
    host: localhost
    port: 8762

---
spring:
  profiles: eureka-2
  application:
    name: eureka-2

server:
  port: 8762

eureka:
  instance:
    hostname: eureka1.tacocloud.com

other:
  eureka:
    host: localhost
    port: 8762

공통 설정을 갖는 기본 프로파일에는 eureka.client.serviceUrl.defualtZone 을 설정하였다. 여기에 지정된 other.eureka.host 와 other.eureka.port 변수의 값은 그 다음에 있는 각 프로파일 구성에서 설정된 값으로 대체된다.

기본 프로파일 다음에는 두 개의 프로파일인 eureka-1 과 eureka-2 가 구성되어 있으며, 각 프로파일에는 자신의 포트와 eureka.instance.hostname 이 설정되어 있다. 그리고 각 프로파일에 설정된 다른 유레카 인스턴스를 참조하기 위해 other.eureka.host 와 other.eureke.port 속성도 설정되어 있다. 이 속성들은 프레임워크와는 관계없으며, 기본 프라일에 지정된 other.eureka.host 와 other.eureka.port 변수의 값을 대체하기 위해 필요하다.

eureka.client.fetchRegistry 와 eureka.client.regiterWithEureka 를 따로 설정하지 않아도 기본값이 true 이기 때문에 자동으로 구성 환경에 설정값으로 세팅된다. 따라서 각 유레카 서버가 다른 유레카 서버에 자신을 등록하고 레지스트리의 등록 정보를 가져온다.

[SpringBoot] Transactional

ssunw — Sun, 21 Aug 2022 10:55:48 +0900

JDBC 트랜잭션

Spring 에서 JDBC 를 사용하여 트랜잭션을 사용할 수 있다.

// 데이터베이스를 사용하기 위해 연결을 진행
Connection connection = dataSource.getConnection(); 
try (connection) {
    // Java 에서 데이터베이스 트랜잭션을 시작하는 유일한 방법이다. 
    // setAutoCommit(false) 는 트랜잭션을 직접 관리할 수 있게 해준다. 개발자가 원할 대 커밋 또는 롤백이 가능
    connection.setAutoCommit(false); 
    // 쿼리문 작성
    
    connection.commit(); // 커밋을 진행
} catch (SQLException e) {
    connection.rollback(); // 예외가 발생한 경우 롤백
}

위 코드처럼 간단한 케이스라면 상관이 없겠지만 트랜잭션을 여러개 발생해야 하는 경우에 복잡도가 올라간다. 두 개 이상의 DB에 접근해야 하는 작업을 하나의 트랜잭션으로 만들 수가 없다.

@Transactional

public class UserService {
    @Transactional
    public Long registerUser(User user) {
        // 쿼리문 실행
        // 유저 데이터 DB 에 저장
        // userDao.save(user);
        return id;
    }
}

일반적으로 많이 사용되는 선언적 트랜잭션 방식으로 @Transactional 어노테이션을 붙여서 사용한다. 스프링 부트에서는 자동으로 @Transactional 어노테이션 사용 설정인 @EnableTransactionManagement 어노테이션 설정이 되어 있다.

@Transactional 이 있으면 JDBC 에서 필요한 코드를 삽입해준다.(getConnection(), setAutoCommit(false), 메소드 종료 시 커밋, 예외 발생 시 롤백)

트랜잭션 경계 설정 전략

트랜잭션의 시작과 종료는 Service 레이어 내부 메소드에 달려 있다. 트랜잭션의 경계를 설정하는 방법으로는 PlatformTransactionManager 를 사용하여 트랜잭션 코드를 통해 임의로 지정하는 방법과 AOP 를 이용하여 지정하는 방법으로 나뉘며 AOP 를 활용한 @Transactional 어노테이션이 주로 사용된다.

// 기본 전파 속성은 REQUIRED
@Transactional
public void invoke() {
    System.out.println("*** invoke start");
    insert1();
    insert2();
    System.out.println("*** invoke end");
}

// 기본 전파 속성은 REQUIRED
public void insert1() {
    bookRepository.save(new Book("책1"));
}

// 기본 전파 속성은 REQUIRED
public void insert2() {
    bookRepository.save(new Book("책2"));
}

DEBUG JpaTransactionManager : Creating new transaction with name [dev.highright96.springstudy.transaction.BookServiceImpl.invoke]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
DEBUG JpaTransactionManager : Opened new EntityManager [SessionImpl(2076486718<open>)] for JPA transaction
DEBUG JpaTransactionManager : Exposing JPA transaction as JDBC [org.springframework.orm.jpa.vendor.HibernateJpaDialect$HibernateConnectionHandle@351fadfa]
*** invoke start
DEBUG JpaTransactionManager : Found thread-bound EntityManager [SessionImpl(2076486718<open>)] for JPA transaction
DEBUG JpaTransactionManager : Participating in existing transaction
Hibernate: insert into book (isbn, flag, name) values (null, ?, ?)
DEBUG JpaTransactionManager : Found thread-bound EntityManager [SessionImpl(2076486718<open>)] for JPA transaction
DEBUG JpaTransactionManager : Participating in existing transaction
Hibernate: insert into book (isbn, flag, name) values (null, ?, ?)
*** invoke end
DEBUG JpaTransactionManager : Initiating transaction commit
DEBUG JpaTransactionManager : Committing JPA transaction on EntityManager [SessionImpl(2076486718<open>)]
DEBUG JpaTransactionManager : Closing JPA EntityManager [SessionImpl(2076486718<open>)] after transaction

로그를 살펴보면 JpaTransactionManager 가 트랜잭션 관리를 하는 것을 알 수 있다.

invoke start
- invoke() 메소드가 시작되기 전에 DB 커넥션을 얻는다.
Participating in existing transaction
- invoke() 메소드 내에서 insert1() 과 insert2() 에서 실행되는 트랜잭션은 기존 트랜잭션에 참가하며, 기본 트랜잭션 전파 설정은 REQUIRED 이다.
invoke end
- invoke() 메소드가 실행된 이후, 트랜잭션을 커밋하고 커넥션을 반환환다.

트랜잭션이 시작되는 지점은 invoke() 메소드에 대한 프록시 메소드 내부이고, 다음 순서대로 호출 경계가 설정된다.

프록시 객체 호출
Proxy.invoke() 시작
트랜잭션 시작
트랜잭션 전파 설정에 따른 내부 메소드 트랜잭션 처리
트랜잭션 커밋
Proxy.invoke() 종료

즉, 메소드가 끝날 때까지 커밋 또는 커넥션 반환이 이루어지지 않고 트랜잭션 내부 메소드 내에서 발생하는 SQL 은 동일한 커넥션을 사용한다. 따라서 처리 시간이 긴 메소드의 경우에는 트랜잭션 단위를 조정해서 DB Lock 지속 시간이 지나치게 길어지거나 DB 커넥션 풀의 커넥션 개수가 모자라지 않도록 해야 한다.

트랜잭션 전파

트랜잭션 전파는 임의의 한 트랜잭션이 경계에서 이미 진행 중인 트랜잭션이 존재할 때, 혹은 존재하지 않을 때 동작 방식을 결정하는 설정이다.

A 라는 트랜잭션이 시작되고 트랜잭션 A 가 끝나지 않을 시점에서 트랜잭션 B 메소드가 호출될 때 B 는 어느 트랜잭션에서 동작할까.

A, B 트랜잭션

트랜잭션 전파 설정에 따라 여러 시나리오가 존재하지만 아주 간단하게 두 가지만 확인하도록 한다.

A 라는 트랜잭션이 시작되었고 아진 진행 중인 상태라면 B 는 새로운 트랜잭션을 만들지 않고 A 에서 시작된 트랜잭션에 참여하게 된다. 이 경우 B 를 호출한 B.method() 까지 마치고 이후 작업에서 예외가 발생한다면 A 와 B 가 모두 A 트랜잭션에 하나로 묶여 있기 때문에 전체가 롤백된다.
트랜잭션 B 와 트랜잭션 A 를 별도의 트랜잭션으로 구분하여 실행시킬 수 있다. 이 경우에 트랜잭션 B 경계를 빠져 나가는 순간, B 트랜잭션은 독립적으로 커밋되거나 롤백된다. 트랜잭션 A 는 B 트랜잭션에 영향을 받지 않고 진행된다. 즉, A 의 (2) 에서 예외가 발생하더라도 트랜잭션 A 만 롤백되고, 트랜잭션 B 는 아무런 영향을 받지 않는다.

여기서 A 트랜잭션과 B 트랜잭션은 서로 다른 Service 레이어에 속해야 한다. 만약 한 Service 레이어에서 A 트랜잭션을 실행하고, A 트랜잭션 코드에서 다시 내부 B 트랜잭션을 실행한다면 B 트랜잭션은 트랜잭션이 적용되지 않은 일반 코드가 실행된다.

REQUIRED(기본값)

가장 많이 사용되는 트랜잭션 전파 속성으로 이미 진행 중인 트랜잭션이 없으면 새로 시작하고 진행 중인 트랜잭션이 있다면 기존 트랜잭션에 참여한다.

즉 위 예시에서 1번 예시에 해당한다.

REQUIRED

A 는 새로운 트랜잭션을 생성하고 B 는 트랜잭션을 생성하지 않고 진행 중인 트랜잭션 즉, A 트랜잭션에 합류한다.

즉 현재 서비스 레이어에서 실행되는 메소드는 A 라는 하나의 트랜잭션만 존재한다.

REQUIRES_NEW

항상 새로운 트랜잭션을 시작하는 방식으로 이미 진행중인 트랜잭션이 있든 없든 간에 항상 새로운 트랜잭션을 만들어 독립적으로 동작시킨다. 즉, 독립적인 트랜잭션이 보장되어야 하는 코드에 적용할 수 있다.

REQUIRES_NEW

A 트랜잭션이 생성되고, B 트랜잭션이 생성된다. 각각의 트랜잭션은 커밋, 롤백을 따로따로 진행한다.

B 기능이 끝날 때 B 트랜잭션이 커밋되고, A 기능이 끝날 때 A 트랜잭션이 커밋된다.

MANDATORY

이미 진행중인 트랜잭션이 있으면 해당 트랜잭션에 합류하는 방식으로 REQUIRED 와 동일한 방식처럼 보이지만 진행 중인 트랜잭션이 없다면 예외를 발생시킨다는 점이 REQUIRED 와 다르다.

독립적인 트랜잭션을 생성하면 안되는 경우에 사용한다.

NESTED

이미 실행 중인 트랜잭션이 존재할 경우 중첩 트랜잭션을 생성한다. 중첩 트랜잭션이란 트랜잭션 내부에 다시 트랜잭션을 만드는 것으로 부모 트랜잭션에서 새로운 트랜잭션을 내부에 만드는 것이다.

중첩 트랜잭션은 부모 트랜잭션의 커밋과 롤백에는 영향을 받지만 중첩 트랜잭션은 부모 트랜잭션에 영향을 주지 않는다. REQUIRED 와 마찬가지로 부모 트랜잭션, 이미 진행중인 트랜잭션이 존재하지 않을 경우에는 독립적으로 트랜잭션을 생성해서 사용한다.

NESTED

A 라는 부모 트랜잭션이 존재하기 때문에 중첩 트랜잭션 B 를 생성한다. B 트랜잭션이 모두 끝나도 모든 커밋은 부모 트랜잭션인 A 트랜잭션의 끝에서 이뤄진다.

만약 A 트랜잭션에서 예외가 발생해 롤백이 될 경우 B 트랜잭션도 같이 롤백이 된다. 하지만 중첩 트랜잭션인 B 트랜잭션에서 예외가 발생해 롤백이 발생할 경우 해당 롤백을 부모 트랜잭션인 A 트랜잭션에게 전파하지 않는다.

NEVER

트랜잭션을 사용하지 않도록 강제하는 방식으로 트랜잭션을 사용하지 않는 방식이다. NOT_SUPPORTED 와 다른 점은 NOT_SUPPORTED 는 트랜잭션을 무시하고 보류하는 반면에 NEVER 는 트랜잭션이 존재하면 예외를 발생 시킨다.

NEVER

NOT_SUPPORTED

해당 속성을 사용하면 트랜잭션 자체를 무시한다. 즉, 트랜잭션 없이 동작한다는 뜻이다. 트랜잭션의 경계 설정 대부분은 AOP 를 이용하여 여러 메소드를 일괄적으로 적용한다. 따라서 특별한 임의의 메소드 하나에만 트랜잭션을 적용하지 않기 위한 전파 속성이다.

@Transactionl 주의점

@Transactional 어노테이션을 붙이면, 트랜잭션 처리를 위해 빈 객체에 대한 프록시 객체를 생성한다. 이때 프록시 타겟 클래스를 상속하여 생성된다. 따라서 상속이 불가능한 private 메소드의 경우 @Transactional 어노테이션을 붙여도 트랜잭션이 동작하지 않는다.

DBMS 의 종류에 따라 DB Lock 지속 시간이나 Read Consistency 의 차이, 그리고 이로 인한 서비스 동시성 문제 등을 생각하면 메소드 단위로 경계가 설정되는 AOP 방식의 트랜잭션이 비효율적일 수 있다. 예를 들어, 실행 시간이 긴 메소드에 AOP 로 트랜잭션을 붙였을 경우 불필요하게 DB 커넥션을 점유하거나 DB Lock 이 유지되는 시간이 길어질 수 있다.

public class TransactionInvoker {
    private final A1Dao a1dao;
    private final A2Dao a2dao;
    
    @Transactionl
    public void invoke() {
        // 긴 Business Login
        doInternalTransaction();
    }
    
    public void doInternalTransaction() {
        a1dao.insertA1();
        a2dao.insertA2();
    }
}

에를 들어, 위와 같은 상황에서는 비즈니스 로직이 트랜잭션에 포함되는 비효율이 발생할 수 있다. 이러한 경우에 개발자가 직접 트랜잭션의 경계를 설정할 필요가 있고, 이 때 TransactionTemplate 이 사용된다.

public class TransactionInvoker {
    private final A1Dao a1dao;
    private final A2Dao a2dao;
    private final TransactionTemplate transactionTemplate;
    
    public void setTransactionManager(PlatformTransactionManager transactionManager) {
        this.transactionTemplate = new TransactionTemplate(transactionManager);
        this.transactionTemplate.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
    }
    
    public void invoke() throws Exception {
        // 비즈니스 로직
        doInternalTransaction();
    }
    
    private void doInternalTransaction() throws Exception {
        transactionTemplate.execute(new TransactionCallbackWithoutResult() {
            public void doInTransactionWithoutResult(TransactionStatus status) {
                try {
                    a1dao.insertA1();
                    a2dao.insertA2();
                } catch (Exception e) {
                    status.setRollbackOnly();
                }
                return;
            }
        }
    }
}

Spring 에서 setter 를 통해 TransactionTemplate 을 주입받는다. 그 후 TransactionTemplate 을 생성 및 Transaction 속성을 설정한다.

[kubernetes] kubernetes 아키텍쳐

ssunw — Mon, 1 Aug 2022 17:57:33 +0900

kubrenetes 공식 문서에서 설명하고 있는 아키텍쳐

클러스터는 물리적 혹은 논리적으로 여러개의 리소스를 하나로 묶어서 사용하는 것을 뜻한다.

기본적으로 Docker 는 클러스터라는 기능은 없다. 도커 컨테이너들은 각각 따로 관리된다. 이를 하나로 한꺼번에 관리할 수는 없다.

이런 형태를 stand alone 이라고 부르며, stand alone 형태는 관리하기가 힘들다.

즉, 클러스터는 리소스를 하나로 묶어서 한번에 관리를 하는 것이다.

쿠버네티스 클러스터의 핵심

Control Plane
Node

Node(구 명칭 worker, Minions)

Control Plane 과 Node 라는 VM 형태로 나눠진다. 즉 역할이 분리되는 것이다.

Node 는 실제 컨테이너를 실행해준다. 즉, Node 안에 도커(podman, CRIO...)가 설치되있어야 한다.

일반적으로 Control Plane 보다 Node 의 갯수가 더 많다.

Control Plane(구 명칭 Master)

Node 를 관리해주는 녀석이다. 그래서 Control Plane 에 장애가 발생하면 Node 를 관리할 수 없다. 그래서 SPoF 를 방지하기 위해 여러 대의 Control Plane 을 띄워둔다. 일반적으로는 3대이상을 Control Plane 으로 띄운다.

Control Plane 을 클러스터링 할 때 절대 짝수개로 두면 안된다.

Control Plane 컴포넌트

kube-apiserver

kube-apiserver 는 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트이다.

모든 통신은 kube-apiserver 을 통해 통신이 된다.

쿠버네티스 API 서버의 주요 구현은 kube-apiserver 이다. kube-apiserver는 수평으로 확장되도록 디자인되었다. 즉, 더 많은 인스턴스를 배포해서 확장할 수 있다. 여러 kube-apiserver 인스턴스를 실행하고, 인스턴스간의 트래픽을 균형있게 조절할 수 있다.

kube-controller-manager

쿠버네티스 핵심으로 쿠버네티스 전체를 관리한다.

쿠버네티스는 컨테이너를 관리하지 않는다.

쿠버네티스는 Pod 를 관리하고, Pod 는 컨테이너가 아니다.

컨트롤러는 다음을 포함한다.

노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
레플리케이션 컨트롤러: 시스템의 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞은 수의 파드들을 유지시켜 주는 책임을 가진다. (쿠버네티스의 핵심은 컨테이너의 복제이다.)
엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채운다(즉, 서비스==Network(LB) 와 파드를 연결시킨다.)
서비스 어카운트 & 토큰(인증) 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.

cloud-controller-manager

쿠버네티스가 클라우드에 있을 경우(EKS, AKS, GKE), 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 해 준다.

kube-scheduler

노드가 배정되지 않은 새로 생성된 Pod 를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트이다.

즉, Pod 를 어느 노드에 어떻게 배치할 것인지 설정해준다.

etcd(etc daemon)

모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 key value 스토리지이다.(DB)

쿠버네티스 클러스터에서 etcd를 뒷단의 저장소로 사용한다면, 이 데이터를 백업하는 계획은 필수이다.

Node 컴포넌트

kubelet

클러스터의 각 노드에서 실행되는 에이전트이다. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.

kube-apiserver 에 컨테이너를 만들어달라고 요청을 보내면 kubelet 이 파드를 만들고 파드에서 컨테이너가 동작하도록 한다.

kube-proxy

docker proxy 는 네트워크의 정책(iptables 정책)을 관리한다. 예를 들어 포트 포워딩 할 때 이 녀석을 사용한다.

kube-proxy 도 똑같이 네트워크 정책을 담당한다.

쉽게 얘기하자면 kubelet 은 컨테이너를 담당하는 녀석이고, kube-proxy 는 네트워크를 담당하는 녀석이다.

Control Plane 의 컴포넌트들도 모두 컨테이너이기 때문에 해당 컨테이너를 관리하는 kubelet 과 kube-proxy 가 Control Plane 에도 존재한다.

[SpringBoot] 빌더 패턴

ssunw — Mon, 1 Aug 2022 08:57:29 +0900

Entity 클래스를 생성할 때, 주의할 것은 무분별한 setter 메소드 생성이다. 자바빈 규약을 생각하시면서 getter/setter를 무작정 생성하는데, 이렇게 되면 해당 클래스의 인스턴스 값들이 언제 어디서 변해야하는지 코드상으로 명확히 구분할수가 없어, 차후 기능변경시 정말 복잡해진다.해당 필드의 값 변경이 필요하면 명확히 그 목적과 의도를 나타낼 수 있는 메소드를 추가해야만 합니다.

예를들어 주문 취소 메소드를 만든다고 가정하면 아래 코드로 비교해보시면 될 것 같다.

잘못된 사용
public class Order{
    public void setStatus(boolean status){
        this.status = status
    }
}

public void 주문서비스의_취소메소드 (){
   order.setStatus(false);
}

올바른 사용
public class Order{
    public void cancelOrder(){
        this.status = false;
    }
}
public void 주문서비스의_취소메소드 (){
   order.cancelOrder();
}

자 그러면 여기서 한가지 궁금한 점이 생길 수 있다. 기본 생성자도 AccessLevel.PROTECTED로 막아놓고, setter 메소드도 없는 이 상황에서 어떻게 값을 채워 DB에 insert 해야할까?

기본적인 구조는 생성자를 통해 최종 값을 채운후 DB에 Insert 하는것이며, 값 변경이 필요한 경우 해당 이벤트에 맞는 public 메소드를 호출하여 변경하는 것을 전제로 한다.여기서 생성자 대신에 @Builder를 통해 제공되는 빌더 클래스를 사용합니다. 생성자나 빌더나 생성 시점에 값을 채워주는 역할은 똑같다. 다만, 생성자의 경우 지금 채워야할 필드가 무엇인지 명확히 지정할수가 없다. 예를 들어 아래와 같은 생성자가 있다면

public Example(String a, String b){
    this.a = a;
    this.b = b;
}

개발자가 new Example(b,a)처럼 a와 b의 위치를 변경 해도 실제로 코드를 실행하기전까진 전혀 문제를 찾을수가 없다.하지만 빌더를 사용하게 되면 아래와 같이

Example.builder()
    .a(a)
    .b(b)
    .build();

어느 필드에 어떤 값을 채워야 할지 명확하게 인지할 수 있다.

[SpringBoot] N+1 문제

ssunw — Mon, 1 Aug 2022 08:55:20 +0900

LAZY 로딩과 EAGER 로딩의 차이를 먼저 알아야 한다.(지연 로딩, 즉시 로딩)

지연로딩

Team —————— Member 는 서로 OneToMany, ManyToOne 관계를 맺고 있다.

public class Team extends CoreEntity {

	// ... 중략

	@OneToMany(mappedBy = "team", cascade = {CascadeType.ALL}, fetch = FetchType.LAZY)
	private List<Member> members = new ArrayList()<>;
}

public class Member extends CoreEntity {

	// ... 중략

	@ManyToOne(fetch = FetchType.LAZY, cascade = {CascadeType.ALL})
	@JoinColumn(name = "member_idx")
	private Team team;
}

위와 같은 형태로 Team 엔티티에 연관관계를 맺고 있다.

여기서 Member 객체를 조회할 때 Team 객체를 불러오는 방식에 차이가 생긴다.

여기서는 FetchType.LAZY → 지연로딩을 사용했기 때문에 Team 객체를 프록시 객체로서 가져오게 된다.

프록시 객체란 무엇이냐? 프록시 객체 내부의 속성을 조회하기 전 까지는 DB 에 쿼리문을 날리지 않는 null 값을 가진 객체라고 생각하면 된다.

즉, Team 객체는 프록시 객체이기 때문에 우리가 직접 조회하기 전 까지는 DB 에 쿼리문을 날리지 않는다.

그래서 Member 객체를 조회할 때 select 쿼리문을 한 번만 날리고 프록시 객체를 조회할 경우에 다시 쿼리를 날린다.

즉시로딩

즉시 로딩은 말 그대로 객체를 조회할 때 연관관계를 맺은 객체까지 전부 조회하는 것을 뜻 한다.

기본적으로 N+1 문제가 발생하며, ManyToOne, OneToOne 의 경우 기본적으로 즉시 로딩이며 OneToMany, ManyToMany 는 지연 로딩으로 설정되어 있다.

N+1 문제의 원인

즉시 로딩으로 모든 연관관계 객체들을 불러올 경우 select 로 연관관계 까지 조회하므로 N+1 발생
지연 로딩으로 조회를 하고나서 연관관계 객체를 다시 조회할 경우 N+1 문제 발생

public void N1_test() {

	List<Team> teams = teamRepository.findAll();

}

만약 Member 클래스의 Team 객체와의 연관관계 속성이 즉시 로딩이였을 경우 위의 케이스에서 N+1 문제 발생

지연 로딩일 경우에도 프록시 객체를 다시 조회하는 경우에 JPQL 이 실행되어 N+1 문제가 발생한다.

public class Team extends CoreEntity {

	// ... 중략

	@OneToMany(mappedBy = "team", cascade = {CascadeType.ALL}, fetch = FetchType.LAZY)
	private List<Member> members = new ArrayList()<>;
}

@Transactional
public void N1_test() {
	
	List<Team> teams = teamRepository.findAll();

	for(Team team : teams) {
		System.Out.Println(team.getMembers.getSize());
	}
}

위의 경우 team 레포지토리에서 모든 team 의 값들을 리스트로 뽑아오고, 해당하는 각각의 팀들의 멤버를 조회하는 로직이다.

여기서 멤버 정보를 조회하면 팀 객체에 대한 조회는 이미 끝난 상태여서 JOIN 으로 쿼리가 생성이 안되다.

단지, 팀 객체에 대한 ID 로 조회할 수 밖에 없다.

그래서 where team.memberId = ? 형식으로 JPQL 쿼리를 생성하고, 이로 인해 매번 조회 쿼리가 발생

N 번 실행되는 이슈가 발생한다.

→

멤버를 조회할 때, 팀 객체에 대한 조회는 이미 끝난 상태이다.

그래서 JOIN 을 사용하지 못하기 때문에 JPQL 쿼리를 만들어서 반복문 횟수만큼 쿼리문을 날린다.

N+1 문제 해결법

지연 로딩에서 문제가 생기는 이유 → DB 통신은 findAll 에서 끝났는데 프록시 객체를 조회해서 다시 JPQL 쿼리를 날리기 때문에 발생한다.

즉, join 이 되지 않아서 생기는 문제라고 볼 수 있다.

그러면 join 을 해주면 해결될 문제가 아닐까? ⇒ Spring 에선 fetch join 을 통해 해결한다.

해당 레포지토리에서 네이티브 쿼리를 만들어서 해결할 수 있다.

@Query("select DISTINCT t from Team t join fetch t.members")
List<Team> findAllJoinFetch();

이렇게 하면 N+1 문제가 해결이 된다.

그러나 fetch join 도 문제가 존재한다.

첫 째로 JPA 가 제공하는 Pageable 기능 사용 X, 둘 째로 1:N 관계가 2개인 엔티티를 fetch join 불가능하다.

fetch join

sql 조인 종류가 아니고, JPQL 에서 성능 최적화를 위해 제공하는 기능으로 연관 관계를 맺고 있는 엔티티를 SQL 한 번에 함께 조회하는 기능이다.

즉시 로딩과 똑같지만 fetch join 은 쿼리로 내가 원하는 객체, 그래프를 명시적, 동적으로 뽑을 수 있다.

일반 조인 시에는 연관된 엔티티를 함께 조회해주지 않는다.

페치 조인을 사용할 때만 연관 관계인 엔티티도 함께 조회한다.

[minikube 오류] The connection to the server localhost:8443 was refused - did you specify the right host or port? output: stderr nThe connection to the server localhost:8443 was refused - did you specify the right host or port?

ssunw — Thu, 28 Jul 2022 21:26:57 +0900

minikube delete --all --purge

minikube start

참조: https://github.com/kubernetes/minikube/issues/12274#issuecomment-1006201978

[CI/CD] EKS 에서 Jenkins, ArgoCD 를 활용한 파이프라인 구성

ssunw — Thu, 28 Jul 2022 14:35:36 +0900

CI/CD 미니 프로젝트

I. 과제 및 배경 소개

본 프로젝트의 목표는 클라우드 인프라 오케스트레이션의 구현이다. AWS EKS 상에 클러스터를 구성하고, CI/CD 도구인 Jenkins와 ArgoCD를 주로 사용하여 개발부터 배포까지 자동적이고 유기적인 방식으로 이루어지도록 구성한다. 인프라 구성은 아키텍처에서 상술한다.

아키텍처

개발자가 깃허브에 코드를 push 한다.
Jenkins를 GitHub에 연결하고, Jenkins는 GitHub repository에 commit 된 내용을 감지한다.
Pipeline을 생성하고 GitHub에 위치한 Jenkinsfile 스크립트를 찾아 자동 실행되게 설정한다.(checkout → maven build)
Dockerfile을 참조해 image를 빌드한다.
Docker image를 Docker Hub에 push 한다.
Jenkins 에서 manifest를 업데이트해 image tag를 수정한다.
ArgoCD 에서 image tag 수정을 감지하고 싱크 한다.
ArgoCD에서 docker image pull을 진행한다.
ArgoCD에서 소스 코드에서 변경된 부분을 반영하여 업데이트하거나 파드를 재생성한다.

환경 구성

환경 구성은 위에서 보이는 아키텍쳐와 같다. 자세한 설명은 아래 순서를 참고하여 실행하며 알아보도록 하자.

프로젝트 GitHub 주소

https://github.com/seongwoo-choi/mini-cicd-project.git

EKS와 K8S의 차이점

EKS(Elastic Kubernetes Service)는 AWS에서 제공하는 '관리형 쿠버네티스' 이다.

쿠버네티스를 따로 구축하고 관리할 때는 마스터 노드 및 etcd를 이중화, 삼중화 하는것이 매우 중요한데, EKS에서는 마스터노드와 etcd 노드를 EKS가 관리해주고 Private Link로 연결되어 내부망 통신으로 안전하게 워커노드와 통신 할 수 있다.

1. AWS Managed

k8s는 Master Node와 Worker Node 둘다 관리해야 하지만 EKS를 사용하면 Master Node와 Worker Node 둘 다 AWS Managed에서 한번에 관리가 가능하다.

2. 클러스터 업그레이드 용이성

k8s에서 클러스터를 업그레이드 하려고 하면 매뉴얼과 절차대로 진행해야 한다.

반면 EKS를 사용하게 되면 AWS에서 클러스터 업그레이드를 클릭 한번으로 업데이트를 할 수 있다.

3. 네트워크 할당

쿠버네티스에서 파드를 생성하면 해당 파드는 클러스터 내에서만 볼 수 있게 가상 네트워크를 부여받는다.

네트워크 플러그인으로는 AWS CNI라는 플러그인이 사용되는데 해당 플러그인은 일반적인 CNI(Flannel, Callico)와 차이점이 있다.클러스터의 IP 대역을 VPC로 할당 받기 때문에 파드를 생성하면 VPC와 동일한 네트워크를 공유하게 된다.

즉, 파드는 클러스터를 생성하는 데 사용되는 서브넷의 IP를 사용하게 되고 Worker Node는 여러 네트워크 인터페이스(=ENI)로 파드(=오브젝트)의 IP를 관리한다.

4. 인증방식

EKS와 k8s와 다르게 EKS는 AWS IAM을 인증방식으로 사용해 사용자에게 역할을 할당시킨다.

II. 구현 절차

1. EC2 인스턴스 구성

Repository로 Docker Hub 또는 ECR 사용 가능, 본 프로젝트에서는 Docker Hub를 선택했다.

1-1. EC2 인스턴스에 IAM 역할 부여

EC2 인스턴스에서 eksctl 을 사용하여 클러스터를 생성하기 때문에 AdministratorAccess 정책을 부여한 역할이 필요하다.

AdministratorAccess 정책으로 EKS용 역할 생성하기

IAM 접속 → 액세스 관리 → 역할 → 역할 만들기

EC2 인스턴스에 역할을 부여할 것이므로 EC2 선택

AWS 관리에서 모든 권한을 줄 수 있는 AdministratorAccess 정책을 추가한다.

권한 추가 후 역할 생성 버튼 클릭하여 역할을 생성한다.

인스턴스의 IAM 역할 수정

인스턴스 선택 → 작업 → 보안 → IAM 역할 수정

EC2 인스턴스에서 IAM 역할 수정 화면

1-2. 보안 그룹 생성

ssh 와 jenkins 에 접속하기 위한 8080 포트 추가
접속 가능한 ip주소는 현재 인스턴스를 생성하고 실행할 컴퓨터인 나의 ip 주소를 사용

1-3. 인스턴스에 접속해 도구 설치

awscli, aws-iam-authenticator, kubectl, eksctl
Jenkins, Docker, Helm, ArgoCD 등

sudo hostname jenkins
sudo su - jenkins

awscli 설치

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" 
sudo apt install unzip
sudo unzip awscliv2.zip  
sudo ./aws/install
aws --version

AWS configure

AWS 명령줄 인터페이스(AWS CLI)는 명령줄 셸에서 명령을 사용하여 AWS 서비스와 상호 작용할 수 있는 오픈 소스 도구다. AWS CLI를 사용함으로써 터미널의 명령 프롬프트에서 브라우저 기반인 aws 콘솔에서 제공하는 것과 동일한 기능을 구현하는 명령 실행을 시작할 수 있게 된다.

aws configure 명령어를 사용해 IAM에서 미리 생성해 둔 사용자로 aws 계정에 로그인이 가능하다.

IAM 사용자 생성: IAM → 액세스 관리 → 사용자 → 사용자 추가

사용자 이름 지정 후 자격 증명 유형을 선택한다. 여기서는 액세스 키를 이용하여 로그인을 할 것이기 때문에 액세스 키 로그인 방식만 선택한다.

AdministratorAccess 권한을 부여하여 인스턴스에서 작업 수행이 가능하도록 한다.

태그는 생략 후 IAM을 최종으로 생성하면 아래와 같은 메세지가 출력된다. “.csv 다운로드” 후 파일 안에 있는 액세스 키 ID와 비밀 액세스 키를 복사하여 aws configure 로그인 시 아래와 같이 입력한다.

순서대로 액세스 키 ID, 비밀 키, 사용할 리전, 그리고 아웃풋 포맷(보통 JSON으로 설정)을 입력한다.

aws sts get-caller-identity 명령어를 통해 로그인 된 ID 정보를 확인할 수 있다.

aws-load-balancer-controller

공식 문서: https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/network-load-balancing.html, https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/alb-ingress.html, https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/aws-load-balancer-controller.html

helm repo add eks <https://aws.github.io/eks-charts>
helm repo update

aws sts get-caller-identity # account 확인

--set image.repository=dkr.ecr.region-code.amazonaws.com/amazon/aws-load-balancer-controller

helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=***myeks-custom*** --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller --set image.repository=***602401143452***.dkr.ecr.ap-northeast-2.amazonaws.com/amazon/aws-load-balancer-controller

aws-iam-authentication 설치

curl -o aws-iam-authenticator https://amazon-eks.s3.us-west-2.amazonaws.com/1.21.2/2021-07-05/bin/linux/amd64/aws-iam-authenticator
chmod +x ./aws-iam-authenticator
mkdir -p $HOME/bin && cp ./aws-iam-authenticator $HOME/bin/aws-iam-authenticator && export PATH=$PATH:$HOME/bin
echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc

aws-iam-authenticator help

앞에서 설정한 것 처럼, IAM 권한을 사용하여 AWS 서비스 및 리소스에 대한 액세스 권한을 지정하고 제어할 수 있다. IAM 역할에 권한을 부여하려면 액세스 유형, 수행할 수 있는 작업, 작업을 수행할 수 있는 리소스를 지정하는 정책을 연결하면 된다. IAM 정책을 사용하여 특정 AWS 서비스 API 및 리소스에 대한 액세스 권한을 부여할 수 있다. (여기서는 ec2 인스턴스에 권한을 부여하기 위해 설치하였다.)

curl 명령어로 aws-iam-authentication의 파일을 다운로드하고, **chmod**를 사용해 모두에게 실행 권한을 부여한다. 그리고 환경 변수를 설정하고 배쉬 설정 파일안에 세팅해준다. 마지막으로 help 명령어를 실행시켜 정상적으로 작동 여부를 확인 할 수 있다.

kubectl 1.22.8 설치

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
apt-cache madison kubectl | grep 1.22.8
sudo apt-get install kubectl=1.22.8-00 -y
sudo apt-mark hold kubectl

쿠버네티스 커맨드 라인 도구인 kubectl을 사용하면 쿠버네티스 클러스터에 대해 명령을 실행할 수 있다. kubectl 을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하고, 로그를 볼 수 있다.

여기서 사용할 버전은 1.22.8 버전이며 apt-get과 curl 명령어를 사용해 설치한다.

eksctl 설치

curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin
eksctl version

eksctl은 Amazon EKS에서 Kubernetes 클러스터를 생성 및 관리하기 위한 명령줄 유틸리티다. eksctl은 Amazon EKS용 노드가 있는 새 클러스터를 가장 쉽고 간편하게 생성하는 방법이다.

eksctl 을 설치 수 있는 깃허브 파일을 curl 명령어로 다운받고, 파일의 위치를 /usr/local/bin 밑으로 이동시킨다. 설치 후 eksctl version 명령어를 사용해 버전 확인이 가능하다.

Jenkins 설치

sudo apt update

sudo apt-get install default-jdk -y
java -version

sudo apt install maven -y
mvn --version

wget -q -O - https://pkg.jenkins.io/debian/jenkins.io.key | sudo apt-key add -
echo deb http://pkg.jenkins.io/debian-stable binary/ | sudo tee /etc/apt/sources.list.d/jenkins.list
sudo apt update
sudo apt install jenkins -y

sudo cat /var/lib/jenkins/secrets/initialAdminPassword # 젠킨스 접속시 사용되는 초기 암호 확인

Jenkins는 빌드와 테스트 등의 워크플로우에서 지속적인 통합(CI, Continous Integration) 서비스를 제공하는 툴이다. 반복되는 업무를 자동화 하기 위하여 구성된 도구로 한번의 설정으로 빌드를 자동화 시킬 수 있다.

Docker 설치

sudo apt install docker.io -y
sudo usermod -aG docker $USER
sudo systemctl start docker
sudo systemctl enable docker
sudo systemctl status docker

sudo usermod -aG docker jenkins
sudo service jenkins restart
sudo systemctl daemon-reload
sudo service docker stop
sudo service docker start

Docker 는 애플리케이션을 신속하게 구축, 테스트 및 배포할 수 있는 소프트웨어 플랫폼이다. Docker는 소프트웨어를 컨테이너라는 표준화된 유닛으로 패키징하며, 이 컨테이너에는 라이브러리, 시스템 도구, 코드, 런타임 등 소프트웨어를 실행하는 데 필요한 모든 것이 포함되어 있다. 이 프로젝트 내에서는 이미지를 빌드하는 역할을 수행한다.

Helm CLI 설치

curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
sudo apt-get install apt-transport-https --yes
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update
sudo apt-get install helm

Helm 은 Kubernetes 클러스터에서 좀 더 쉽게 애플리케이션을 설치하고 관리하는 프로그램이다. 로컬 시스템에서 Helm CLI를 사용하여 차트를 설치하고 관리할 수 있다. 여기서는 aws의 AWS Load Balancer Controller를 설치하기 위해 Helm Chart를 설치하였다.

ArgoCD CLI 설치

wget https://github.com/argoproj/argo-cd/releases/download/v2.2.5/argocd-linux-amd64 -O argocd
chmod +x argocd
sudo mv argocd /usr/local/bin

argocd는 Kubernetes를 위한 CD(Continuous Delivery)툴로, GitOps방식으로 관리되는 Manifest 파일의 변경사항을 감시하며, 현재 배포된 환경의 상태와 Git에 정의된 Manifest 상태를 동일하게 유지하는 역할을 수행 한다. 쉽게 말해 Jenkins 에서 빌드한 파일들을 자동으로 배포할 수 있게 만들고, 그 과정을 GUI 방식으로 볼 수 있도록 설계된 툴이다. 현재 프로젝트 내에서는 Jenkins를 CI로, argocd를 CD툴로 사용하였다.

2. Repository의 manifest로 eksctl 클러스터 생성

2-1. EC2 인스턴스 공개키 git 계정에 등록

sudo su - jenkins
ssh-keygen
cat .ssh/id_rsa.pub

github: Settings → SSH and GPG keys → New SSH Key → Key에 공개키(id_rsa.pub) 내용 입력

2-2. git clone으로 manifest 가져오기

깃 계정에 현재 인스턴스의 jenkins 호스트 공개키를 등록했기 때문에 ssh 방식으로 깃 클론이 가능하다. 아래와 같이 소스를 가져와 eksctl 명령어를 통해 클러스터를 생성한다.

$ sudo su - jenkins
$ git clone git@github.com:XXXXXX.git

2-3. 파일 기반 eksctl 클러스터 생성

$ cd mini-cicd-project
$ eksctl create cluster -f <파일명> 
# 15~20 분 정도 소요됨
$ kubectl get nodes

아래는 eksctl 클러스터를 생성할 때 사용한 파일의 각 부분이다.

우선 Cluster 환경을 설정하는 yaml 파일에 EKS 이름, 리전, k8s 버전, AZ 를 설정한다.

# project_myeks.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: project-myeks
  region: ap-northeast-2
  version: "1.22"

# AZ
availabilityZones: ["ap-northeast-2a", "ap-northeast-2b",  "ap-northeast-2c"]

아래 IAM 부분은 EKS 에서 사용할 애드온들에 대한 serviceAccounts 계정을 생성 하는 부분으로 IAM역할을 serviceAccounts 계정에 적절히 바인딩한다. eks 입장에서 AWS IAM 은 외부 인증 서버이기 때문에 OIDC 를 true 로 설정해야 한다. 자주 사용되는 애드온들의 경우 IAM역할들이 wellKnownPolicies 에 정의되어 있다. 각각의 애드온들은 alb, nlb 를 사용할 수 있게 하는 aws-load-balancer-controller, ebs 크기 변경 및 스냅샷을 찍을 수 있게 하는 ebs-csi-controller-sa, 클러스터 오토 스케일링이 가능하게 하는 cluster-autoscaler 이다.

# IAM OIDC & Service Account
iam:
  withOIDC: true
  serviceAccounts:
    - metadata:
        name: aws-load-balancer-controller
        namespace: kube-system
      wellKnownPolicies:
        awsLoadBalancerController: true
    - metadata:
        name: ebs-csi-controller-sa
        namespace: kube-system
      wellKnownPolicies:
        ebsCSIController: true
    - metadata:
        name: cluster-autoscaler
        namespace: kube-system
      wellKnownPolicies:
        autoScaler: true

다음은 워커 노드 그룹을 설정하는 부분으로 Production 용 노드만 만들었고 가용성을 높이기 위해 오토 스케일링을 사용한다. 또한 deploy 에서 생성되는 파드들이 해당 production 노드에 스케줄링되게 하기 위해서 labels: { role: production } 을 붙여주었으며, 노드 즉 EC2 인스턴스들이 모두 private subnet 에 배치되도록 설정했다. ssh 접속을 하기 위해 미리 키를 생성하여 인스턴스에 등록했다. 위에서 설정한 IAM 애드온들을 사용할 수 있도록 애드온 정책들을 true 로 설정했다.

# Managed Node Groups
managedNodeGroups:
  # On-Demand Instance
  - name: production
    instanceType: t2.medium
    minSize: 1
    desiredCapacity: 2
    labels: { role: production }
    maxSize: 3
    privateNetworking: true
    ssh:
      allow: true
      publicKeyPath: ./keypair/myssh.pub
    availabilityZones: ["ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c"]
    iam:
      withAddonPolicies:
        autoScaler: true
        albIngress: true
        cloudWatch: true
        ebs: true

EKS 로 생성되는 클러스터의 경우 컨트롤 플레인을 AWS 에서 자체적으로 관리해주기 때문에 어떤 작업이 이뤄졌는지 로그를 확인하기 어렵다. 그래서 아래와 같이 CloudWatch 에서 로그를 확인할 수 있도록 cloudWatch를 설정한다.

# CloudWatch Logging
cloudWatch:
  clusterLogging:
    enableTypes: ["*"]

전체 코드는 아래와 같다.

# project_myeks.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: project-myeks
  region: ap-northeast-2
  version: "1.22"

# AZ
availabilityZones: ["ap-northeast-2a", "ap-northeast-2b",  "ap-northeast-2c"]

# IAM OIDC & Service Account
iam:
  withOIDC: true
  serviceAccounts:
    - metadata:
        name: aws-load-balancer-controller
        namespace: kube-system
      wellKnownPolicies:
        awsLoadBalancerController: true
    - metadata:
        name: ebs-csi-controller-sa
        namespace: kube-system
      wellKnownPolicies:
        ebsCSIController: true
    - metadata:
        name: cluster-autoscaler
        namespace: kube-system
      wellKnownPolicies:
        autoScaler: true

# Managed Node Groups
managedNodeGroups:
  # On-Demand Instance
  - name: production
    instanceType: t2.medium
    minSize: 1
    desiredCapacity: 2
    labels: { role: production }
    maxSize: 3
    privateNetworking: true
    ssh:
      allow: true
      publicKeyPath: ./keypair/myssh.pub
    availabilityZones: ["ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c"]
    iam:
      withAddonPolicies:
        autoScaler: true
        albIngress: true
        cloudWatch: true
        ebs: true

# CloudWatch Logging
cloudWatch:
  clusterLogging:
    enableTypes: ["*"]

3. CI—Jenkins

웹 브라우저에서 인스턴스의 IP:8080 으로 접속한다. 앞서 젠킨스를 설치하고 난 뒤 sudo cat /var/lib/jenkins/secrets/initialAdminPassword 로 확인한 초기 암호를 입력한다.

관리자 설정과 권장 플러그인 설치를 끝내면 젠킨스의 메인 화면이 나타난다.

3-1. 기본 설정: 환경변수, 플러그인, 크레덴셜, 슬랙 알림

1) Global Tool Configuration에서 환경변수 설정

Maven을 다음과 같이 설정한다.

Name 에 지정한 값은 앞으로 젠킨스에서 구성할 작업에서 변수로 사용된다.
MAVEN_HOME의 위치: /usr/share/maven

maven 세팅 화면

2) Plugin 설치

Jenkins 관리 → 플러그인 관리 → 설치 가능 → Search
Docker, Docker pipeline, kubernetes CLI, Slack Notification

일부 플러그인은 Restart가 필요하다.

3) Credentials 등록

도커허브, 깃허브, 슬랙에 대한 3개의 Credentials 를 설정한다.

Jenkins 관리 → Manage Credentials → Domains (global) → Global credentials → Add Credentials

GitHub 계정 설정하기
- Kind: Username with Password
- Username: GitHub 계정명
- Password: GitHub에서 발급받은 토큰 값(Settings-Developer settings-Personal access tokens)
- ID: 젠킨스 내에서 해당 크레덴셜을 가리키기 위해 사용할 변수 이름을 지정한다.
Docker Hub Registry 계정 설정하기
1. dockerhub: Account Settings → Security → New Access Token → Generate
3. 아래와 같은 화면에서 생성된 토큰을 복사해 젠킨스 크레덴셜에 입력한다. Kind는 깃헙과 동일하게 “Username with Password”로 선택한다.
Slack 통합 토큰 자격 증명 ID 설정하기

이 부분은 다음 단계인 Slack 알림 설정 과정에서 서술한다.

4) Slack 알림을 위한 젠킨스 CI 앱 추가

참조: https://hello-startup.tistory.com/19

CI/CD의 각 단계가 순조롭게 진행되고 있는지를 실시간으로 확인하는 방법에는 여러가지가 있으나, 본 프로젝트에서는 Slack 메시지를 받는 방법을 선택했다.

우선 메시지를 받아볼 Slack 워크스페이스를 개설하고, Jenkins 에서 알람이 올 채널을 하나 개설하고, 슬랙 앱 메뉴에서 아래처럼 Jenkins CI를 검색한다.

아래 화면에서 Jenkins CI를 추가하면 링크가 열리고 Slack에 추가할 수 있다.

알림을 포스트할 채널을 고른 뒤, 통합 앱을 추가하면 설정 지침 페이지로 이동하며, 이곳에서 기타 젠킨스에서 앱을 설정하는 방법을 상세히 설명한다. 설정 지침에서 다음과 같이 팀 하위 도메인, 통합 토큰 자격 증명 ID 값이 부여되었음을 확인할 수 있다. 이 두 가지 값을 복사한다.

젠킨스로 돌아와, Jenkins 관리 → 시스템 설정 맨 하단 Slack 설정 부분을 찾는다. (Slack Notification plugin이 설치되어 있지 않으면 보이지 않음) Workspace에는 팀 하위 도메인 값을 붙여넣고, Default channel 에는 Slack 에서 생성한 채널 이름을 넣는다. Credential에는 열쇠 아이콘 Add 버튼을 눌러 Jenkins Credentials Provider를 선택한다.

Credential 추가를 위해 아래와 같이 Kind는 토큰 ID 값만을 사용하기 때문에 Secret text를 선택하고, Secret에 앞서 Jenkins CI 도구에서 복사해둔 통합 토큰 자격 증명 ID 값을 입력한다. ID는 임의 입력해도 무방하다.

추가한 크레덴셜의 ID를 드롭다운 메뉴에서 고르고 저장한다.

3-2. 파이프라인 생성

1) Jenkins Job 구성

새로운 item → Pipeline 선택 → Pipeline Tab(맨 하단 Pipeline으로 이동) → Definition에서 Pipeline script from SCM 선택

아래 그림과 같이 해당 Repository URL 에 Jenkins Credential 을 통해 인증하고 main 브랜치로 이동하여 Jenkinsfile 의 파이프라인 스크립트를 실행하도록 설정했다.

2) Jenkinsfile의 내용

위에서 Script Path에 설정한 바와 같이 Jenkinsfile은 GitHub repository 최상위 디렉토리에 위치한다.

전체 스크립트는 pipeline { } 안에 작성되며 이하 각 부분 별로 스크립트를 설명한다.

tools 안에는 Global Tool Configuration 에서 설정한 Maven3 를 사용할 수 있도록 maven 이라는 명칭을 부여했다.
environment 안에는 Jenkinsfile 스크립트에서 사용할 로컬 변수들을 설정했다. 도커 허브 레지스트리, 도커 허브 계정, 깃 허브 계정, 이메일, 이름 등을 변수로 설정해주었다.

  // Global Tool Configuration 에서 설정한 maven 의 명칭
  tools {
    maven 'Maven3' 
  }

  // 해당 스크립트 내에서 사용할 로컬 변수들 설정
  // 레포지토리가 없으면 생성됨
  // Credential들에는 젠킨스 크레덴셜에서 설정한 ID를 사용
  environment {
    dockerHubRegistry = 'how0326/tomcat' 
    dockerHubRegistryCredential = 'docker' 
    githubCredential = 'git_hub'
    gitEmail = 'how0326@gmail.com'
    gitName = 'seongwoo-choi'
  }

이하는 stages { } 안에 작성되며 그 하위 요소인 stage { } 에서 단계별 작업을 지정한다.

steps { } 내의 스크립트 실행이 끝난 후에 post { }안의 스크립트가 실행되며, failure { } 내부의 스크립트는 steps 가 실패할 경우, success { } 는 steps 가 성공할 경우에 실행된다.
우선 checkout 을 사용하여 깃허브에서 레포지토리를 클론해온다. 만약 프라이빗 레포지토리일 경우에는 environment 에서 지정한 깃허브 계정으로 클론한다.
두 번째 stage 는 tools 에서 지정한 maven 도구를 사용하여 Jar 파일을 생성하는 단계이다.

    // 깃허브 계정으로 레포지토리를 클론한다.
    stage('Checkout Application Git Branch') {
      steps {
        checkout([$class: 'GitSCM', branches: [[name: '*/main']], extensions: [], userRemoteConfigs: [[credentialsId: githubCredential, url: 'https://github.com/mini-cicd-project/mini-cicd-project.git']]])
      }
      // steps 가 끝날 경우 실행한다.
      // steps 가 실패할 경우에는 failure 를 실행하고 성공할 경우에는 success 를 실행한다.
      post {
        failure {
          echo 'Repository clone failure' 
        }
        success {
          echo 'Repository clone success' 
        }
      }
    }

    // Maven 을 사용하여 Jar 파일 생성    
    stage('Maven Jar Build') {
      steps {
        sh 'mvn clean install'  
      }
      post {
        failure {
          echo 'Maven war build failure' 
        }
        success {
          echo 'Maven war build success'
        }
      }
    }

세 번째 stage는 도커를 사용해 이미지를 빌드하는 단계이다.

이 단계부터는 성공, 실패 시에 슬랙에 알람이 오도록 설정했다.

    stage('Docker Image Build') {
      steps {
        // 도커 이미지를 빌드하며 빌드한 횟수에 따라 순차적으로 증가하는 젠킨스 자체 변수를 태그로 자동 지정한다.
        sh "docker build . -t ${dockerHubRegistry}:${currentBuild.number}"
        sh "docker build . -t ${dockerHubRegistry}:latest"
      }
      // 성공, 실패 시 슬랙에 알람오도록 설정
      post {
        failure {
          echo 'Docker image build failure'
          slackSend (color: '#FF0000', message: "FAILED: Docker Image Build '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        }
        success {
          echo 'Docker image build success'
          slackSend (color: '#0AC9FF', message: "SUCCESS: Docker Image Build '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        }
      }
    }

네번째 스테이지는 도커에 이미지를 푸시하는 단계이다.

로그인 부분은 젠킨스의 “Pipeline Syntax” 기능을 활용하여 도커 허브에 로그인하는 샘플 스크립트를 생성, 수정해 사용했다. 이후 도커 명령어로 도커 허브에 앞선 단계에서 생성한 이미지 두 개를 푸시한다.
이미지를 푸시한 이후에 10 초 쉰 후 후속작업을 실행하도록 했으며, 푸시가 성공하든 실패하든 현재 빌드된 이미지를 삭제하도록 했다. 이는 불필요한 스토리지 사용량을 줄이며, 다음 이미지 빌드 시에 캐시 사용으로 변경사항 미적용 오류 등을 방지하기 위한 방법이다.

    stage('Docker Image Push') {
      steps {
        // 젠킨스에 등록한 크레덴셜로 도커 허브에 이미지 푸시
        withDockerRegistry(credentialsId: dockerHubRegistryCredential, url: '') {
          sh "docker push ${dockerHubRegistry}:${currentBuild.number}"
          sh "docker push ${dockerHubRegistry}:latest"
          // 10초 쉰 후에 다음 작업을 이어나가도록 함
          sleep 10
        } 
      }

      post {
        failure {
          echo 'Docker Image Push failure'
          sh "docker rmi ${dockerHubRegistry}:${currentBuild.number}"
          sh "docker rmi ${dockerHubRegistry}:latest"
          slackSend (color: '#FF0000', message: "FAILED: Docker Image Push '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        }
        success {
          echo 'Docker Image Push success'
          sh "docker rmi ${dockerHubRegistry}:${currentBuild.number}"
          sh "docker rmi ${dockerHubRegistry}:latest"
          slackSend (color: '#0AC9FF', message: "SUCCESS: Docker Image Push '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        }
      }
    }

마지막 스테이지는 deploy/production.yaml 의 이미지 태그를 변경하여 깃허브에 푸시하는 단계이다.

Pipeline Syntax sample을 사용하여 깃허브에 로그인하는 스크립트를 작성하고, sed 명령어를 사용하여 deploy/production.yaml 의 이미지 태그를 변경한 뒤 메인 브랜치에 푸시하도록 했다.

    stage('K8S Manifest Update') {
      steps {
        // git 계정 로그인, 해당 레포지토리의 main 브랜치에서 클론
        git credentialsId: githubCredential,
            url: 'https://github.com/mini-cicd-project/mini-cicd-project.git',
            branch: 'main'  

        // 이미지 태그 변경 후 메인 브랜치에 푸시
        sh "git config --global user.email ${gitEmail}"
        sh "git config --global user.name ${gitName}"
        sh "sed -i 's/tomcat:.*/tomcat:${currentBuild.number}/g' deploy/production.yaml"
        sh "git add ."
        sh "git commit -m 'fix:${dockerHubRegistry} ${currentBuild.number} image versioning'"
        sh "git branch -M main"
        sh "git remote remove origin"
        sh "git remote add origin git@github.com:mini-cicd-project/mini-cicd-project.git"
        sh "git push -u origin main"
      }
      post {
        failure {
          echo 'K8S Manifest Update failure'
          slackSend (color: '#FF0000', message: "FAILED: K8S Manifest Update '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        }
        success {
          echo 'K8s Manifest Update success'
          slackSend (color: '#0AC9FF', message: "SUCCESS: K8S Manifest Update '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        }
      }
    }

전체 코드는 아래와 같다.

pipeline {
  agent any
  // Global Tool Configuration 에서 설정한 Name
  tools {
    maven 'Maven3' 
  }

  // 해당 스크립트 내에서 사용할 로컬 변수들 설정
  // 레포지토리가 없으면 생성됨
  // Credential들에는 젠킨스 크레덴셜에서 설정한 ID를 사용
  environment {
    dockerHubRegistry = 'how0326/tomcat' 
    dockerHubRegistryCredential = 'docker' 
    githubCredential = 'git_hub'
    gitEmail = 'how0326@gmail.com'
    gitName = 'seongwoo-choi'
  }

  stages {

    // 깃허브 계정으로 레포지토리를 클론한다.
    stage('Checkout Application Git Branch') {
      steps {
        checkout([$class: 'GitSCM', branches: [[name: '*/main']], extensions: [], userRemoteConfigs: [[credentialsId: githubCredential, url: 'https://github.com/mini-cicd-project/mini-cicd-project.git']]])
      }
      // steps 가 끝날 경우 실행한다.
      // steps 가 실패할 경우에는 failure 를 실행하고 성공할 경우에는 success 를 실행한다.
      post {
        failure {
          echo 'Repository clone failure' 
        }
        success {
          echo 'Repository clone success' 
        }
      }
    }

    // Maven 을 사용하여 Jar 파일 생성    
    stage('Maven Jar Build') {
      steps {
        sh 'mvn clean install'  
      }
      post {
        failure {
          echo 'Maven war build failure' 
        }
        success {
          echo 'Maven war build success'
        }
      }
    }
    stage('Docker Image Build') {
      steps {
        // 도커 이미지 빌드
        sh "docker build . -t ${dockerHubRegistry}:${currentBuild.number}"
        sh "docker build . -t ${dockerHubRegistry}:latest"
      }
      // 성공, 실패 시 슬랙에 알람오도록 설정
      post {
        failure {
          echo 'Docker image build failure'
          slackSend (color: '#FF0000', message: "FAILED: Docker Image Build '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        }
        success {
          echo 'Docker image build success'
          slackSend (color: '#0AC9FF', message: "SUCCESS: Docker Image Build '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        }
      }
    }  

    stage('Docker Image Push') {
      steps {
        // 젠킨스에 등록한 계정으로 도커 허브에 이미지 푸시
        withDockerRegistry(credentialsId: dockerHubRegistryCredential, url: '') {
          sh "docker push ${dockerHubRegistry}:${currentBuild.number}"
          sh "docker push ${dockerHubRegistry}:latest"
          // 10초 쉰 후에 다음 작업 이어나가도록 함
          sleep 10
        } 
      }

      post {
        failure {
          echo 'Docker Image Push failure'
          sh "docker rmi ${dockerHubRegistry}:${currentBuild.number}"
          sh "docker rmi ${dockerHubRegistry}:latest"
          slackSend (color: '#FF0000', message: "FAILED: Docker Image Push '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        }
        success {
          echo 'Docker Image Push success'
          sh "docker rmi ${dockerHubRegistry}:${currentBuild.number}"
          sh "docker rmi ${dockerHubRegistry}:latest"
          slackSend (color: '#0AC9FF', message: "SUCCESS: Docker Image Push '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        }
      }
    }

    stage('K8S Manifest Update') {
      steps {
        // git 계정 로그인, 해당 레포지토리의 main 브랜치에서 클론
        git credentialsId: githubCredential,
            url: 'https://github.com/mini-cicd-project/mini-cicd-project.git',
            branch: 'main'  

        // 이미지 태그 변경 후 메인 브랜치에 푸시
        sh "git config --global user.email ${gitEmail}"
        sh "git config --global user.name ${gitName}"
        sh "sed -i 's/tomcat:.*/tomcat:${currentBuild.number}/g' deploy/production.yaml"
        sh "git add ."
        sh "git commit -m 'fix:${dockerHubRegistry} ${currentBuild.number} image versioning'"
        sh "git branch -M main"
        sh "git remote remove origin"
        sh "git remote add origin git@github.com:mini-cicd-project/mini-cicd-project.git"
        sh "git push -u origin main"
      }
      post {
        failure {
          echo 'K8S Manifest Update failure'
          slackSend (color: '#FF0000', message: "FAILED: K8S Manifest Update '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        }
        success {
          echo 'K8s Manifest Update success'
          slackSend (color: '#0AC9FF', message: "SUCCESS: K8S Manifest Update '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        }
      }
    }

  }
}

3) Jenkins CI-Slack Notification 실행 확인

Pipeline 구성을 마치고 Save/Apply → Build Now

빌드가 시작되며 깃허브 레포지토리에서 Jenkinsfile 을 가져와 스크립트를 실행한다.

위와 같이 Stage View를 통해 오류 없이 Jenkinsfile의 실행이 성공한 것을 확인할 수 있다. slackSend가 설정된 각 스테이지의 실행이 성공(또는 실패)할 때마다 슬랙으로 알림이 전송된다. 아래 이미지는 도커 이미지 빌드, 푸시, 깃허브에 푸시가 성공했음을 알리는 슬랙 메시지이다.

실제로 아래와 같이 도커허브에 새로운 빌드 번호를 tag로 단 이미지가 푸시된 것을 확인할 수 있다.

4. CD—ArgoCD

4-1. ArgoCD 설치

참조: https://argo-cd.readthedocs.io/en/stable/getting_started/

1) aws-load-balancer-controller 설치

helm repo add eks https://aws.github.io/eks-charts
helm repo list
helm repo update
helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=project-myeks --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller --set image.repository=602401143452.dkr.ecr.ap-northeast-2.amazonaws.com/amazon/aws-load-balancer-controller

2) ArgoCD 설치 확인 및 웹 UI 접속

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

설치가 끝나면 argocd-server 서비스의 타입을 로드 밸런서로 변경한 후, 해당 로드 밸런서의 DNS 이름 주소로 접속할 수 있게 한다.

kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

kubectl -n argocd get all로 생성된 리소스들을 확인하고 service/argocd-server의 주소를 확인한다. 서버는 위에서 설정한 대로 LoadBalancer 타입이며 external-ip 에 도메인 주소가 부여된 것을 확인할 수 있다.

jenkins@jenkins:~$ kubectl -n argocd get all
NAME                                                    READY   STATUS    RESTARTS   AGE
pod/argocd-application-controller-0                     1/1     Running   0          3h58m
pod/argocd-applicationset-controller-66689cbf4b-xpm7g   1/1     Running   0          3h58m
pod/argocd-dex-server-66fc6c99cc-nlrlx                  1/1     Running   0          3h58m
pod/argocd-notifications-controller-8f8f46bd6-lrm5d     1/1     Running   0          3h58m
pod/argocd-redis-d486999b7-bh2f5                        1/1     Running   0          3h58m
pod/argocd-repo-server-7db4cc4b45-2b2dd                 1/1     Running   0          3h58m
pod/argocd-server-79d86bbb47-64w7s                      1/1     Running   0          3h58m

NAME                                              TYPE           CLUSTER-IP       EXTERNAL-IP                                                                   PORT(S)                      AGE
service/argocd-applicationset-controller          ClusterIP      10.100.204.233   <none>                                                                        7000/TCP                     3h58m
service/argocd-dex-server                         ClusterIP      10.100.68.12     <none>                                                                        5556/TCP,5557/TCP,5558/TCP   3h58m
service/argocd-metrics                            ClusterIP      10.100.113.208   <none>                                                                        8082/TCP                     3h58m
service/argocd-notifications-controller-metrics   ClusterIP      10.100.153.105   <none>                                                                        9001/TCP                     3h58m
service/argocd-redis                              ClusterIP      10.100.110.65    <none>                                                                        6379/TCP                     3h58m
service/argocd-repo-server                        ClusterIP      10.100.161.179   <none>                                                                        8081/TCP,8084/TCP            3h58m
service/argocd-server                             LoadBalancer   10.100.0.145     ad7af453685d843d8a0a210edf174fba-610535311.ap-northeast-2.elb.amazonaws.com   80:32388/TCP,443:30461/TCP   3h58m
service/argocd-server-metrics                     ClusterIP      10.100.61.142    <none>                                                                        8083/TCP                     3h58m

NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/argocd-applicationset-controller   1/1     1            1           3h58m
deployment.apps/argocd-dex-server                  1/1     1            1           3h58m
deployment.apps/argocd-notifications-controller    1/1     1            1           3h58m
deployment.apps/argocd-redis                       1/1     1            1           3h58m
deployment.apps/argocd-repo-server                 1/1     1            1           3h58m
deployment.apps/argocd-server                      1/1     1            1           3h58m

NAME                                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/argocd-applicationset-controller-66689cbf4b   1         1         1       3h58m
replicaset.apps/argocd-dex-server-66fc6c99cc                  1         1         1       3h58m
replicaset.apps/argocd-notifications-controller-8f8f46bd6     1         1         1       3h58m
replicaset.apps/argocd-redis-d486999b7                        1         1         1       3h58m
replicaset.apps/argocd-repo-server-7db4cc4b45                 1         1         1       3h58m
replicaset.apps/argocd-server-79d86bbb47                      1         1         1       3h58m

NAME                                             READY   AGE
statefulset.apps/argocd-application-controller   1/1     3h58m

확인한 주소로 브라우저에서 ArgoCD의 웹 UI에 접속한다.

admin 계정에 대한 암호는 아르고CD의 시작문서에서 안내하는 대로 다음 명령어를 통해 구할 수 있다.

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

4-2. Git 저장소에서 바로 애플리케이션 배포하기

1) Repository 연결

private repository 와 연동하기 위해 Repositories 설정 메뉴에서 아래 화면처럼 “Connect repo using HTTPS”를 선택한다.

Repository의 type은 git을 선택
ArgoCD가 바라볼 git 주소를 Repository URL에 입력
private repository 이므로 git hub ID와 Password(GitHub에서 발급받은 토큰 값) 입력

2) ArgoCD Application 생성

메인 화면 가운데의 “CREATE APPLICATION”으로 아래와 같은 앱 구성 화면을 연다.

General 섹션: 생성할 Application 이름을 지정하고 Sync 정책을 설정한다. git 저장소의 변경 사항을 자동으로 운영에 반영하기 위해 Automatic으로 설정하였다.

Source 섹션: repository URL에서 미리 등록한 git repository를 선택한 다음, 배포할 application의 위치(git repository에서의 위치)를 Path에 입력한다.

Destnation 섹션: kubernetes의 어느 cluster에 배포할지(아래 그림에서는 기본선택), 그리고 어떤 namespace에 배포할지를 결정한다. 마지막으로, 구성화면 최상단의 create를 눌러 앱을 생성한다.

아래는 생성된 애플리케이션을 확인하는 화면이다. 구성 시에 설정한 automatic sync policy에 따라 생성 직후 “Synced” 상태임을 확인할 수 있다.

아래는 해당 애플리케이션의 배포 및 연결 상태가 시각적으로 표시되는 화면이다.

배포된 App에 접속하려면 위 화면에서 myweb-ing(ALB)의 링크 셰어 아이콘 :을 누르거나, App Details에서 URLs를 찾는다.

아래는 배포된 앱에 접속했을 때 볼 수 있는 화면이다.

3) ArgoCD CLI

한편 ArgoCD CLI에서는 배포된 앱의 정보를 다음과 같이 확인할 수 있다.

아르고 CD 서버에 로그인하기

$ argocd login --insecure ac...32-882088216.ap-northeast-2.elb.amazonaws.com:80
Username: admin
Password:
'admin:login' logged in successfully
Context 'ac...16.ap-northeast-2.elb.amazonaws.com:80' updated

앱 정보 보기

$ argocd app get mini-project-cicd
Name:               mini-project-cicd
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          default
URL:                https://ac...16.ap-northeast-2.elb.amazonaws.com:80/applications/mini-project-cicd
Repo:               https://github.com/xxxx/xxxx.git
Target:             HEAD
Path:               deploy/
SyncWindow:         Sync Allowed
Sync Policy:        Automated
Sync Status:        Synced to HEAD (ee6b1a4)
Health Status:      Healthy

GROUP              KIND        NAMESPACE  NAME               STATUS  HEALTH   HOOK  MESSAGE
                   Service     default    production-svc-lb  Synced  Healthy        service/production-svc-lb unchanged
apps               Deployment  default    production-deploy  Synced  Healthy        deployment.apps/production-deploy configured
networking.k8s.io  Ingress     default    myweb-ing          Synced  Healthy        ingress.networking.k8s.io/myweb-ing unchanged

Sync Policy가 Automated 가 아닌 경우, 싱크를 실행하는 명령어는 다음과 같다.

argocd app sync <application>

kubectl로도 애플리케이션 Ingress 및 내부 Load Balancer의 DNS 주소를 볼 수 있다.

jenkins@jenkins:~$ kubectl get ing,svc -n default
NAME                                  CLASS    HOSTS   ADDRESSPORTS                                                                     AGE
ingress.networking.k8s.io/myweb-ing   <none>   *       k8s-default-mywebing-c51c82d215-597039061.ap-northeast-2.elb.amazonaws.com:80    42m

NAME                        TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
service/kubernetes          ClusterIP      10.100.0.1      <none>        443/TCP        13h
service/production-svc-lb   LoadBalancer   10.100.165.79   k8s-default-producti-7b54e179b8-1cecdb688046eb5a.elb.ap-northeast-2.amazonaws.com  80:30458/TCP   42m

5. CI/CD 연동 확인—Jenkins & ArgoCD

Jenkins와 ArgoCD 동기화 확인을 위해 jenkins에서 build를 실행한다.

정상적으로 build가 완료되었다.

ArgoCD에서 Refresh를 해주거나 약간 기다리면 변경 사항을 반영하여 자동으로 Synchronized가 진행되는 것을 볼 수 있다. 아래는 Sync Status를 통해 Jenkins로 인한 변동 사항이 ArgoCD에 정상적으로 동기화되었음을 확인하는 화면이다.

History and Rollback 을 통해서 아래치럼 배포 이력을 확인하고, 우측 상단의 버튼을 통해 Re-deploy 또는 Rollback 시킬 수 있다.

Sync Status를 통해 Jenkins로 인한 변동 사항이 ArgoCD에 정상적으로 동기화되었음을 확인할 수 있다.

6. 추가 구성

6-1. metrics-server

공식 문서: https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/metrics-server.html

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

6-2. Cluster Autoscaler

1) 수동 스케일링

eksctl scale nodegroup --name myeks-ng1 --cluster project-myeks --help

eksctl scale nodegroup --name myeks-ng1 --cluster project-myeks --nodes 2

2) 자동 스케일링

공식 문서: https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/autoscaling.html

curl -o cluster-autoscaler-autodiscover.yaml https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml

YAML 파일을 수정하고 **을 클러스터 이름으로 바꾼다.

                        - --expander=least-waste
            - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/project-myeks
          volumeMounts:
            - name: ssl-certs

kubectl patch deployment cluster-autoscaler \
  -n kube-system \
  -p '{"spec":{"template":{"metadata":{"annotations":{"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"}}}}}'

kubectl -n kube-system edit deployment.apps/cluster-autoscaler

48         - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/***project-myeks***
49         - ***--balance-similar-node-groups***
50         - ***--skip-nodes-with-system-pods=false***

현재 노드의 kubernetes 버전과 image 버전을 맞춰야 한다. 현재 kubernetes 버전은 1.22.6 이지만 오토스케일러 이미지는 1.22.2 가 제일 최신 버전이기 때문에 1.22.2 로 설정한다.

kubectl get nodes
NAME                                                 STATUS   ROLES    AGE   VERSION
ip-192-168-117-21.ap-northeast-2.compute.internal    Ready    <none>   50m   v1.22.6-eks-7d68063
ip-192-168-149-72.ap-northeast-2.compute.internal    Ready    <none>   50m   v1.22.6-eks-7d68063
ip-192-168-180-249.ap-northeast-2.compute.internal   Ready    <none>   50m   v1.22.6-eks-7d68063

kubectl set image deployment cluster-autoscaler \
  -n kube-system \
  cluster-autoscaler=k8s.gcr.io/autoscaling/cluster-autoscaler:v1.22.2

다음 명령어로 Cluster Autoscaler 로그를 확인한다.

kubectl -n kube-system logs -f deployment.apps/cluster-autoscaler

6-3. CloudWatch Container Insight

공식 문서: https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-EKS-quickstart.html

ClusterName='project-myeks'
LogRegion='ap-northeast-2'
FluentBitHttpPort='2020'
FluentBitReadFromHead='Off'
[[ ${FluentBitReadFromHead} = 'On' ]] && FluentBitReadFromTail='Off'|| FluentBitReadFromTail='On'
[[ -z ${FluentBitHttpPort} ]] && FluentBitHttpServer='Off' || FluentBitHttpServer='On'
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/quickstart/cwagent-fluent-bit-quickstart.yaml | sed 's/{{cluster_name}}/'${ClusterName}'/;s/{{region_name}}/'${LogRegion}'/;s/{{http_server_toggle}}/"'${FluentBitHttpServer}'"/;s/{{http_server_port}}/"'${FluentBitHttpPort}'"/;s/{{read_from_head}}/"'${FluentBitReadFromHead}'"/;s/{{read_from_tail}}/"'${FluentBitReadFromTail}'"/' | kubectl apply -f -

윈도우는 쉘 스크립트를 실행하지 못해서 git bash 를 다운받아서 실행해야 한다.

❯ kubectl get po -A
NAMESPACE           NAME                                            READY   STATUS    RESTARTS   AGE
amazon-cloudwatch   cloudwatch-agent-8khfv                          1/1     Running   0          74s
amazon-cloudwatch   cloudwatch-agent-l9w7j                          1/1     Running   0          74s
amazon-cloudwatch   fluent-bit-lrzx2                                1/1     Running   0          74s
amazon-cloudwatch   fluent-bit-vlc9x                                1/1     Running   0          74s

fluent-bit 가 로그를 수집하고 cloudwatch-agent 에게 로그를 보내주면 cloudwatch 에 로그가 쌓인다.

kubectl get nodes --show-labels
NAME                                                 STATUS   ROLES    AGE   VERSION               LABELS
ip-192-168-149-72.ap-northeast-2.compute.internal    Ready    <none>   77m   v1.22.6-eks-7d68063   alpha.eksctl.io/cluster-name=project-myeks,alpha.eksctl.io/nodegroup-name=myeks-ng1,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=t3.medium,beta.kubernetes.io/os=linux,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup-image=ami-06512ccb913a9d11d,eks.amazonaws.com/nodegroup=myeks-ng1,eks.amazonaws.com/sourceLaunchTemplateId=lt-018ac7a7f7853aa04,eks.amazonaws.com/sourceLaunchTemplateVersion=1,failure-domain.beta.kubernetes.io/region=ap-northeast-2,failure-domain.beta.kubernetes.io/zone=ap-northeast-2b,kubernetes.io/arch=amd64,kubernetes.io/hostname=ip-192-168-149-72.ap-northeast-2.compute.internal,kubernetes.io/os=linux,node.kubernetes.io/instance-type=t3.medium,topology.ebs.csi.aws.com/zone=ap-northeast-2b,topology.kubernetes.io/region=ap-northeast-2,topology.kubernetes.io/zone=ap-northeast-2b

alpha.eksctl.io/cluster-name=project-myeks
alpha.eksctl.io/nodegroup-name=myeks-ng1
beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=t3.medium,beta.kubernetes.io/os=linux
eks.amazonaws.com/capacityType=ON_DEMAND
eks.amazonaws.com/nodegroup-image=ami-06512ccb913a9d11d
eks.amazonaws.com/nodegroup=myeks-ng1
eks.amazonaws.com/sourceLaunchTemplateId=lt-018ac7a7f7853aa04
eks.amazonaws.com/sourceLaunchTemplateVersion=1
failure-domain.beta.kubernetes.io/region=ap-northeast-2
failure-domain.beta.kubernetes.io/zone=ap-northeast-2b
kubernetes.io/arch=amd64
kubernetes.io/hostname=ip-192-168-149-72.ap-northeast-2.compute.internal
kubernetes.io/os=linux,node.kubernetes.io/instance-type=t3.medium
topology.ebs.csi.aws.com/zone=ap-northeast-2b
topology.kubernetes.io/region=ap-northeast-2
topology.kubernetes.io/zone=ap-northeast-2b

7. Troubleshooting

테라폼으로 VPC를 직접 생성하고 클러스터 생성에 활용 시 오류 발생

문제: 테라폼으로 VPC를 생성한 후 해당 VPC와 서브넷 주소를 할당해서 클러스터를 생성했을 때, LoadBalancer 가 VPC 에 할당되지 않았다.
해결: eksctl 로 VPC 가 자동으로 생성되도록 했다.

Jenkins Helm chart 생성시 오류 발생

문제: 헬름 차트로 젠킨스를 생성했을 시, ALB, NLB 가 제대로 연결이 되지 않는다.
추정 이유: LB가 타겟 그룹에 제대로 연결되지 않아 생기는 것으로 짐작된다.
해결: ALB를 하나만 생성했다.

도커의 사용

문제: EKS 클러스터에서 도커를 사용할 수 없기 때문에 Jenkins 에서 도커를 사용할 수 없다.
해결: 마스터 슬레이브 구조로 구축하는 것이 최선이나 시간적인 여유가 없어 EC2 인스턴스에 젠킨스를 설치하는 방식으로 우회하였다.

AWS Load Balancer Controller 설치 오류

문제: AWS Load Balancer Controller 설치를 시도했을 때 다음과 같은 메시지가 출력되며 설치가 진행되지 않는다.

Error: INSTALLATION FAILED: Kubernetes cluster unreachable: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1alpha1"

해결: 해결하지 못함. EC2를 새로 만들고 처음부터 재설치 진행.

EKS 클러스터의 완전 삭제

문제: 실습을 반복하면서 EKSCTL 로 깨끗하게 지워지지 않은 클러스터가 남아 새 클러스터가 정상적으로 생성되지 않는다.
해결: AWS 웹콘솔의 CloudFormation에서 직접 스택을 삭제하고 연결된 리소스를 직접 정리한다.

[kubernetes] PV, PVC

ssunw — Thu, 28 Jul 2022 14:33:57 +0900

퍼시스턴트 볼륨(PV)와 퍼시스턴트 볼륨 클레임(PVC)

데이터베이스처럼 파드 내부에서 특정 데이터를 보유해야 하는 상태가 있는(stateful) 애플리케이션의 경우 데이터를 어떻게 관리해야 할까 고민해봐야 한다. 예를 들어, MySQL 디플로이먼트를 통해 파드를 생성하더라도 MySQL 파드 내부에 저장된 데이터는 영속적이지 않다.

디플로이먼트를 삭제하면 파드도 함께 삭제되고 그와 동시에 파드의 데이터 또한 함께 삭제되기 때문이다.

이를 해결하기 위해서 파드의 데이터를 영속적으로 저장하기 위한 방법이 필요하다.

쿠버네티스는 워커 노드 중 하나를 선택해 파드를 할당하는데, 특정 노드에서만 데이터를 보관해 저장하면 파드가 다른 노드로 옮겨갔을 때 해당 데이터를 사용할 수 없게 되기 이를 해결하기 위한 일반적인 방법은 어느 노드에서도 접근해 사용할 수 있는 퍼시스턴트 볼륨을 사용하는 방법이다.

PV는 워커 노드들이 네트워크 상에서 스토리지를 마운트해 영속적으로 데이터를 저장할 수 있는 볼륨을 의미한다. 따라서 파드에 장애가 생겨 다른 노드로 옮겨가더라도 해당 노드에서 PV에 네트워크로 연결해 데이터를 계속해서 사용할 수 있다.

네트워크로 연결해 사용할 수 있는 PV의 대표적인 예로는 NFS, AWS의 EBS, Ceph, ClusterFS 등이 있다.

쿠버네티스는 PV를 사용하기 위한 기능을 자체적으로 제공하고 있다.

로컬 볼륨: hostPath, emptyDir

hostPath는 호스트와 볼륨을 공유하기 위해서 사용하고, emptyDir은 파드의 컨테이너 간에 볼륨을 공유하기 위해서 사용한다. 이 두가지는 자주 사용되는 볼륨 종류는 아니긴 하다.

워커 노드의 로컬 디렉토리를 볼륨으로 사용: hostPath

파드의 데이터를 보존할 수 있는 가장 간단한 방법은 호스트의 디렉토리를 파드와 공유해 데이터를 저장하는 방법이다. docker 의 -v 옵션이라고 생각하면 된다.

volumes 항목에 볼륨을 정의한 뒤, 이를 파드를 정의하는 containers 항목에 참조해 사용한다. 위 예시에서는 볼륨에서 hostPath 항목을 정의함으로써 호스트의 /tmp 디렉토리를 파드의 /etc/data 에 마운트했다.

파드를 생성한 뒤 파드의 컨테이너 내부로 들어가 /etc/data 디렉토리에 파일을 생성하면 호스트의 /tmp 디렉토리에 파일이 저장된다. 파드 컨테이너의 /etc/data와 호스트의 /tmp는 동일한 디렉토리로써 사용된다.

$ kubectl exec -it hostpath-pod touch /etc/data/mydata
$ ls /tmp/mydata
/tmp/mydata

이런 방식의 데이터 보존은 바람직하지 않다. 디플로이먼트의 파드에 장애가 생겨 다른 노드로 파드가 옮겨 갔을 경우 이전 노드에 저장된 데이터를 사용할 수 없기 때문이다.

hostPath 볼륨을 반드시 사용해야 한다면 노드 스케줄링 기능을 사용하여 특정 노드에만 파드를 배치하는 방법을 생각해봐야 한다.

hostPath 볼륨은 모든 노드에 배치해야 하는 특수한 파드의 경우에 유용하게 사용할 수 있다. 만약, CAdvisior와 같은 모니터링 툴을 쿠버네티스의 모든 워커 노드에 배포해야 한다면 hostPath 를 사용하는 것이 옳은 선택이다. 이런 경우를 제외하고서는 hostPath 볼륨을 사용하는 것은 보안 및 활용성 측면에서 바람직한 방법이 아니다.

파드 내의 컨테이너 간 임시 데이터 공유: emptyDir

emptyDir 볼륨은 파드의 데이터를 영속적으로 보존하기 위해 외부 볼륨을 사용하는 것이 아닌, 파드가 실행되는 도중에만 필요한 휘발성 데이터를 각 컨테이너가 함께 사용할 수 있도록 임시 저장 공간을 생성한다.

emptyDir 이라는 이름이 의미하는 것처럼 emptyDir 디렉토리는 비어있는 상태로 생성되며 파드가 삭제되면 emptyDir에 저장돼 있던 데이터도 함께 삭제된다.

emptyDir 은 한 컨테이너가 파일을 관리하고 한 컨테이너가 그 파일을 사용하는 경우 유용하게 사용할 수 있다. content-creator 컨테이너 내부로 들어가 /data 디렉토리에 웹 컨텐츠를 생성하면 아파치 웹 서버 컨테이너의 htdocs 디렉토리에도 동일하게 웹 컨텐츠 파일이 생성될 것이고, 웹 서버에 의해 외부로 제공된다.

$ kubectl exec -it emptyDir-pod -c content-creator sh
/ # echo Hello, World! >> /data/test.html

이런 방법외에도 깃허브 소스코드를 pull 받아와서 emptyDir을 통해 애플리케이션 컨테이너에 공유해주는 사이드카 컨테이너를 생각할 수도 있고 설정 파일을 동적으로 갱신하는 컨테이너를 파드에 포함시킬 수도 있다.

네트워크 볼륨

쿠버네티스에서는 별도의 플러그인을 설치하지 않아도 다양한 종류의 네트워크 볼륨을 파드에 마운트할 수 있다. 온프레미스 환경에서도 구축할 수 있는 NFS, iSCSI, GlusterFS, Ceph 와 같은 네트워크 볼륨뿐만 아니라 AWS의 EBS, GCP의 gcePersistentDisk 와 같은 클라우드 플랫폼의 볼륨을 마운트할 수 있다.

사용 가능한 모든 스토리지 종류는 쿠버네티스 공식 문서에서 확인할 수 있다.

네트워크 볼륨의 위치는 특별하게 정해진 것은 없고, 네트워크로 접근할 수 만 있으면 쿠버네티스 클러스터 내부, 외부 어느 곳에 존재해도 상관없다. 단, AWS의 EBS와 같은 클라우드에 종속적인 볼륨을 사용하려면 AWS에서 쿠버네티스 클러스터를 생성할 때 특정 클라우드를 위한 옵션이 별도로 설정돼 있어야 한다.

NFS를 네트워크 볼륨으로 사용하기

여러 개의 클라이언트가 동시에 마운트해서 사용할 수 있지만 여러 개의 스토리지를 클러스터링하는 다른 솔루션에 비해 안정성이 떨어진다. 하지만 하나의 서버만으로 간편하게 사용할 수 있으며, NFS를 마치 로컬 스토리지처럼 사용할 수 있다는 장점이 있다.

NFS 서버를 사용하려면 NFS 서버와 NFS 클라이언트가 각각 필요하다. NFS 서버는 영속적인 데이터가 실제로 저장되는 네트워크 스토리지 서버이고, NFS 클라이언트는 NFS 서버에 마운트해 스토리지에 파일을 읽고 쓰는 역할이다. NFS 클라이언트는 워커 노드의 기능을 사용할 것이기 때문에 따로 준비할 필요는 없고 NFS 서버만 별도로 구축하면 된다.

NFS 서버를 위한 디플로이먼트와 서비스를 생성했고, NFS 서버의 볼륨을 파드에서 마운트해 데이터를 영속적으로 저장시킨다.

NFS 서버를 컨테이너에서 마운트하는 파드를 생성한다.

mountPath를 /mnt로 설정했기 때문에 NFS 서버의 네트워크 볼륨은 파드 컨테이너의 /mnt 디렉토리에 마운트 될 것이다. 즉, 컨테이너 내부에서 /mnt 디렉토리에 파일을 저장하면 NFS 서버에 데이터가 저장된다.

volumes 항목에서 nfs 라는 항목을 정의함으로써 NFS 서버의 볼륨을 사용한다고 명시했다.

여기 예제에서 유의해야 할 부분은 server 항목이 nfs-service라는 서비스의 DNS 이름이 아닌 {NFS_SERVICE_IP}로 설정돼 있다는 것이다. NFS 볼륨의 마운트는 컨테이너 내부가 아닌 워커 노드에서 발생하므로 서비스의 DNS 이름으로 NFS 서버에 접근할 수 없다.

노드에서는 파드의 IP로 통신은 할 수 있지만 쿠버네티스의 DNS를 사용하도록 설정돼 있지 않기 때문이다.

그래서 예외적으로 NFS 서비스의 Cluster IP 를 직접 얻은 뒤, YAML 파일에서 사용하는 방식으로 파드를 생성한다.

$ export NFS_CLUSTER_IP=$(kubectl get svc nfs-service -o jsonpath='{.spec.clusterIP}')

$ cat nfs-pod.yaml | sed "s/{NFS_SERVICE_IP}/$NFS_CLUSTER_IP/g" | kubectl apply -f -

kubectl get - o jsonpath 명령어를 사용하여 리소스의 특정 정보만 가져올 수 있다.

NFS 서버에 마운트하려면 워커 노드에서 별도의 NFS 패키지를 설치해야 할 수도 있다. 만약 파드가 ContainerCreating 상태에서 더 이상 진행되지 않는다면 kubectl describe pod 명령어로 문제를 확인하고 파드가 할당된 워커 노드에서 $ apt-get install nfs-common 패키지를 설치한다.

실제 운영환경에서 NFS 서버를 도입하려면 백업 스토리지를 별도로 구축해 NFS의 데이터 손실에 대비하거나 NFS 서버의 설정 튜닝 및 NFS 서버에 접근하기 위한 DNS 이름을 준비해야 할 수도 있다. 이런 설정들은 환경에 맞게 적절히 구성해야 한다.

PV, PVC를 이용한 볼륨 관리

PV와 PVC를 사용하는 이유

PVC 는 PV의 세부적인 사항을 몰라도 볼륨을 사용할 수 있도록 추상화해주는 역할을 담당한다. 즉, 파드를 생성하는 YAML 입장에서는 네트워크 볼륨이 NFS인지, AWS의 EBS인지 상관없이 볼륨을 사용할 수 있도록 하는 것이 PVC의 핵심 아이디어이다.

PV와 PVC를 사용하는 흐름을 간단하게 나타내면 아래와 같다.

여러 종류의 네트워크 볼륨을 이용해 PV를 미리 생성한다.
필요한 볼륨 크기, 볼륨의 속성을 명시한 PVC 를 생성한다.
PVC 요청에 부합하는 PV를 바인드해 컨테이너에 마운트한다.

위 과정에서 중요한 점은 ‘사용자는 디플로이먼트의 YAML 파일에 볼륨의 상세한 스펙을 정의하지 않아도 된다는 것이다.’ 사용자는 YAML 파일에서 이 디플로이먼트는 볼륨을 마운트할 수 있어야 한다는 의미의 퍼시스턴트 볼륨 클레임을 명시할 뿐이고, 실제로 마운트되는 볼륨이 무엇인지 알 필요가 없다.

AWS에서 PV, PVC 사용

AWS 상에서 kops 나 EKS 로 쿠버네티스를 설치했다면 PV를 EBS와 연동해 사용할 수 있다.

AWS에서 EBS를 쿠버네티스의 PV로 등록하려면 가장 먼저 EBS를 생성해야 한다. AWS 웹사이트 관리 콘솔에서 EBS를 생성해도 상관없지만 여기서는 aws-cli 명령어를 사용해 EBS를 생성한다.

--size 옵션에서는 볼륨의 크기를 기가바이트(GB) 단위로 입력한다. 다음 명령어는 5기가의 EBS 볼륨을 생성하는 예이다.

$ export VOLUME_ID=$(aws ec2 create-volume --size 5
--region ap-northeast-2
--availability-zone ap-northeast-2a
--volum-type gp2
--tag-specifications
'ResourceType=volume, Tags=[{Key=KubernetesCluster,Value=mycluster.k8s.local}]'
| jq '.VolumeId' -r)

$ echo $VOLUME_ID
vol-xxxx...

EBS의 볼륨 ID를 $VOLUME_ID라는 셸 변수에 저장하고 이 ID를 통해 PV를 생성한다.

EBS의 가용 영역과 리전은 반드시 쿠버네티스 워커 노드와 동일한 곳에 있어야 한다.

AWS의 EBS를 마운트하기 위해 awsElasticBlockStore라는 항목을 정의했다. 볼륨의 타입에 따라 하위 항목에 정의하는 옵션이 달라질 수 있으며, EBS의 볼륨 ID를 입력해야 한다.

$ cat ebs-pv.yaml | sed "s/<VOLUME_ID>/$VOLUME_ID/g" | kubectl apply -f -

PVC 를 생성하지 않았기 때문에 STATUS 항목이 Avaliable 로 설정된다.

애플리케이션을 배포하려는 사용자 입장에서 PV, PVC 파드를 함께 생성한다. PVC 오브젝트를 먼저 생성한 뒤 이를 파드의 volumes 항목에서 사용함으로써 파드 내부에 EBS 볼륨을 마운트한다.

PVC 의 요구 사항과 일치하는 PV 가 존재하지 않는다면 파드는 계속해서 Pending 상태로 남아있는다.

PV와 PVC 상태가 bound로 설정됐다면 두 리소스가 성공적으로 연결된 것이다. 파드가 정상적으로 생성되어 Running 상태라면 EBS 볼륨 또한 파드 내부에 정상적으로 마운트됐다는 뜻이다.

PV는 네임 스페이스에 속하지 않는 오브젝트이지만, PVC는 네임스페이스에 속하는 오브젝트이다.

위 과정을 다시 순차적으로 나타내면 아래와 같다.

파드의 데이터를 영속적으로 저장하기 위해 AWS EBS 볼륨을 생성한다. awscli 나 콘솔에서 직접 생성한 뒤 볼륨의 ID를 기록한다.
EBS 볼륨을 쿠버네티스 PV로 등록한다. 이 때 YAML 파일에 awsElasticBlockStore 항목에 EBS 볼륨 ID를 명시한다. 또한 볼륨의 읽기 및 쓰기 속성, 볼륨의 크기를 별도로 설정한다.
PVC 생성하는 YAML 파일에 원하는 볼륨의 조건을 나열한다.
PV 속성이 PVC의 요구 조건과 일치할 경우 리소스가 연결된다. kubectl get pv,pvc 출력 결과를 확인하면 리소스의 상태가 Bound 즉, 연결 상태로 바뀌는 것을 확인할 수 있다.
파드는 PVC 를 사용하도록 설정돼 있고 최종적으로 EBS 볼륨이 컨테이너 내부에 마운트된다.

PV 를 선택하기 위한 조건 명시

PVC 를 사용하면 볼륨이 어떤 스펙을 가졌는지 알 필요는 없지만 사용하려는 볼륨이 애플리케이션에 필요한 최소한의 조건을 맞출 필요는 있다.

볼륨의 크기가 적어도 얼마나 돼야 하는지, 여러 개의 파드에 마운트 될 수 있는지, 읽기 전용으로만 사용할 수 있는지 등이 조건에 해당할 수 있다.

AccessMode나 볼륨의 크기 등이 바로 이런 조건에 해당한다. PV와 PVC의 accessMode 및 볼륨 크기 속성이 부합해야만 쿠버네티스는 두 리소스를 매칭해 바인드한다.

NFS 는 여러 개의 인스턴스에 의해 마운트가 가능하지만(1:N 마운트), AWS의 EBS는 하나의 인스턴스에 의해서만 마운트될 수 있다(1:1 마운트). 또한, NFS 서버의 저장 공간 크기는 일반적으로 호스트의 스토리지 크기와 동일하지만, AWS의 EBS는 생성 당시에 설정했던 크기만큼만 데이터를 저장할 수 있다.

AccessModes와 볼륨 크기, 스토리지 클래스, 라벨 셀렉터를 이용한 PV 선택

accessModes는 PV와 PVC를 생성할 때 설정할 수 있는 속성으로 볼륨에 대해 읽기 및 쓰기 작업이 가능하지, 여러 개의 인스턴스에 의해 마운트 될 수 있는지 등을 의미한다. 사용 가능한 accessModes 의 종류는 아래와 같다.

ReadWriteOnce: 1:1 마운트만 가능, 읽기 쓰기 가능, RWO 로 출력
ReadOnlyMany: 1:N 마운트 가능, 읽기 전용, ROX 로 출력
ReadWriteMany: 1:N 마운트 가능, 읽기 쓰기 가능, RWX 로 출력

accesModes 나 볼륨의 크기는 해당 볼륨의 메타데이터일 뿐, 볼륨이 정말로 그러한 속성을 가지도록 강제하지는 않는다. 예를 들어 AWS의 EBS를 통해 PV를 생성하더라도 accessModes를 ReadWriteMany로 설정할 수 있다.

Local, hostPath 등 로컬 볼륨을 PV로 사용할 수 있는데, 그러한 경우 YAML 파일의 capacity.storage 항목에 크기를 지정한다고 해서 해당 크기의 새 디스크 파티션이 생성되는 것도 아니다. 따라서 이런 설정들은 애플리케이션을 배포할 때 적절한 볼륨을 찾아주는 라벨과 같은 역할을 한다고 생각하면 된다.

그 외에도 스토리지 클래스나 라벨 셀렉터를 이용해 PV의 선택을 좀 더 세분화할 수 있다. 스토리지 클래스는 볼륨의 대표 속성 등을 나타내는 것으로, PV를 생성할 때 클래스를 설정하면 해당 클래스를 요청하는 PVC와 연결해 바인드한다.

위의 두 개의 YAML에서는 각각 storageClassName 이라는 항목에 my-ebs-volume 이라는 값을 입력했다. 이러한 경우 스토리지 클래스의 이름이 일치하는 PV와 PVC이 서로 연결된다.

단, storageClassName을 별도로 YAML 파일에 명시하지 않으면 클래스가 설정되지 않았다는 뜻 인 ”” 으로 설정되며 똑같이 스토리지 클래스가 설정되지 않은 PV 또는 PVC와 매칭된다.

또는 라벨 셀렉터를 사용할 수도 있다. 서비스와 디플로이먼트를 서로 연결할 때 라벨 셀렉터를 사용했던 것처럼 PVC에 라벨 셀렉터인 matchLabels 항목을 정의함으로써 특정 PV와 바인드하는 것이 가능하다.

PV의 라이프 사이클과 Reclaim Policy

PV 를 정상적으로 생성하고 STATUS 부분을 확인하면 Avaliable 로 되어있는 것을 확인할 수 있다. STATUS라는 항목은 PV가 사용 가능한지, PVC와 연결됐는지 등을 의미한다.

PVC를 새로 생성하여 바인드했을 때는 STATUS 항목이 Bound(연결됨)로 바뀌는 것을 확인할 수 있다. PV가 이미 바인드 됐기 때문에 다른 PVC 와 연결할 수 없는 상태이다.

PV와 연결된 PVC를 삭제할 경우 직관적으로 생각하면 PVC 가 없어졌으니 연결된 PV를 다시 사용할 수 있을 것처럼 생각할 수 있다.

PVC 를 삭제하면 PV의 STATUS가 Available 이 아닌 Released 상태로 변경된다. Released 는 해당 PV의 사용이 끝났다는 것을 의미하며, Released 상태에 있는 PV는 다시 사용할 수 없다.

그렇지만 실제 데이터는 볼륨 안에 고스란히 보존돼 있기 때문에 PV 오브젝트를 삭제한 뒤 다시 생성하면 Avaliable 상태의 볼륨을 다시 사용할 수 있다.

하지만, PVC를 삭제했을 때, PV의 데이터를 어떻게 처리할 것인지 별도로 정의할 수도 있다. PV 사용이 끝났을 때 해당 볼륨을 어떻게 초기화 할 것인지 별도로 설정할 수 있는데 쿠버네티스는 이를 Reclaim Policy라고 부른다. 크게 Retain, Delete, Recycle 방식이 존재한다.

보통 PV의 용도는 데이터를 영구적으로 저장하기 위한 것이기 때문에 PV 사용이 끝난 뒤에도 원격 스토리지에 저장된 데이터를 계속해서 보존하고 싶을 것이다. 쿠버네티스는 기본적으로 PV 데이터를 보존하는 방식인 Retain 방식이 기본값으로 사용한다.

kubectl get pv 명령어에서 출력되는 RECLAIM POLICY 항목의 Retain 이라는 설정값이 이를 뜻한다.

PV 라이프 사이클에 대한 아무런 설정을 하지 않았다면 즉, PV 의 Reclaim Policy가 기본값인 Retain 으로 설정돼 있다면 PV 의 라이프 사이클은 Available → Bound → Released 가 된다.

Reclaim Policy 가 Retain으로 설정된 PV는 연결된 PVC가 삭제된 후 Released 상태로 전환되며, 스토리지에 저장된 데이터는 그대로 보존된다.

Retain 과 반대의 역할을 하는 Delete, Recycle 정책이 있다. PV 의 리클레임 정책을 Delete 로 설정해 생성했다면 PV의 사용이 끝난 뒤에 자동으로 PV가 삭제되며, 가능한 경우에 한해서 연결된 외부 스토리지도 함께 삭제된다.

$ cat ebs-pv-delete.yaml | sed "s/<VOLUME_ID>/$VOLUME_ID/g" | kubectl apply -f -

리클레임 정책이 Delete 인 PV를 파드 내부에 마운트한 뒤 PVC 를 삭제함으로써 사용을 종료할 경우, 리클레임 정책이 Delete 이기 때문에 PVC가 삭제됨과 동시에 PV가 삭제된다. 그 뿐만 아니라 외부에 연결돼 있던 EBS 볼륨도 한꺼번에 삭제되기 매누에 볼륨에 저장돼 있던 파일들이 모두 유실된다.

Recycle 정책은 PVC 가 삭제됐을 때 PV 데이터를 모두 삭제한 뒤, Available 상태로 만들어준다. 이 정책은 Delete 와 다르게 PV나 외부 스토리지 자체를 삭제하지는 않는다. Recycle 정책은 쿠버네티스에서 더 이상 사용되지 않을 정책 중 하나이다.

storageClass와 Dynamic Provisioning

PV를 사용하려면 미리 외부 스토리지를 준비해야만 했다. AWS의 EBS를 PV로 사용하려면 EBS를 미리 생성한 뒤, 볼륨 ID를 YAML 파일에 직접 입력하는 방식이었다.

매번 이렇게 볼륨 스토리지를 직접 수동으로 생성하고 스토리지에 대한 접근 정보를 YAML 파일에 적는 것은 귀찮은 일이다.

이를 위해 쿠버네티스는 동적 프로비저닝이라는 기능을 제공한다. 동적 프로비저닝은 PVC가 요구하는 조건과 일치하는 PV가 존재하지 않는다면 자동으로 PV와 외부 스토리지를 함께 프로비저닝하는 기능이다.

따라서 동적 프로비저닝을 사용하면 EBS와 같은 외부 스토리지를 직접 미리 생성할 필요가 없으며 PVC를 생성하면 외부 스토리지가 자동으로 생성되기 때문이다.

앞서 특정 PV를 선택하기 위해 스토리지 클래스를 사용했던 것처럼 동적 프로비저닝에서도 사용할 수 있다. 동적 프로비저닝은 스토리지 클래스의 정보를 참고해 외부 스토리지를 생성하기 때문이다.

동적 프로비저닝의 예시를 단계별로 알아보자.

ssd 라는 스토리지 클래스에는 SSD를 생성하라는 설정을, hdd라는 스토리지 클래스에는 HDD를 생성하라는 설정을 미리 정의했다고 가정한다.
PVC에 특정 스토리지 클래스를 명시한다. PVC의 AccessModes나 Capacity 등의 조건과 일치하는 PV가 존재하지 않는 상태이다.
조건에 일치하는 PV를 새롭게 만들기 위해 스토리지 클래스에 정의된 속성에 따라서 외부 스토리지를 생성한다. 만약, PVC 에 storageClassName: ssd 로 설정했고, ssd라는 이름의 스토리지 클래스가 SSD에 대한 설정 정보를 담고 있다면 SSD 스토리지가 동적으로 생성된다.
새롭게 생성된 외부 스토리지는 쿠버네티스의 PV로 등록되고 PVC와 바인딩된다.

동적 프로비저닝을 모든 쿠버네티스 클러스터에서 범용적으로 사용할 수 있는 것은 아니며 동적 프로비저닝 기능이 지원되는 스토리지 프로비저너가 미리 활성화 돼 있어야 한다. 사용 가능한 프로비저닝 목록은 공식 문서에서 확인이 가능하다.

만약, AWS나 GCP와 같은 클라우드 플랫폼에서 쿠버네티스를 사용하고 있다면 별도로 설정하지 않아도 자동으로 동적 프로비저닝을 사용할 수 있다.

AWS에서 동적 프로비저닝 사용

provisioner와 type을 봐야 한다. provisioner 항목에는 AWS의 쿠버네티스에서 사용할 수 있는 EBS 동적 프로비저너인 kubernetes.io/aws-ebs를 설정했다. type 항목은 EBS가 어떤 종류인지 나타내는 것으로, st1과 gp2, sc1, io1 등을 사용할 수 있다.

PVC에 storageClassName 항목을 정의하지 않았을 때, 쿠버네티스에서 기본적으로 사용하도록 설정된 스토리지 클래스가 있다면 해당 스토리지 클래스를 통해 동적 프로비저닝이 수행된다. 따라서 동적 프로비저닝을 아예 사용하지 않을 것이라면 storageClassName: “” 으로 설정한다.

동적 프로비저닝을 사용할 때 주의해야 할 점은 PV의 리클레임 정책이 자동으로 Delete로 설정된다는 점이다. 동적으로 생성되는 PV의 리클레임 정책 속성은 스토리지 클래스에 설정된 reclaimPolicy 항목을 상속받는데, 스토리지 클래스의 reclaimPolicy는 기본적으로 Delete 이기 때문이다.

동적 프로비저닝에서 특정 스토리지 클래스를 기본값으로 사용

스토리지 클래스를 생성할 때, 아래와 같은 annotation 을 추가하면 이 스토리지 클래스를 기본값으로 사용한다.

$ kubectl get storageclass
NAME               PROVISIONER             AGE
HDD                kubernetes.io/aws-ebs   3m27s
generic(default)   kubernetes.io/aws-ebs   1s 
SSD                kubernetes.io/aws-ebs   3m42s

[kubernetes] Ingress, Nginx Ingress Controller

ssunw — Tue, 26 Jul 2022 21:43:04 +0900

인그레스(Ingress)

인그레스(Ingress)는 일반적으로 외부에서 내부로 향하는 것을 지칭하는 단어이다. 예를 들어 인그레스 트래픽은 외부에서 서버로 유입되는 트래픽을 의미하며, 인그레스 네트워크는 인그레스 트래픽을 처리하기 위한 네트워크를 의미한다.

서비스 오브젝트가 외부 요청을 받아들이기 위한 것이었다면 ‘인그레스'는 외부 요청을 어떻게 처리할 것인지 네트워크 7계층 레벨에서 정의하는 쿠버네티스 오브젝트이다.

여기서 ‘처리한다'라는 문장에는 많은 기능이 내포돼 있는데 인그레스 오브젝트가 담당할 수 있는 기본적인 기능만 간단히 나열해보면 다음과 같다.

외부 요청의 라우팅: /apple, /apple/red 등과 같이 특정 경로로 들어온 요청을 어떠한 서비스로 전달할지 정의하는 라우팅 규칙을 설정할 수 있다.
가상 호스트 기반의 요청 처리: 같은 IP에 대해 다른 도메인 이름으로 요청이 도착했을 때, 어떻게 처리할 것인지 정의할 수 있다.
SSL/TLS 보안 연결 처리: 여러 개의 서비스로 요청을 라우팅할 때, 보안 연결을 위한 인증서를 쉽게 적용할 수 있다.

인그레스의 기능은 위 기능에만 제한되는 것이 아니며, 인그레스를 어떻게 사용하냐(ALB 를 인그레스로 사용하는 등..)에 따라 다양한 기능을 사용할 수 있다.

인그레스 자체의 기능은 비교적 정해져 있어도 인그레스의 요청을 처리할 서버로 무엇을 선택하느냐에 따라 기능이 조금씩 달라지기 때문이다.

인그레스를 사용하는 이유

서비스에서 사용할 수 있는 NodePort나 LoadBalancer 타입의 서비스를 사용해도 위 기능들을 구현하는 것이 불가능하지는 않기 때문에 인그레스를 왜 사용해야 하는지 알아야 할 필요가 있다.

내 애플리케이션이 3개의 디플로이먼트로 생성돼 있다고 가정해 볼 때 각각의 디플로이먼트를 외부에 노출해야 한다면 NodePort 또는 LoadBalancer 타입의 서비스 3개를 생성하는 방법을 먼저 떠올릴 것이다. 각 디플로이먼트에 대응하는 서비스를 하나씩 연결해 준 셈이다.

이런 방식은 잘 작동하는 것 같지만, 서비스마다 세부적인 설정을 할 때 추가적인 복잡성이 발생하게 된다. SSL/TLS 보안 연결, 접근 도메인 및 클라이언트 상태에 기반한 라우팅 등을 구현하려면 각 서비스와 디플로이먼트에 대해 일일이 설정을 해야 하기 때문이다.

이런 경우 쿠버네티스가 제공하는 인그레스 오브젝트를 사용하면 URL 엔드포인트를 단 하나만 생성함으로써 이러한 번거로움을 쉽게 해결할 수 있다.

3개의 디플로이먼트를 외부로 노출하는 인그레스를 생성하면 3개의 서비스에 대해 3개의 URL이 각각 존재하는 것이 아닌 인그레스에 접근하기 위한 하나의 URL만 존재한다. 따라서 클라이언트는 인그레스의 URL로만 접근하게 되며, 해당 요청은 인그레스에서 정의한 규칙에 따라 처리된 뒤 적절한 디플로이먼트의 파드로 전달된다.

쉽게 AWS ELB로 풀어 설명하자면 클라이언트는 하나의 ALB에 접근을 하게 되고 ALB가 3개의 NLB로 부하 분산을 시켜 주는 것이다. 여기서 ALB는 인그레스가 NLB는 서비스 오브젝트가 된다.

인그레스 구조

[1] host: 해당 도메인 이름으로 접근하는 요청에 대해서 처리 규칙을 적용한다. 위 예시에서는 theotters.net 이라는 도메인으로 접근하는 요청만 처리하지만 여러 개의 host를 정의해 사용할 수도 있다.

[2] path: 해당 경로에 들어온 요청을 어느 서비스로 전달할 것인지 정의한다. 위 예시에서는 /login 이라는 경로의 요청을 backend에 정의된 서비스로 전달한다. 여러 개의 path를 정의해 경로를 처리할 수도 있다.

[3] serviceName, servicePort: path로 들어온 요청이 전달될 서비스와 포트이다.

실제 이 파일을 만들고 kubectl apply -f ingress-example.yaml 이라는 이름의 인그레스를 생성해도 이것만으로는 아무 일도 일어나지 않는다.

인그레스는 단지 요청을 처리하는 규칙을 정의하는 선언적인 오브젝트일 뿐, 외부 요청을 받아들일 수 있는 실제 서버가 아니기 때문이다. 인그레스는 인그레스 컨트롤러(Ingress Controller)라고 하는 특수한 서버에 적용해야만 그 규칙을 사용할 수 있다.

즉, 실제로 외부의 요청을 받아들이는 것은 인그레스 컨트롤러 서버이며, 이 서버가 인그레스 규칙을 로드해 사용한다.

인그레스 컨트롤러 ——————> 인그레스 규칙 적용 ——————> 서비스

따라서 쿠버네티스의 인그레스는 반드시 인그레스 컨트롤러라는 서버와 함께 사용해야 한다. 인그레스 컨트롤러 서버는 여러 종류가 있으며 필요에 따라 하나를 골라서 사용하면 되고 대표적으로 쿠버네티스에서 가장 많이 사용하는 Nginx 웹 서버 인그레스 컨트롤러가 있다.

Nginx 인그레스 컨트롤러는 쿠버네티스에서 공식적으로 개발되고 있기 때문에 설치를 위한 YAML 파일을 공식 깃허브 저장소에서 내려받을 수 있다. 그래서 명령어를 통해 Nginx 인그레스 컨트롤러와 관련된 모든 리소스를 한 번에 설치할 수 있다.(https://kubernetes.github.io/ingress-nginx/deploy/)

kubectl apply -f <https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.3.0/deploy/static/provider/cloud/deploy.yaml>

Nginx 인그레스 컨트롤러를 설치하면 자동으로 생성되는 서비스는 LoadBalancer 타입이다. 실제 운영 환경일 경우 LoadBalancer 타입에 DNS 이름을 할당함으로써 Nginx 인그레스 컨트롤러에 접근하는 것이 일반적이다.

가상 머신처럼 클라우드가 아닌 환경에서 인그레스를 테스트

가상 머신처럼 클라우드가 아닌 환경에서 인그레스를 테스트하고 싶다면 LoadBalancer 대신 NodePort 타입의 서비스를 생성해 사용해도 된다. 이 경우에는 각 노드의 랜덤한 포트로 Nginx 인그레스 컨트롤러에 접근할 수 있다.

혹은 온프레미스에서의 운영 단계를 계획하고 있다면 MetalLB나 오픈스택의 로드 밸런서를 사용할 수도 있다.

인그레스 컨트롤러에 의해 요청이 최종적으로 도착할 디플로이먼트의 서비스는 어떤 타입이든지 상관은 없다. 다만 외부에 서비스를 노출할 필요가 없다면 ClusterIP 타입을 사용하는 것이 좋다.

인그레스의 기능을 하나씩 사용해보기 위해 YAML 파일에 host, path 항목 등을 모두 명시했지만, 이는 반드시 정의할 필요는 없으며 인그레스 항목을 최소한으로 하여 설정으로 생성이 가능하다.

nginx 인그레스를 사용하는 방법을 순서대로 정리해보면

공식 깃허브에서 제공되는 YAML 파일로 Nginx 인그레스 컨트롤러를 생성한다.
Nginx 인그레스 컨트롤러를 외부로 노출하기 위한 서비스를 생성한다.
요청 처리 규칙을 정의하는 인그레스 오브젝트를 생성한다.
Nginx 인그레스 컨트롤러로 들어온 요청은 인그레스 규칙에 따라 적절한 서비스로 전달된다.

위 과정 중 3번에서 인그레스를 생성하면 인그레스 컨트롤러는 자동으로 인그레스를 로드해 Nginx 웹 서버에 적용한다. 이를 위해 Nginx 인그레스 컨트롤러는 항상 인그레스 리소스의 상태를 지켜보고 있으며, 기본적으로 모든 네임스페이스의 인그레스 리소스를 읽어와 규칙을 적용한다.

특정 경로와 호스트 이름으로 들어온 요청은 인그레스에 정의된 규칙에 따라 서비스로 전달된다.

요청이 실제로 서비스로 전달되는 것은 아니며, Nginx 인그레스 컨트롤러는 서비스에 의해 생성된 엔드포인트로 요청을 직접 전달한다. 즉 서비스의 ClusterIP 가 아닌 엔드포인트의 실제 종착 지점들로 요청이 전달되는 셈이다.

어노테이션을 이용한 설정

kubernetes.io/ingress.class 는 해당 인그레스 규칙을 어떤 인그레스 컨트롤러에 적용할 것인지를 의미한다. 인그레스 컨트롤러로는 Nginx 말고도 Kong이나 GKE 등 여러 가지 중 하나를 선택해 사용할 수 있다.

쿠버네티스 클러스터 자체에서 기본적으로 사용하도록 설정된 인그레스 컨트롤러가 존재하는 경우가 있는데, 이 경우에는 어떤 인그레스 컨트롤러를 사용할 것인지 반드시 인그레스에 명시해주는 것이 좋다.

예를 들어 GKE에서 쿠버네티스를 사용하고 있다면 GKE에서 제공하는 인그레스 컨트롤러를 기본적으로 사용하도록 설정돼 있다. 따라서 GKE에서 인그레스를 생성할 때 만약 annotation 항목에서 kubernetes.io/ingress.classs 를 사용하지 않으면 GKE의 인그레스 컨트롤러를 자동으로 생성해 사용하게 된다.

따라서 GKE 나 다른 클라우드 서비스에서 Nginx 인그레스 컨트롤러를 사용하고 싶다면 반드시 kubernetes.io/ingress.class 를 nginx로 설정해야 한다.

nginx.ingress.kubernetes.io/rewrite-target 이라는 주석은 Nginx 인그레스 컨트롤러에서만 사용할 수 있는 기능이다. 이 주석은 인그레스에 정의된 경로로 들어오는 모든 요청을 rewrite-target에 설정된 경로로 전달한다.

예를 들어, Nginx 인그레스 컨트롤러로 /login 으로 접근하면 서비스에는 / 경로로 전달된다. /login 으로 시작하는 모든 요청을 서비스의 / 로 전달한다. 옳은 URL 은 아니지만 /login/success/good 라는 경로로 요청을 보내도 똑같이 / 로 전달된다.

이 외에도 루트 경로로 접근했을 때 특정 path 로 리다이렉트하는 app-root 주석이나 SSL 리다이렉트를 위한 ssl-redirect 주석 등을 사용할 수 있다. Nginx 인그레스 컨트롤러에서 사용할 수 있는 주석은 공식 사이트에서 확인 가능하다.

단, 이런 주석들은 Nginx 인그레스 컨트롤러에서만 사용할 수 있으며, 다른 인그레스 컨트롤러 서버를 사용한다면 해당 인그레스 컨트롤러의 공식 문서를 참고해 적절한 방법으로 기능을 사용해야 한다.

Nginx 인그레스 컨트롤러에 SSL/TLS 보안 연결 적용

인그레스의 장점 중 하나는 쿠버네티스의 뒤쪽에 있는 디플로이먼트와 서비스가 아닌 앞쪽에 있는 인그레스 컨트롤러에서 편리하게 SSL/TLS 보안 연결을 설정할 수 있다는 것이다.

즉, 인그레스 컨트롤러 지점에서 인증서를 적용해 두면 요청이 전달되는 애플리케이션에 대해 모두 인증서 처리를 할 수 있다. 따라서 인그레스 컨트롤러가 보안 연결을 수립하기 위한 일종의 관문(Gateway) 역할을 한다고도 볼 수 있다.

AWS와 같은 클라우드 환경에서 LoadBalancer 타입의 서비스를 사용할 계획이라면 클라우드 플랫폼 자체에서 관리해주는 인증서를 인그레스 컨트롤러에 적용할 수도 있다. 예를 들어 AWS의 ACM을 LoadBalancer 타입의 서비스에 제공하는 방식.

Nginx 인그레스 컨트롤러 또한 인증서를 통한 보안 연결 기능을 제공하기 때문에 어렵지 않게 보안 연결을 설정할 수 있다. 가장 먼저 보안 연결에 사용할 인증서와 비밀키를 생성하자.

openssl req -x509 -nodes -days 365 -newkey rsa:2048
-keyout tls.key -out tls.crt -subj "/CN=dev.theotters.net/0=dev"

/CN 에는 Nginx 인그레스 컨트롤러에 접근하기 위한 Public DNS 이름을 입력해야 한다. 위 예시에서 Nginx 인그레스 컨트롤러와 연결된 서비스에 dev.theotters.net 이라는 도메인으로 접근한다고 가정한 것이며, 인증서 생성 옵션은 환경에 맞게 적절히 변경해 사용해야 한다.

예를 들어, AWS에서 생성되어 동적인 도메인 이름을 할당받은 클래식 로드 밸런서라면 /CN=*.ap-northeast-2.elb.amazonaws.com 처럼 사용하는 것도 가능하다.

$ ls
tls.crt tls.key ...

$ kubectl create secret tls tls-secret --key tls.key --cert tls.crt

tls 항목이 추가되었고 spec.tls.hosts 항목에서는 보안 연결을 적용할 도메인 이름을, spec.tls.secretName 은 앞서 생성했던 tls 타입의 시크릿 이름을 입력했다. 이는 dev.theotters.net 이라는 도메인 이름으로 접근하는 요청에 대해 tls-secret 시크릿의 인증서로 보안 연결을 수립하겠다는 뜻이다.

[kubernetes] Configmap, Secret

ssunw — Tue, 26 Jul 2022 20:34:07 +0900

컨피그맵(Configmap), 시크릿(Secret): 설정값을 파드에 전달

설정값이나 설정 파일을 내 애플리케이션에 전달하는 가장 확실한 방법은 도커 이미지 내부에 설정값 또는 설정 파일을 정적으로 저장해 놓는 것이다. 하지만 도커 이미지는 일단 빌드되고 나면 불변의 상태를 가지기 때문에 이 방법은 상황에 따라 설정 옵션을 유연하게 변경할 수 없다는 단점이 있다.

이에 대한 대안으로 파드를 정의하는 YAML 파일에 환경 변수를 직접 적어 놓는 하드 코딩 방식을 사용할 수도 있다.

위처럼 환경 변수를 파드 템플릿에 직접 명시하는 방식도 나쁘지는 않지만, 상황에 따라서는 환경 변수의 값만 다른, 동일한 여러 개의 YAML 파일이 존재할 수도 있다. 즉, 운영 환경과 개발 환경이 다른 경우에 각각 디플로이먼트를 생성해야 한다면 환경 변수가 서로 다르게 설정된 두 가지 버전의 YAML 파일이 따로 존재해야 하기 때문이다.

쿠버네티스는 YAML 파일과 설정값을 분리할 수 있는 컨피그맵과 시크릿이라는 오브젝트를 제공한다. 컨피그맵에는 설정값을 시크릿에는 노출되서는 안되는 비밀값을 저장할 수 있다.

kubectl create configmap <컨피그맵 이름> <각종 설정값들>
kubectl create cm log-level-configmap --from-literal LOG_LEVEL=DEBUG

--from-literal 옵션을 여러 번 사용함으로써 여러 개의 키-값을 컨피그맵에서 사용하도록 설정할 수도 있다.

kubectl create cm start-k8s --from-literal k8s=kubernetes --from-literal container=docker

컨피그맵에 저장된 설정값은 kubectl describe configmap 명령어나 kubectl get configmap -o yaml 명령어로 확인할 수 있다.

컨피그맵을 파드에서 사용하는 방법은 크게 두 가지가 있다. 내 애플리케이션이 소스코드 내부에서 어떻게 설정값을 읽는지에 따라 적절한 방법을 선택해야 한다.

컨피그맵의 값을 컨테이너의 환경 변수로 사용
컨피그맵의 값을 파드의 컨테이너 환경 변수로 가져온다. 컨피그맵에 저장된 키-값 데이터가 컨테이너 환경 변수의 키-값으로서 그대로 사용되기 때문에 echo $LOG_LEVEL과 같은 방식으로도 값을 확인할 수 있다. 내 앱이 시스템 환경 변수로부터 설정값을 가져온다면 이 방법을 사용하는 것이 좋다.
컨피그맵의 값을 파드 내부의 파일로 마운트해 사용
컨피그맵의 값을 파드 컨테이너 내부의 특정 파일로 마운트한다. 예를 들어 LOG_LEVEL=INFO 라는 값을 가지는 컨피그맵을 /etc/config/log_level 이라는 파일로 마운트하면 log_level 파일에는 INFO 라는 값이 저장된다. 이때 파일이 위치할 경로는 별도로 설정할 수 있다. 내 앱이 nginx.conf, .env 등의 파일을 통해 설정값을 읽어 들인다면 이 방법을 사용하는 것이 좋다.

컨피그맵의 데이터를 컨테이너의 환경 변수로 가져오기

생성한 컨피그맵을 불러와서 환경 변수를 설정하는 방식이다.

envFrom 항목은 하나의 컨피그맵에 여러 개의 키-값 쌍이 존재하더라도 모두 환경 변수로 가져오도록 설정한다. 따라서 start-k8s 컨피그맵에서 2개의 키-값 데이터가 한꺼번에 포드의 환경 변수로 등록된다. 즉 총 3개의 키-값 쌍을 파드로 넘긴 것이다.

valueFrom과 configMapKeyRef 를 사용하면 여러 개의 키-값 쌍이 들어 있는 컨피그맵에서 특정 데이터만을 선택해 환경 변수로 가져올 수도 있다.

$ kubectl exec continer-selective-env-example env | grep ENV
ENV_KEYNAME_2=kubernetes
ENV_KEYNAME_1=DEBUG

envFrom: 컨피그맵에 존재하는 모든 키-값 쌍을 가져온다.
valueFrom: 컨피그맵에 존재하는 키-값 쌍 중에서 원하는 데이터만 선택적으로 가져온다.

컨피그맵의 내용을 파일로 파드 내부에 마운트하기

내 앱이 nginx.conf, mysql.conf, .env 등과 같은 특정 파일로부터 설정값을 읽어온다면 컨피그맵의 데이터를 파드 내부의 파일로 마운트해 사용할 수 있다. 예를 들어 아래 YAML 파일은 start-k8s 컨피그맵에 존재하는 모든 키-값 쌍을 /etc/config 디렉토리에 위치시킨다.

spec.volumes: YAML 파일에서 사용할 볼륨의 목록을 정의한다. 위 예시에서는 start-k8s 라는 이름의 컨피그맵을 통해 configmap-volume 볼륨을 정의했다.
spec.containers.volumeMounts: volumes 항목에서 정의된 볼륨을 컨테이너 내부의 어떤 디렉토리에 마운트할 것인지 명시한다. 위 예시에서는 /etc/config 디렉토리에 컨피그맵의 값이 담긴 파일이 마운트될 것이다.

$ kubectl exec configmap-volume-pod ls /etc/config
container
k8s

$ kubectl exec configmap-volume-pod ls /etc/config/k8s
kubernetes

컨피그맵에 저장돼 있던 두 개의 키-쌍 데이터, 즉, container와 k8s라는 키 이름이 파일로 존재하고 있다. 여기서 알아둬야 할 것은 컨피그맵의 모든 키-값 쌍 데이터가 마운트 됐으며, 파일 이름은 키의 이름과 같다는 것이다.

컨피그맵과 같은 쿠버네티스 리소스의 데이터를 파드 내부 디렉토리에 위치시키는 것을 쿠버네티스 공식 문서에서는 투사(Projection)라고 표현한다.

키-쌍 데이터를 파드에 마운트하는 것이 아닌, 원하는 키-쌍 데이터만 선택해서 파드에 파일로 가져올 수도 있다.

items 항목: 컨피그맵에서 가져올 키-값의 목록을 의미하며, k8s라는 키만 가져오도록 명시했다.
path 항목: 최종적으로 디렉토리에 위치할 파일의 이름을 입력하는 항목으로 k8s_fullname 이라는 값을 입력했다.

즉, /etc/config/k8s_fullname 경로에 파일이 위치하게 된다.

$ kubectl exec selective-cm-volume-pod ls /etc/config
k8s_fullname

$ kubectl exec selective-cm-volume-pod ls /etc/config/k8s_fullname
kubernetes

파일로부터 컨피그맵 생성

컨피그맵을 볼륨으로 포드에 제공할 때는 대부분 설정 파일 그 자체를 컨피그맵으로 사용하는 경우가 많다. 예를 들어, Nginx의 설정 파일인 nginx.conf 또는 MySQL의 설정 파일인 mysql.conf의 내용을 아예 통째로 컨피그맵에 저장한 뒤 이를 볼륨 파일로 포드 내부에 제공하면 좀 더 효율적인 설정 관리가 가능할 것이다. 이러한 경우를 위해 쿠버네티스는 컨피그맵을 파일로부터 생성하는 기능 또한 제공한다.

--from-file 옵션을 사용하면 파일로부터 컨피그맵을 생성할 수 있다. --from-file 옵션을 여러 번 사용해 여러 개의 파일을 컨피그맵에 저장할 수도 있다.

$ kubectl create configmap <컨피그맵 이름> --from-file <파일 이름>
$ echo hello, world >> index.html
$ kubectl create configmap index-file --from-file index.html
configmap/index-file created

--from-file 옵션에서 별도의 키를 지정하지 않으면 파일 이름이 키로, 파일의 내용이 값으로 저장된다. 위의 예시에서는 index.html 이라는 파일로 컨피그맵을 생성했기 때문에 index.html 이라는 키에 hello, world 라는 값이 설정됐다.

YAML 파일로 컨피그맵 정의하기

컨피그맵은 YAML 파일을 사용해서 오브젝트를 생성할 수 있다.

컨피그맵 ⇒ 환경변수로 줄 수도, 파드에 마운트시켜서 컨피그맵 내부의 값을 주거나, 파일을 컨피그맵으로 만들어서 볼륨 마운트시켜 파드에 넘겨줄 수도 있다.

시크릿 사용 방법 익히기

시크릿은 SSH 키, 비밀번호 등과 같이 민감한 정보를 저장하기 위한 용도로 사용되며, 네임스페이스에 종속되는 쿠버네티스 오브젝트이다. 시크릿과 컨피그맵은 사용 방법이 매우 비슷하다.

시크릿은 민감한 정보를 저장하기 위해 컨피그맵보다 좀 더 세분화 된 사용법을 제공한다.

다음 명령어는 my-password 라는 이름의 시크릿을 생성하며, password=1q2w3e4r 이라는 키-값 쌍을 저장한다.

$ kubectl create secret generic my-password --from-literal password=1q2w3e4r

또한, 컨피그맵처럼 --from-literal 대신 --from-file 이나 --from-env-file 옵션을 이용해 파일로부터 값을 읽어와 사용해도 된다.

$ echo mypassword > pw1 && echo yourpassword > pw2
$ kubectl create secret generic our-password --from-file pw1 --from-file pw2

시크릿은 컨피그맵과 달리 데이터의 사용 목적에 따라 몇 가지 종류로 나뉘기 때문에 generic 과 같은 특수 옵션에 대해 알아야 한다.

kubectl describe secret 으로 방금 생성한 시크릿을 확인하면 키-값 쌍 에서 값 부분이 이상한 값으로 변형돼 표기되는 것을 볼 수 있고, 이는 시크릿에 값을 저장할 때 쿠버네티스가 기본적으로 base64로 값을 인코딩하기 때문이다.

따라서 YAML 파일로부터 시크릿을 생성할 때도 데이터의 값에 base64로 인코딩 된 문자열을 사용해야 한다.

시크릿의 키-값 데이터를 파드의 환경 변수로 설정할 수도 있고, 특정 경로의 파일로 파드 내에 마운트할 수도 있다.

아래 예시를 확인하자.

또는 시크릿의 키-값 데이터를 파일로 파드의 볼륨에 마운트할 수도 있으며, 여러 개의 키-값 쌍이 존재하는 시크릿에서 선택적으로 사용할 수도 있다.

이미지 레지스트리 접근을 위한 docker-registry 타입의 시크릿 사용

시크릿은 컨피그맵처럼 단순 문자열이나 설정 파일 등을 저장할 때 사용할 수도 있지만 사용 목적에 따라 여러 종류의 시크릿을 사용할 수도 있다.

시크릿의 기본 타입은 Opaque 로 설정돼 있고, Opaque 타입은 별도로 시크릿의 종류를 명시하지 않으면 자동으로 설정되는 타입이며, 사용자가 정의하는 데이터를 저장할 수 있는 일반적인 목적의 시크릿이다.

kubectl create 명령어로 시크릿을 생성할 때 generic 이라고 명시했던 것이 바로 Opaque 타입에 해당하는 종류이다.

사설 레지스트리에 접근하기 위해서는 cli 상에서 로그인이 필요로 한데 도커의 경우 docker login 을 사용하여 사설 레지스트리에 인증한다.

쿠버네티스에서는 docker login 명령어 대신 레지스트리의 인증 정보를 저장하는 별도의 시크릿을 생성해 사용한다. 레지스트리 인증을 위해 시크릿을 생성하는 방법은 두 가지가 있다.

첫번째는 docker login 명령어로 로그인에 성공했을 때 도커 엔진이 자동으로 생성하는 ~/.docker/config.json 파일을 사용하는 것이다. config.json 파일에는 인증을 위한 정보가 담겨 있기 때문에 이를 그대로 시크릿으로 가져오면 된다.

$ kubectl create secret generic registry-auth \
--from-file=.dockerconfigjson=/root/.docker/config.json \
--type=kubernetes.io/dockerconfigjson

또는 시크릿을 생성하는 명령어에서 직접 로그인 인증 정보를 명시할 수도 있다. 각 옵션에 적절한 인자를 입력하면 되며, --docker-username과 --docker-password 옵션은 로그인 이름과 비밀번호를 입력하는 필수 옵션이다.

$ kubectl create secret docker-registry registry-auth-bt-cmd \
--docker-username=how0326 \
--docker-password=12345

--docker-server 는 필수 옵션이 아니며, 필요에 따라 사용하면 된다. --docker-server 옵션을 사용하지 않으면 기본적으로 도커 허브(docker.io)를 사용하도록 설정되지만, 다른 사설 레지스트리를 사용하려면 --docker-server 옵션에 해당 서버의 주소 또는 도메인 이름을 입력하면 된다.

$ kubectl create secret docker-registry registry-auth-bt-cmd \
--docker-username=how0326 \
--docker-password=12345 \
--docker-server=ecs.registry.com

위 명령어로 생성된 시크릿은 kubernetes.io/dockerconfigjson 이라는 타입으로 설정된다.

이 시크릿은 디플로이먼트 또는 포드 등에서 사설 레지스트리로부터 이미지를 받아올 때 사용할 수 있다. 예를 들어 도커 허브의 프라이빗 저장소에 저장된 이미지를 통해 파드를 생성하려면 다음과 같이 YAML 파일에서 imagePullSecret 항목을 정의한다.

기본적으로는 YAML 파일에 명시된 도커 이미지가 워커 서버에 존재하지 않을 때만 이미지를 받아오도록 설정돼 있지만, imagePullPolicy 항목을 통해 이미지를 받아오는 설정을 변경할 수 있다. imagePullPolicy의 자세한 사용 방법은 쿠버네티스 공식 문서를 참고할 수 있다.

TLS 키를 저장할 수 있는 tls 타입의 시크릿 사용

시크릿은 TLS 연결에 사용되는 공개키, 비밀키 등을 쿠버네티스에 자체적으로 저장할 수 있도록 tls 타입을 지원한다. 따라서 파드 내부의 애플리케이션이 보안 연결을 위해 인증서나 비밀키 등을 가져와야 할 때 시크릿의 값을 파드에 제공하는 방식으로 사용할 수 있다.

tls 타입의 시크릿을 사용하는 방법은 매우 간단하다. 보안 연결에 사용되는 키 페어가 미리 준비돼 있다면 kubectl create secret tls 명령어로 쉽게 생성할 수 있다.

$ openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 -subj "/CN=example.com" -keyout cert.key -out cert.crt

$ ls
cert.crt cert.key ...

$ kubectl create secret tls my-tls-secret --cert cert.crt --key cert.key
secret/my-tls-sercret created

생성된 시크릿의 정보를 확인해보면 cert.crt 와 cert.key 파일의 내용이 tls.crt 와 tls.key 라는 키로 저장돼 있음을 알 수 있다. 각 데이터는 모두 base64로 인코딩되어 저장된다.

좀 더 쉽게 컨피그맵과 시크릿 리소스 배포하기

CLI 상에서 시크릿을 만드는 것보다 YAML 을 통해 시크릿 오브젝트를 배포할 수 있다. 그러나 시크릿의 데이터가 많아질수록 YAML 파일에 직접 시크릿의 데이터를 저장하는 것은 바람직한 방법이 아니다.

이러한 단점을 해결하면서 시크릿이나 컨피그맵을 배포하기 위해 YAML 파일을 작성할 때, 데이터를 YAML 파일로부터 분리할 수 있는 kustomize 기능을 사용할 수 있다.

kustomize는 자주 사용되는 YAML 파일의 속성을 별도로 정의해 재사용하거나 여러 YAML 파일을 하나로 묶는 등 다양한 용도로 사용할 수 있는 기능이다. 그렇지만 지금은 시크릿과 컨피그맵을 좀 더 쉽게 쓰기 위한 용도로 kustomize를 간단하게 사용해보자.

kustomize 로부터 생성될 시크릿의 정보를 미리 확인하려면 kubectl kustomize 명령어를 사용한다.

kustomization.yaml 파일로부터 시크릿을 생성하려면 해당 파일이 위치한 디렉토리에서 kubectl apply -k ./ 명령어를 사용한다.

만약 컨피그맵을 kustomize 로부터 생성하고 싶다면 kustomization.yaml 파일에서 secretGenerator 대신 configmapGenerator 를 사용하면 된다. 컨피그맵은 시크릿과 달리 종류가 존재하지 않으므로 type 항목은 제거한다.

[kubernetes] Namespace

ssunw — Tue, 26 Jul 2022 20:33:19 +0900

Namespace: 리소스를 논리적으로 구분하는 장벽

쿠버네티스에서는 리소스를 논리적으로 구분하기 위해 네임스페이스라는 오브젝트를 제공한다. 간단히 생각해서 네임스페이스는 포드, 레플리카셋, 디플로이먼트, 서비스 등과 같은 리소스들이 묶여 있는 하나의 가상 공간 또는 그룹이라고 이해하면 된다.

예를 들어 모니터링을 위한 모든 리소스들은 monitoring 이라는 이름의 네임스페이스에서 생성할 수 있고, 테스트를 위한 리소스들은 testbed 라는 네임스페이스에서 생성할 수 있다.

또는, 여러 개발 조직이 하나의 쿠버네티스 클러스터를 공유해 사용해야 한다면 조직별로 네임스페이스를 사용하도록 구성할 수 있다. 이렇게 여러 개의 네임스페이스를 사용하면 마치 하나의 클러스터에서 여러 개의 가상 클러스터를 사용하는 것처럼 느껴질 것이다.

쿠버네티스를 설치하면 자동으로 default, kube-system 라는 네임스페이스가 생성되고 kubectl 명령어로 쿠버네티스 리소스를 사용할 때는 기본적으로 default 네임스페이스를 사용한다.

기본적으로 kube-system 네임스페이스는 쿠버네티스에 대한 충분한 이해 없이는 건드리지 않는 것이 좋다. 예상치 못하게 쿠버네티스 클러스터가 동작하지 않을 수도 있기 때문이다.

네임스페이스를 사용하는 경우는 대부분 모니터링, 로드 밸런싱 인그레스 등의 특정 목적을 위한 용도가 대부분이다. 각 네임스페이스의 리소스들은 논리적으로만 구분된 것일 뿐, 물리적으로 격리된 것이 아니기 때문에 서로 다른 네임스페이스에서 생성된 파드가 같은 노드에 존재할 수 있다.

Label vs NameSpace

네임스페이스와 라벨의 차이점이 궁금할 수 있다. 서비스와 파드를 매칭시키기 위해 사용하는 라벨 또한 리소스를 분류하고 구분하기 위한 방법 중 하나이기 때문이다.

네임스페이스는 라벨보다 더욱 넓은 용도로 사용될 수 있다. ResourceQuota 오브젝트를 이용해 특정 네임스페이스에서 생성되는 포드의 자원 사용량을 제한하거나, 애드미션 컨트롤러라는 기능을 이용해 특정 네임스페이스에 생성되는 파드에는 항상 사이드카 컨테이너를 붙이도록 설정할 수도 있다.

무엇보다 쿠버네티스의 사용 목적에 따라 파드, 서비스 등의 리소스를 격리함으로써 편리하게 구분할 수 있다는 특징도 있다.

네임스페이스에 종속되는 쿠버네티스 오브젝트와 독립적인 오브젝트

A라는 네임스페이스에서 파드를 만들면 A 네임스페이스에서만 보이고 B 네임스페이스에서는 보이지 않는다. 이런 경우를 쿠버네티스에서는 ‘오브젝트가 네임스페이스에 속한다'라고 표현한다.

대표적으로 네임스페이스 속하지 않는 쿠버네티스 오브젝트는 nodes이다. nodes는 쿠버네티스 클러스터에서 사용되는 저수준의 오브젝트이며, 네임스페이스에 의해 구분되지 않기 때문이다.

노드처럼 네임스페이스에 속하지 않는 오브젝트들은 보통 네임 스페이스에서 관리되지 않아야 하는 클러스터 전반에 걸쳐 사용되는 경우가 많다.

[kubernetes] Service

ssunw — Tue, 26 Jul 2022 20:32:49 +0900

Service: 포드를 연결하고 외부에 노출

다른 디플로이먼트의 포드들이 내부적으로 접근하려면 서비스라고 부르는 별도의 쿠버네티스 오브젝트를 생성해야 한다. 서비스는 포드에 접근하기 위한 규칙을 정의하기 때문에 쿠버네티스에서 애플리케이션을 배포하기 위해서는 반드시 알아야 할 오브젝트이다.

핵심 기능은 다음과 같다.

여러 개의 포드에 쉽게 접근할 수 있도록 고유한 도메인 이름을 부여한다.
여러 개의 포드에 접근할 때, 요청을 분산하는 로드 밸런서 기능을 한다.
클라우드 플랫폼의 로드 밸런서, 클러스터 노드의 포트 등을 통해 포드를 외부로 노출한다.

서비스의 종류

ClusterIP 타입: 쿠버네티스 내부에서만 포드들에 접근할 때 사용한다. 외부로 포드를 노출하지 않기 때문에 쿠버네티스 클러스터 내부에서만 사용되는 포드에 적합하다.
NodePort 타입: 포드에 접근할 수 있는 포트를 클러스터의 모든 노드에 동일하게 개방한다. 따라서 외부에서 포드에 접근할 수 있는 서비스 타입이다. 접근할 수 있는 포트는 랜덤으로 정해지지만, 특정 포트로 접근하도록 설정할 수도 있다.
LoadBalancer 타입: 클라우드 플랫폼에서 제공하는 로드 밸런서를 동적으로 프로비저닝해 포드에 연결한다. NodePort 타입과 마찬가지로 외부에서 포드에 접근할 수 있는 서비스 타입이다. 그렇지만 일반적으로 AWS, GCP 등과 같은 클라우드 플랫폼 환경에서만 사용할 수 있다. nginx 를 사용하여 로드 밸런서 역할을 하게 할 수 있다.

ClusterIP 타입의 서비스 - 쿠버네티스 내부에서만 포드에 접근하기

spec.selector: 이 서비스에서 어떠한 라벨을 가지는 포드에 접근할 수 있게 만들 것인지 결정한다.

spec.ports.port: 서비스는 쿠버네티스 내부에서만 사용할 수 있는 고유한 IP를 할당받는다. 이 때 port 항목에는 서비스의 IP에 접근할 때 사용할 포트를 설정하게 된다.

spec.ports.targetPort: 은 selector 항목에서 정의한 라벨에 의해 접근 대상이 된 포드들이 내부적으로 사용하고 있는 포트를 입력한다. 즉, 포드 템플릿에 정의된 containerPort 와 같은 값으로 설정해야 한다.

ClusterIP 타입의 서비스 IP와 포트를 통해 파드에 접근을 할 수 있고 서비스와 연결된 여러 개의 포드에 자동으로 요청이 분산된다. 서비스를 생성할 때 별도의 설정을 하지 않아도 서비스는 연결된 파드에 대해 로드 밸런싱을 수행한다.

서비스에는 IP뿐만 아니라 서비스 이름 그 자체로도 접근할 수 있다. 쿠버네티스는 애플리케이션이 서비스나 파드를 쉽게 찾을 수 있도록 내부 DNS를 구동하고 있고 파드들은 자동으로 이 DNS를 사용하도록 설정되기 때문이다.

실제로 여러 파드가 클러스터 내부에서 서로를 찾아 연결해야 할 때는 서비스의 이름과 같은 도메인 이름을 사용하는 것이 일반적이다. 즉, 파드가 서로 상호 작용할 때는 파드의 IP를 알 필요 없고 파드와 연결된 서비스 이름을 사용함으로써 간단하게 파드에 접근할 수 있다.

서비스의 라벨 셀렉터와 파드의 라벨이 매칭돼 연결되면 쿠버네티스는 자동으로 엔드포인트라고 부르는 오브젝트를 별도로 생성한다. 예를 들어, 서비스와 관련된 엔드포인트는 서비스와 동일한 이름으로 존재한다.

엔드 포인트라는 이름이 의미하는 것처럼 엔드포인트 오브젝트는 서비스가 가리키고 있는 도착점을 나타낸다. 서비스를 이용해 파드를 연결한다면 엔드포인트는 자동으로 생성되므로 엔드포인트를 지나치게 알 필요는 없지만, 엔드포인트 자체도 독립된 쿠버네티스의 리소스이기 때문에 이론상으로 서비스와 엔드포인트를 따로 따로 만들 수도 있다.

NodePort 타입의 서비스 - 서비스를 이용해 포드를 외부에 노출하기

NodePort 타입의 서비스는 클러스터 외부에서도 접근을 할 수 있다. NodePort 타입의 서비스는 모든 노드의 특정 포트를 개방해 서비스에 접근하는 방식이다. 도커에서 컨테이너를 외부로 노출하는 방식과 비슷하다고 생각하면 된다.

각 노드에서 개방되는 포트는 기본적으로 30000~32768 포트 주에 랜덤으로 선택되지만 YAML 파일에 nodePort 항목을 정의하면 원하는 포트를 선택할 수 있다.

NodePort 타입의 서비스는 ClusterIP의 기능을 포함하고 있다. NodePort 타입의 서비스는 내부 네트워크와 외부 네트워크 양쪽에서 접근을 할 수 있다.

기본적으로 NodePort 가 사용할 수 있는 포트 범위는 30000~32768 이지만 API 서버 컴포넌트의 실행 옵션을 변경하면 원하는 포트 범위를 설정할 수 있다. 포트 범위를 직접 지정하려면 API 서버의 옵션을 다음과 같이 추가하거나 수정한다.

--service-node-port-range=30000-35000

너무 낮은 포트 번호는 시스템의 의해 예약된 포트일 수 있기 때문에 30000번 이상부터 사용하는 것이 좋다.

실제 운영 환경에서 NodePort로 서비스를 외부에 제공하는 경우는 많지 않다. NodePort에서 포트 번호를 80 이나 443으로 설정하기에는 적절하지 않으며, SSL 인증서 적용, 라우팅 등과 같은 복잡한 설정을 서비스에 적용하기가 어렵기 때문이다.

따라서 NodePort 의 경우는 이 자체를 통해 서비스를 외부로 제공하기보다는 인그레스(Ingress)라고 부르는 쿠버네티스의 오브젝트에서 간접적으로 사용되는 경우가 많다.

LoadBalancer 타입의 서비스 - 클라우드 플랫폼의 로드 밸런서와 연동

로드 밸런서 타입의 서비스는 서비스 생성과 동시에 로드 밸런서를 새롭게 생성해 포드와 연결한다. 로드 밸런서 타입의 서비스는 클라우드 플랫폼으로부터 도메인 이름과 IP를 할당받기 때문에 NodePort 보다 더욱 쉽게 파드에 접근할 수 있다.

로드밸런서 타입의 서비스는 로드 밸런서를 동적으로 생성하는 기능을 제공하는 환경에서만 사용할 수 있다는 점을 알아야 한다. 일반적인 가상 머신이나, 온프레미스 환경에서는 사용하기 어려울 수 있지만 MetalLB 를 사용하여 온프레미스 환경에서도 돌릴 수 있기는 하다.

로드 밸런서 타입의 서비스 또한 NodePort나 ClusterIP와 동일하게 서비스의 IP(CLUSTER-IP)가 할당되며, 파드에서는 서비스의 IP 또는 서비스의 이름으로 서비스에 접근할 수 있다. 눈여겨 볼 부분은 EXTERNER-IP 항목이다. 이 주소는 클라우드 플랫폼인 AWS, GCP 등으로부터 자동으로 할당된 것이며, 이 주소와 서비스의 포트를 통해 포드에 접근할 수 있다.

다른 서비스 타입과 마찬가지로 요청이 여러 개의 파드로 분산되는 로드 밸런싱 기능을 자동으로 사용할 수 있다. 또한 각 노드에서 동일하게 접근할 수 있는 PORT(S) 가 부여되어 NodePort 의 간접적인 기능 또한 자동으로 사용할 수 있다.

만약 NLB나 ALB를 설정하고 싶다면 metadata.annotations 항목을 수정해주면 된다. 자세한 것은 AWS 공식 문서에 잘 나와 있다.

쿠버네티스에서 annotations는 라벨처럼 해당 리소스의 추가적인 정보를 나타내기 위한 키-값 쌍으로 이뤄져 있다. 그렇지만 리소스의 종류에 따라 특정 용도로 사용할 수 있게 쿠버네티스에 미리 정의된 몇 가지 주석이 있다. 이 주석들은 리소스에 특별한 설정값을 부여하기 위해 사용된다. 미리 정의된 주석은 라벨과 함께 익숙해지는 것이 좋다.

LoadBalancer 타입의 서비스 - 온프레미스 환경에서 LoadBalancer 타입의 서비스 사용하기

로드 밸런서 타입의 서비스는 일반적으로 AWS와 같은 클라우드 플랫폼에서 사용되지만, 필요하다면 직접 보유하고 있는 온프레미스 환경에서도 MetalLB 나 오픈 스택과 같은 특수한 환경을 직접 구축하여 사용할 수 있다.

그 중에서도 MetalLB 라는 서드파티 제품을 사용하면 로드 밸런서 타입의 서비스를 사용할 수 있다.

요청을 외부로 리다이렉트하는 서비스: ExternalName

쿠버네티스를 외부 시스템과 연동해야 할 때는 ExternalName 타입의 서비스를 사용할 수도 있다.

ExternalName 타입을 사용해 서비스를 생성하면 서비스가 외부 도메인을 가리키도록 설정할 수 있다. 예를 들어 쿠버네티스 내부의 파드들이 externalname-svc 라는 이름으로 요청을 보낼 경우, 쿠버네티스의 DNS 는 my.database.com으로 접근할 수 있도록 CNAME 레코드를 반환한다. 즉, externalname-svc로 요청을 보내면 my.database.com에 접근하게 된다.

ExternalName 타입의 서비스는 쿠버네티스와 별개로 존재하는 레거시 시스템에 연동해야 하는 상황에 유용하게 사용할 수 있다.

[kubernetes] POD, ReplicaSet, Deployment

ssunw — Tue, 26 Jul 2022 20:32:18 +0900

POD vs Container

파드는 같은 리눅스 네임스페이스를 공유하는 여러 컨테이너들을 추상호된 집합으로 사용하기 위해서 사용한다.

포드 내의 컨테이너들이 네트워크 네임스페이스 등과 같은 리눅스 네임스페이스를 공유해 사용하기 때문이다.

즉, 도커에서 컨테이너들끼리 네트워크 네임 스페이스를 공유하여 동일한 네트워크 환경을 사용한 것 처럼 POD 내부의 컨테이너들도 같은 리눅스 네임스페이스를 공유해 사용한다.

완전한 앱으로써의 POD

하나의 포드는 하나의 완전환 애플리케이션이다. 만약 하나의 애플리케이션에 로그를 수집하는 기능이나, 변경사항을 갱신해야 하는 경우 포드의 주 컨테이너와 기능 확장을 위한 추가 컨테이너를 함께 포드에 포함시킬 수 있다.

이렇게 포드에 정의된 부가적인 컨테이너를 사이드카 컨테이너라고 부르며 사이드카 컨테이너는 포드 내의 다른 컨테이너와 네트워크 환경 등을 공유하게 된다.

RepilcaSet

POD 의 라이프 싸이클을 관리하기 위해 여러 개의 파드를 생성하거나 삭제할 때 한 번에 관리하기 편하다.

파드와 RS 는 느슨한 연결을 유지하고 있으며 이런 느슨한 연결은 포드와 RS 의 정의 중 라벨 셀렉터를 이용해 이뤄진다.

라벨은 포드 등의 쿠버네티스 리소스를 분류할 때 유용하게 사용할 수 있는 메타데이터이다. 라벨은 쿠버네티스 리소스의 부가적인 정보를 표현할 수 있을 뿐만 아니라 서로 다른 오브젝트가 서로를 찾아야 할 때 사용되기도 한다.

정해진 수의 동일한 포드가 항상 실행되도록 관리한다.
노드 장애 등의 이유로 포드를 사용할 수 없을 때 다른 노드에서 포드를 다시 생성한다.
레플리카셋의 목적은 ‘포드를 생성하는 것'이 아닌, ‘일정 개수의 포드를 유지하는 것’이다.

Deployment

실제 쿠버네티스 운영 환경에서 레플리카셋을 YAML 파일에서 사용하는 경우는 거의 없다. 대부분은 레플리카셋과 포드의 정보를 정의하는 디플로이먼트라는 오브젝트를 YAML 파일에 정의해 사용한다.

디플로이먼트는 레플리카셋의 상위 오브젝트이기 때문에 디플로이먼트를 생성하면 해당 디플로이먼트에 대응하는 레플리카셋도 함께 생성된다.

디플로이먼트로부터 생성된 레플리카셋과 포드는 특이한 해시값을 포함한 이름으로 생성된다. 이 해시값은 포드를 정의하는 템플릿으로부터 생성된 것 이다.

Deployment 를 사용하는 이유

디플로이먼트를 사용하는 이유 중 하나는 애플리케이션의 업데이트와 배포를 더욱 편하게 만들기 위해서이다.

예를 들어, 애플리케이션을 업데이트할 때 레플리카셋의 변경 사항을 저장하는 리비전(revision)을 남겨 롤백을 가능하게 해주고, 무중단 서비스를 위해 포드의 롤링 업데이트의 전략을 지정할 수도 있다.

디플로이먼트는 포드의 정보를 업데이트함으로써 새로운 레플리카셋과 포드를 생성하더라도 이전 버전의 레플리카셋을 삭제하지 않고 남겨두고 있다. 즉, 디플로이먼트는 포드의 정보가 변경되어 업데이트가 발생했을 때 이전의 정보를 리비전으로서 보존한다.

리비전에 대한 자세한 정보를 알고 싶으면 아래 명령어로 확인이 가능하다.

kubectl rollout history deployment <디플로이먼트_이름>

--record=true 옵션으로 디플로이먼트를 변경하면 변경 사항을 위와 같이 디플로이먼트에 기록함으로써 해당 버전의 레플리카셋을 보존한다.

만약, 이전 버전의 레플리카셋으로 되돌리는 롤백을 하고 싶을 경우 아래와 같은 명령어를 사용할 수 있다. --to-revision 에는 되돌리려는 리비전의 번호를 입력하면 된다.

kubectl rollout undo deployment <디플로이먼트_이름> --to-revision=1

[kubernetes] AWS EKS : EBS CSI(Container Storage Interface) Driver 설치하기

ssunw — Wed, 15 Jun 2022 12:56:03 +0900

CSI(Container Storage Interface)란, Kubernetes와 같은 CO(컨테이너 오케스트레이션 시스템)의

컨테이너화된 워크로드에, 임의의 블록 및 파일 스토리지 시스템을 노출하기 위한 표준 인터페이스이다.

Amazon EBS CSI Driver를 사용하면 표준 Kubernetes 인터페이스를 사용하여,

AWS에서 EKS 및 자체 관리형 Kubernetes 클러스터 모두에서 실행되는 애플리케이션에 대해

블록 스토리지를 간단하게 구성하고 사용할 수 있다.

Amazon EBS CSI Driver에서는Amazon EKS 클러스터가 영구 볼륨을 위해

Amazon EBS 볼륨의 수명 주기(LifeCycle)를 관리할 수 있게 해준다.

클러스터를 처음 생성할 때는 Amazon EBS CSI Driver가 설치되지 않으며,

드라이버를 사용하려면 Amazon EKS 추가 기능 또는 자체 관리형 추가 기능으로 드라이버를 추가해야 한다.

아래 그림은 일반적인 CSI Driver의 구조이다.

AWS EBS CSI driver 또한 다음과 같은 구조를 가지며, 우측 StatefulSet/Deployment로 배포된 controller Pod가 AWS API를 사용하여 실제 EBS volume을 생성하는 역할을 한다. 좌측의 DaemonSet으로 배포된 node Pod은 AWS API를 사용하여 Kubernetes node (EC2 instance)에 EBS volume을 attach 해준다.

https://hyperconnect.github.io/2021/07/05/ebs-csi-gp3-support.html

더 자세한 구조와 동작에 대한 설명은

Container Storage Interface의 Design Document에서 확인할 수 있다.

EBS CSI Driver 설치하기

managing-ebs-csi에 따라 설치해보자.

NLB, ALB로 EKS 배포가 된 상태여야 한다. 현재 IAM 계정 설정까지 완료된 상태(yaml 파일에 정의)이다.

addon 설치부터 진행하며, 클러스터 yaml파일은 다음과 같다.

myeks.yaml

apiVersion: eksctl.io/v1alpha5 
kind: ClusterConfig 

metadata:
  name: myeks-custom #cluster 이름
  region: ap-northeast-2 
  version: "1.22"

# 가용영역 지정
availabilityZones: ["ap-northeast-2a", "ap-northeast-2b",  "ap-northeast-2c"]

#IAM 계정을 만들어 연결
iam:
  withOIDC: true #OIDC(OpenID Connect) : eks입장에서 AWS IAM은 외부인증서버이기 때문에 OIDC를 true로 하지 않으면 
                 #                       AWS 계정과 eks 계정은 완전히 별개이다.
  serviceAccounts: #SA 계정 생성 -> 이후 addon 추가할 때 필요
    - metadata:
        name: aws-load-balancer-controller #SA 계정 이름
        namespace: kube-system
      wellKnownPolicies:
        awsLoadBalancerController: true #계정에 권한 부여 : ingress를 만들 때 사용
    - metadata:
        name: ebs-csi-controller-sa #SA 계정 이름
        namespace: kube-system
      wellKnownPolicies:
        ebsCSIController: true #계정에 권한 부여 : ebs
    - metadata: 
        name: cluster-autoscaler #SA 계정 이름
        namespace: kube-system
      wellKnownPolicies:
        autoScaler: true #계정에 권한 부여

# Managed Node Groups : worker node 그룹
managedNodeGroups: #여러개 세팅 가능
  # On-Demand Instance
  - name: myeks-ng1
    instanceType: t3.medium
    minSize: 2
    desiredCapacity: 3 #cluster 오토스케일링된다
    maxSize: 4
    privateNetworking: true #기본적으로 EC2는 public에 배치된다(앞서 EXTERNAL-IP 부여된 것 확인했었다)
                            #외부에 노출되는 것은 위험하기 때문에 private 배치애햐한다
    ssh:
      allow: true 
      publicKeyPath: ./keypair/myeks.pub  #접속할 ssh 키
    availabilityZones: ["ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c"]
    iam:
      withAddonPolicies: #IAM 계정 정책
        autoScaler: true
        albIngress: true
        cloudWatch: true #로그를 남기기 위해
        ebs: true

# Fargate Profiles
fargateProfiles:
  - name: fg-1
    selectors:
    - namespace: dev
      labels:
        env: fargate
        
        
# CloudWatch Logging
cloudWatch:
  clusterLogging:
    enableTypes: ["*"]

클러스터 생성이 되어있지 않다면, 다음 명령을 통해 클러스터를 생성한다.

$ eksctl create cluster -f myeks.yaml

생성 후, 다음과 같이 role을 확인할 수 있다.

$ eksctl get iamserviceaccount --cluster myeks-custom
NAMESPACE       NAME                            ROLE ARN
kube-system     aws-load-balancer-controller    arn:aws:iam::xxxxxxxxxxxx:role/eksctl-myeks-custom-addon-iamserviceaccount-Role1-8AMSGCDRD4JC
kube-system     aws-node                        arn:aws:iam::xxxxxxxxxxxx:role/eksctl-myeks-custom-addon-iamserviceaccount-Role1-1SIOBJ3B0WDDL
kube-system     cluster-autoscaler              arn:aws:iam::xxxxxxxxxxxx:role/eksctl-myeks-custom-addon-iamserviceaccount-Role1-86B8C7A4ZBUF
kube-system     ebs-csi-controller-sa           arn:aws:iam::xxxxxxxxxxxx:role/eksctl-myeks-custom-addon-iamserviceaccount-Role1-1NNQO9W67BBCY

다음으로, aws-ebs-csi-driver 애드온을 설치한다.

$ eksctl create addon --name aws-ebs-csi-driver --cluster myeks-custom --service-account-role-arn  arn:aws:iam::[account]:role/eksctl-myeks-custom-addon-iamserviceaccount-Role1-15HLE8HBOD9CN --force

ebs-csi-* 파드가 생성된 것을 확인할 수 있다.

$ kubectl get po -A
NAMESPACE     NAME                                  READY   STATUS    RESTARTS   AGE
...
kube-system   ebs-csi-controller-84bcf56778-5mbk7   6/6     Running   0          25m
kube-system   ebs-csi-controller-84bcf56778-p7snc   6/6     Running   0          25m
kube-system   ebs-csi-node-fzl2v                    3/3     Running   0          25m
kube-system   ebs-csi-node-qgw25                    3/3     Running   0          25m
kube-system   ebs-csi-node-sd45p                    3/3     Running   0          25m
...

이제 EBS 스냅샷 및 EBS 사이즈 조정 등의 기능을 사용할 수 있게 된 것이다.

eksctl을 사용하여 Amazon EBS CSI 추가 기능을 제거하려면,

클러스터 이름을 수정하고 다음 명령을 실행한다.

$ eksctl delete addon --cluster [클러스터 이름] --name aws-ebs-csi-driver --preserve

[kubernetes] k8s Logging : EFK 개요 및 설치

ssunw — Wed, 15 Jun 2022 12:51:56 +0900

EFK stack은 Elasticsearch, Fluent bit(Fluentd), Kibana 3개의 플랫폼 조합을 뜻하며,

클러스터 환경에서 로그의 수집, 검색, 시각화를 가능하게 한다.

그림을 보면 알 수 있듯이, 각 클러스터에 fluent bit가 daemonset으로 log를 수집한다.

elasticsearch는 fluent bit가 수집한 로그를 저장하며, 요청에 따라 검색을 한다.

마지막으로 유저가 용이하게 사용할 수 있도록 kibana로 시각화 한다.

FluentBit

Log는 /var/log(시스템 로그)또는

/var/log/container(파드 로그) 또는 /var/log/pods(파드 로그)에 저장된다.

(이때 /var/log/container에서 /var/log/pods로 심볼릭 링크가 연결되어있다)

Fluent Bit는 이러한 로그 파일들을 수집한다.

즉 Fluent Bit는 로그 수집기이며, 로그 컬렉터, 로그 스트리머 등으로 불린다.

Fluent Bit는 이렇게 수집된 로그들을 Elastic Search로 전송한다.

Elastic Search

elastic search는 로그 저장소 및 검색 엔진으로,

데이터를 저장하는 저장소가 있고, 이 저장소에서 로그를 검색 한다.

Kibana

Elastic Search를 Kibana를 통해 시각적으로 확인한다.

즉, 수집한 로그를 시각화 하는 대시 보드이다.

단, 무인증 형태이기 때문에 실무에서 사용할 때는 유의해야한다.

☁️ 참고

ELK Stack: Elasticsearch + Logstash + Kibana
EFK Stack: Elasticsearch + Fluentd + Kibana
- Elasticsearch + Fluent Bit + Kibana
Elastic Stack: Elasticsearch + Beat + Kibana

메모리 사용량 : Fluent Bit < Fluentd < Logstash

기능 : Logstash > Fluentd > Fluent Bit

fluentd vs fluentbit

fluent bit는 자바 런타임이 필요한 JRuby logstash 에서

가벼워진 자바 런타임이 필요하지 않는 CRuby fluentd에서

더욱 경량화 된 C로 만들어진 전송에 특화된 로그 수집기이다.

fluent bit 공식 사이트에 들어가면 이 둘의 차이를 디테일하게 확인할 수 있다.

결론적으로 요약하자면 fluentd는 플러그인 등 확장성이 좋고, fluent bit는 리소스를 적게 차지 한다.

EFK Logging

Kibana: 데이터 시각화

Fluent Bit: 로그 컬렉터(수집기)

Elasticsearch: 검색 엔진

Fluent Bit 가 노드에서 로그를 수집한 후 Elasticsearch 로 전송, 로그는 Elasticsearch 에 저장되고 Kibana 가 수집한 로그들을 시각화 한다.

Elasticsearch

https://artifacthub.io/packages/helm/elastic/elasticsearch

elasticsearch 7.17.3 · elastic/elastic

Official Elastic helm chart for Elasticsearch

artifacthub.io

먼저 helm으로 레포지토리(저장소)를 추가하고, 업데이트한다.

helm repo add elastic https://helm.elastic.co
helm repo update

해당 레포지토리에서 elasticsearch와 kibana를 설치할 예정이다.

다음으로 몇가지를 수정(사용자화)하기 위해 values를 es-value.yaml로 받아온다.

helm show values elastic/elasticsearch > es-value.yml

테스트를 위한 것이기 때문에, 복제본의 개수와 리소스를 줄여서 다음과 같이 수정한다.

es-value.yml

...
18 replicas: 1
19 minimumMasterNodes: 1
...
80 resources:
81   requests:
82     cpu: "500m"
83     memory: "1Gi"
84   limits:
85     cpu: "500m"
86     memory: "1Gi"

logging namespace를 생성하고, 해당 ns에 elasticsearch를 설치한다.

kubectl create ns logging
helm install elastic elastic/elasticsearch -f es-value.yml -n logging

Fluent Bit

https://github.com/fluent/fluent-bit-kubernetes-logging

GitHub - fluent/fluent-bit-kubernetes-logging: Fluent Bit Kubernetes Daemonset

Fluent Bit Kubernetes Daemonset. Contribute to fluent/fluent-bit-kubernetes-logging development by creating an account on GitHub.

github.com

Fluent Bit는 Helm차트가 있긴 하지만 버전이 낮으므로, GitHub에서 clone 한다.

git clone https://github.com/fluent/fluent-bit-kubernetes-logging.git

Service Account와 Role, RoleBinding을 설치한다.

cd fluent-bit-kubernetes-logging

kubectl create -f fluent-bit-service-account.yaml -n logging
kubectl create -f fluent-bit-role-1.22.yaml -n logging
kubectl create -f fluent-bit-role-binding-1.22.yaml -n logging

fluent-bit-configmap.yaml는 공통적으로 적용되는 설정파일이고,

fluent-bit-ds-minikube.yaml는 minikube에서 사용하는 것이고,

일반은 fluent-bit-ds.yaml파일(데몬셋)이다.

vi fluent-bit-kubernetes-logging/output/elasticsearch/fluent-bit-ds.yaml

Fluent가 Elastic Search로 로그를 보낼 수 있도록

다음과 같이 fluent-bit-ds.yaml을 Elastic Search 서비스 이름에 맞춰서 수정하고, 생성한다.

32         - name: FLUENT_ELASTICSEARCH_HOST
33           value: "elasticsearch-master"

cd fluent-bit-kubernetes-logging/output/elasticsearch

kubectl create -f fluent-bit-configmap.yaml -n logging
kubectl create -f fluent-bit-ds.yaml -n logging

minikube 를 사용할 경우 fluent-bit-ds.yaml 대신 fluent-bit-ds-minikube.yaml 을 사용한다.

Kibana

kibana는 앞서 설치한 elasticsearch와 동일한 레포지토리에서 설치한다.

먼저 다음과 같이 values를 kibana-value.yaml로 받아오고, 리소스를 수정한다.

또한, 외부에 노출시키기 위해 서비스타입을 LoadBalancer로 수정한다.

helm show values elastic/kibana > kibana-value.yml

kibana-value.yml

...
49 resources:
50   requests:
51     cpu: "500m"
52     memory: "0.7Gi"
53   limits:
54     cpu: "500m"
55     memory: "0.7Gi"
...
119 service:
120   type: LoadBalancer

helm install kibana elastic/kibana -f kibana-value.yml -n logging

작동 확인

설치한 것들이 잘 작동되는지 테스트를 진행해보자.

$ kubectl port-forward -n logging elasticsearch-master-0 9200:9200

터미널을 하나 더 열어서 curl명령어로 확인했을 때,

다음과 같이 tagline이 You Know, for Search라고 출력되면 정상적으로 작동되고 있다는 뜻이다.

$ curl localhost:9200
{
  "name" : "elasticsearch-master-0",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "XXXXXXXXXXXXXXXXXX",
  "version" : {
    "number" : "7.17.3",
    "build_flavor" : "default",
    "build_type" : "docker",
    "build_hash" : "XXXXXXXXXXXXXXXXXX",
    "build_date" : "XXXXXXXXXXXXXXXXXX",
    "build_snapshot" : false,
    "lucene_version" : "8.11.1",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

$ curl localhost:9200/_cat/indices
green  open .kibana_task_manager_7.17.3_001 XXXXXXXXXXXXXXXXXX 1 0   17 3804 538.4kb 538.4kb
green  open .apm-custom-link                XXXXXXXXXXXXXXXXXX 1 0    0    0    226b    226b
green  open .apm-agent-configuration        XXXXXXXXXXXXXXXXXX 1 0    0    0    226b    226b
yellow open logstash-2022.06.01             XXXXXXXXXXXXXXXXXX 1 1 4676    0  15.8mb  15.8mb
green  open .kibana_7.17.3_001              XXXXXXXXXXXXXXXXXX 1 0   22    4   4.7mb   4.7mb

다음으로 kibana에 접속한다.

$ kubectl get svc -n logging
NAME                            TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)             AGE
elasticsearch-master            ClusterIP      10.233.21.152   <none>            9200/TCP,9300/TCP   27m
elasticsearch-master-headless   ClusterIP      None            <none>            9200/TCP,9300/TCP   27m
kibana-kibana                   LoadBalancer   10.233.19.27    192.168.100.240   5601:31535/TCP      18m

kibana의 EXTERNAL-IP와 PORT 192.168.100.240:5601 로 접속을 시도하면

다음과 같이 정상적으로 접속되는 것을 확인할 수 있다.

EFK 세팅하기

Explore on my own을 클릭하고,

[Management] - [Stack Management]를 클릭한다.

[Kibana] - [Index Patterns] - [Create index pattern]을 클릭한다.

Elastic Search에서 index는 database이다.

logstash-xxxx.xx.xx 파일을 확인할 수 있는데,

이것은 Fluent Bit가 Elastic Search에 전송한 로그파일로, 하루에 1개씩 생성된다.

Name에 모든 로그 파일을 수집하도록 logstash-*를 입력하고

Timestamp field는 @timestamp를 선택한다.

[Analytics] - [Discover]를 클릭한다.

그러면 다음과 같이 로그들을 확인할 수 있다. 여기서 KQP는 Kibana Query Language이다.

Search 창에 원하는 키워드를 입력하여 검색이 가능하다.

aws 로드밸랜서 등록 후 503 Service Temporarily Unavailable 발생

ssunw — Wed, 15 Jun 2022 12:30:50 +0900

aws 로드밸랜서 등록후 나오는 503 에러 해결방법

보통은 로드밸랜서의 타겟 그룹에 등록된 타겟이 없을때 혹은 타겟 그룹이 unhealthy 상태일 때 발생한다고 생각하면 편하거.

인스턴스 기반일 경우 타겟 그룹에서 사용할 ec2 인스턴스를 등록하거나 헬스체크를 통과했는지 확인한다.

쿠버네티스 환경에서도 상동하다.

참조: docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-503-issues

[kubernetes] Helm Prometheus Stack 설치

ssunw — Sun, 29 May 2022 15:30:34 +0900

HELM

공식 문서: https://helm.sh/docs/

쿠버네티스 패키지 매니저

용어

Helm Charts: 차트, 패키지
Repository: 차트 저장소
Release: 쿠버네티스 오브젝트 리소스 (패키지 → 클러스터에 생성한 인스턴스)

Helm 저장소는 다양하게 존재한다.

gRPC 로 클라이언트와 서버가 통신한다.

Tiller 에 의해 다운받은 패키지를 API server 를 통해 설치를 한다.

v3 에서 Tiller 를 없앴다. 보안상 문제가 생길 수도 있기 때문, 그래서 v3 에서는 클라이언트가 바론 API server 에 직접 접근하는 방식을 사용한다.

helm 설치(debian/ubuntu 계열)

curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
sudo apt-get install apt-transport-https --yes
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all
sudo apt-get update
sudo apt-get install helm main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list

Helm Chart 검색 사이트: https://artifacthub.io/

차트 구조

<Chart Name>/
	chart.yml
	values.yml
	templates/

chart.yml: 차트의 메타데이터
values.yml: 패키지를 커스터마이즈/사용자화(value)
templates: YAML 오브젝트 파일

helm 사용법

artifacthub 검색

helm search hub <PATTERN>

저장소 추가

helm repo add <저장소> <레포지토리_주소>

helm repo add wordpress https://charts.bitnami.com/bitnami

저장소 검색

helm search repo <저장소>/<PATTERN>

차트 설치

helm install <릴리즈_이름> <저장소>/<차트_이름>

릴리즈 확인

helm list

릴리즈 제거

helm uninstall <릴리즈_이름>

차트 정보 확인

helm show readme <저장소>/<차트>
helm show chart <저장소>/<차트>
helm show values <저장소>/<차트>

차트 사용자화

helm install mywp bitnami/wordpress --set replicaCount=2
helm install mywp bitnami/wordpress --set replicaCount=2 --set service.type=NodePort

릴리즈 업그레이드

helm show value <저장소>/<차트> > wp-value.yml
vi wp-value.yml
helm upgrade <릴리즈_이름> <저장소>/<차트> -f wp-value.yml

릴리즈 업그레이드 히스토리 확인

helm history <릴리즈_이름>

릴리즈 롤백

helm rollback <릴리즈_이름> <REVISION>

Monitoring & Logging

Prometheus Monitoring

https://prometheus.io/docs/introduction/overview/

프로메테우스 아키텍쳐

Prometheus targets(Jobs/exporters): 앱, 프로세스 등 모니터링하려는 대상의 데이터를 exporters 파드에서 수집한다.

Pushgateway: 생명주기가 짧은 녀석들의 데이터들은 여기서 보관한다.

discover targets: target 을 찾기 위해 프로메테우스 서버에서 대상을 특정할 수 있어야 한다.(api-server 에 질의 한다.-pod 목록, node 목록, svc 목록 등…)

TSDB(Time Series DB): 시계열 DB, 관계형 데이터베이스가 아니라 시간대별로 데이터를 저장하기 좋게 만든 DB 를 시계열 DB 라고 한다.

HTTP server: 대시보드. UI, UX 가 엄청 끔찍해서 거의 사용하지는 않는다.

PromQL: SQL 같은 전용 언어를 만들었다. TSDB 에서 데이터를 검색할 수 있는 전용 언어이다.

AlertManager: 리소스를 모니터링 하다가 특정 임계값을 넘으면 슬랙, 이메일 등으로 알림을 보낸다.

Grafana: TSDB 의 시계열 데이터 PromQL 을 통해 쿼리하여 프로덕션 레벨에서 모니터링하는 도구

Helm kube-prometheus-stack 차트 설치

깃허브: https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack

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

prom-values.yml

grafana:
  service:
    type: LoadBalancer

kubectl create ns monitor
helm install prom prometheus-community/kube-prometheus-stack -f prom-values.yaml -n monitor

helm list -n monitor
NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
prom    monitor         1               2022-05-27 05:49:29.781975505 +0000 UTC deployed        prometheus-15.9.0       2.34.0

kubectl get all -n monitor
NAME                                                READY   STATUS    RESTARTS   AGE
pod/prom-kube-state-metrics-7b78c9f88-mf84w         1/1     Running   0          84s
pod/prom-prometheus-alertmanager-55b97bcd64-rwpct   2/2     Running   0          84s
pod/prom-prometheus-node-exporter-28t5x             1/1     Running   0          85s
pod/prom-prometheus-node-exporter-72sbt             1/1     Running   0          85s
pod/prom-prometheus-node-exporter-rkcx5             1/1     Running   0          85s
pod/prom-prometheus-pushgateway-67f89c46f7-4psh9    1/1     Running   0          85s
pod/prom-prometheus-server-c5cbb7c66-x76b6          2/2     Running   0          84s

NAME                                    TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/prom-kube-state-metrics         ClusterIP   10.233.17.58    <none>        8080/TCP   85s
service/prom-prometheus-alertmanager    ClusterIP   10.233.35.47    <none>        80/TCP     85s
service/prom-prometheus-node-exporter   ClusterIP   10.233.3.31     <none>        9100/TCP   85s
service/prom-prometheus-pushgateway     ClusterIP   10.233.47.169   <none>        9091/TCP   85s
service/prom-prometheus-server          ClusterIP   10.233.55.155   <none>        80/TCP     85s

NAME                                           DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/prom-prometheus-node-exporter   3         3         3       3            3           <none>          85s

NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/prom-kube-state-metrics        1/1     1            1           85s
deployment.apps/prom-prometheus-alertmanager   1/1     1            1           85s
deployment.apps/prom-prometheus-pushgateway    1/1     1            1           85s
deployment.apps/prom-prometheus-server         1/1     1            1           85s

NAME                                                      DESIRED   CURRENT   READY   AGE
replicaset.apps/prom-kube-state-metrics-7b78c9f88         1         1         1       85s
replicaset.apps/prom-prometheus-alertmanager-55b97bcd64   1         1         1       85s
replicaset.apps/prom-prometheus-pushgateway-67f89c46f7    1         1         1       85s
replicaset.apps/prom-prometheus-server-c5cbb7c66          1         1         1       85s

prom-grafana 로드밸런서의 EXTERNAL-IP로 접속하면 다음과 같은 화면을 확인할 수 있다.

패스워드는 values.yaml에서 확인할 수 있다.

ID: admin
PWD: prom-operator

로그인 후 다음과 같이 클러스터의 CPU 사용량 등을 확인할 수 있다.

또한 다음과 같이 네임스페이스를 선택해서 확인하는 것도 가능하다.

[kubernetes] 인증

ssunw — Sun, 29 May 2022 15:28:49 +0900

인증

공식 문서: https://kubernetes.io/docs/reference/access-authn-authz/authentication/

쿠버네티스의 사용자

Service Account(SA): 쿠버네티스가 관리하는 SA 사용자
- 사용자가 사용하지 않는다.
- Pod 가 사용하는 계정이다.
Normal User: 일반 사용자(쿠버네티스가 관리하지 않는다.)
- 사용자가 사용하는 계정이다.
- Pod 는 사용하지 않는다.

인증 방법:

x509 인증서
static token
- Bearer Token
  - http 헤더에 인증 정보가 있는 토큰을 담아서 보낸다.
- Service Account Token
  - JSON Web Token: JWT
- OpenID Connect(OIDC)
  - 외부 인증 표준화 인터페이스
  - okta 인증 서버 서비스가 있다.
  - OAuth Provider: EKS 에서 IAM 계정을 사용하는 방식이 바로 OIDC 를 사용한 방식이다.

Pod 는 SA 계정을 사용하고 SA 계정에 할당받은 Token 을 사용한다.

사용자(나)는 x509 를 사용하여 kubectl 을 사용한다.

RBAC: Role Based Access Control

공식 문서: https://kubernetes.io/docs/reference/access-authn-authz/rbac/, https://kubernetes.io/ko/docs/reference/access-authn-authz/authorization/

역할 기반 접근 제어(RBAC, Role-based access control)는 클러스터 내 개별 사용자의 역할을 기반으로 컴퓨터나 네트워크 리소스에 대한 접근을 규제하는 방식이다. 이 맥락에서 접근은 개별 사용자가 파일을 보거나 만들거나 수정하는 것과 같은 특정 작업을 수행할 수 있는 능력이다.

Role: 특정 Name Space 내에서만 권한 부여 가능
ClusterRole: 글로벌하게 권한 부여 가능
- view: 읽을 수 있는 권한
- edit: 생성/삭제/변경할 수 있는 권한
- admin: 모든 것 관리(RBAC의 ClusterRole 제외)
- cluster-admin: 모든 것 관리
RoleBinding
- 특정 Name Space 내에서 Role 과 SA/User 사용자를 연결시켜 주는 것이 RoleBinding 이다.
ClusterRoleBinding
- ClusterRole 과 SA/User 사용자를 연결시켜주는 것이 ClusterRoleBinding 이다.

$ kubectl get po -v=7
I0526 06:31:24.674874  163632 loader.go:372] Config loaded from file:  /home/vagrant/.kube/config
I0526 06:31:24.695368  163632 round_trippers.go:432] GET <https://127.0.0.1:6443/api/v1/namespaces/default/pods?limit=500>
I0526 06:31:24.695939  163632 round_trippers.go:438] Request Headers:
I0526 06:31:24.696880  163632 round_trippers.go:442]     Accept: application/json;as=Table;v=v1;g=meta.k8s.io,application/json;as=Table;v=v1beta1;g=meta.k8s.io,application/json
I0526 06:31:24.697384  163632 round_trippers.go:442]     User-Agent: kubectl/v1.22.8 (linux/amd64) kubernetes/7061dbb
I0526 06:31:24.713208  163632 round_trippers.go:457] Response Status: 200 OK in 15 milliseconds
NAME                                      READY   STATUS    RESTARTS        AGE
nfs-client-provisioner-758f8cd4d6-rt2t8   1/1     Running   5 (4h25m ago)   2d1h

-v 옵션을 사용해서 Request, Response 를 자세하게 확인할 수 있다.

kubectl create 커맨드 → api-server 에 HTTP POST 요청

kubectl get, list, watch 커맨드 → api-server 에 HTTP GET 요청

kubectl update 커맨드 → api-server 에 HTTP PUT 요청

kubectl patch 커맨드 → api-server 에 HTTP PATCH 요청

kubectl delete, deletecollection 커맨드 → api-server 에 HTTP DELTE 요청

Role 예제

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Cluster Role 예제

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing Secret
  # objects is "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

RoleBinding 예제

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# You can specify more than one "subject"
- kind: User 
  name: jane # .kube/config 에 users.user.name 에 jane 이 있어야 한다.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding 예제

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Service Account(SA)

kubectl craete sa <SA_NAME>

$ kubectl create sa myuser1
serviceaccount/myuser1 created

$ kubectl describe sa myuser1
Name:                myuser1
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   myuser1-token-lgpsj
Tokens:              myuser1-token-lgpsj
Events:              <none>

$ kubectl get secret
NAME                                 TYPE                                  DATA   AGE
default-token-jw8gl                  kubernetes.io/service-account-token   3      2d4h
myuser1-token-lgpsj                  kubernetes.io/service-account-token   3      14s
nfs-client-provisioner-token-bgdtf   kubernetes.io/service-account-token   3      2d1h

사용자 생성을 위한 x509 인증서

Private Key 생성

openssl genrsa -out myuser.key 2048

x509 인증서 요청 생성

openssl req -new -key myuser.key -out myuser.csr -subj "/CN=myuser"

/CN=myuser 을 작성한 이유는 인증서의 Common Name 과 ~/.kube/config 의 users.name 과 똑같아야 한다. 그 때문에 /CN=myuser 를 하면 간단하게 Common Name 을 지정할 수 있다.

인증서 base64 인코딩

cat myuser.crt | base64 | tr -d "\\n"

csr.yml

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: myuser-csr
spec:
  usages:
  - client auth
  signerName: kubernetes.io/kube-apiserver-client
  request: LS0tLS1CRUdJTiB

kubectl create -f csr.yaml

kubectl get csr

상태: Pending

kubectl certificate approve myuser-csr

kubectl get csr

상태: Apporved, Issued

kubectl get csr myuser-csr -o yaml

spec.status.certificate 확인

kubectl get csr myuser-csr -o jsonpath='{.status.certificate}' | base64 -d > myuser.crt

openssl x509 -in myuser.crt --text

Kubeconfig 사용자 생성

kubectl config set-credentials myuser --client-certificate=myuser.crt --client-key=myuser.key --embed-certs=true

Kubeconfig 컨텍스트 생성

kubectl config set-context myuser@cluster.local --cluster=cluster.local --user=myuser --namespace
=default

kubectl config get-users
kubectl config get-clusters
kubectl config get-contexts

kubectl config use-context myuser@cluster.local

ClusterRole view 권한을 myuser 사용자에게 부여

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: myuser-view-crb
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: myuser

kubectl create -f myuser-view-crb.yml

kubectl describe clusterrolebindings.rbac.authorization.k8s.io myuser-view-crb

kubectl config use-context myuser@cluster.local
Switched to context "myuser@cluster.local".

kubectl config get-contexts
CURRENT   NAME                             CLUSTER         AUTHINFO           NAMESPACE
          kubernetes-admin@cluster.local   cluster.local   kubernetes-admin
*         myuser@cluster.local             cluster.local   myuser             default

kubectl get pods
NAME                                      READY   STATUS    RESTARTS      AGE
nfs-client-provisioner-758f8cd4d6-rt2t8   1/1     Running   6 (23m ago)   2d19h

kubectl auth can-i get pod
yes

만약 새로운 ClusterRole 만들고 싶을 때는 아래처럼 하면 된다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  namespace: default
  name: myuser-role
rules:
- apiGroups: ["*"] # "" indicates the core API group
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

[kubernetes] Shedulling

ssunw — Sun, 29 May 2022 15:27:28 +0900

Pod Shedulling

공식 문서: https://kubernetes.io/ko/docs/concepts/scheduling-eviction/assign-pod-node/, https://kubernetes.io/ko/docs/concepts/scheduling-eviction/kube-scheduler/

쿠버네티스에서 스케줄링 은 Kubelet이 파드를 실행할 수 있도록 파드가 노드에 적합한지 확인하는 것을 말한다.

스케줄러는 노드가 할당되지 않은 새로 생성된 파드를 감시한다. 스케줄러가 발견한 모든 파드에 대해 스케줄러는 해당 파드가 실행될 최상의 노드를 찾는 책임을 진다. 스케줄러는 아래 설명된 스케줄링 원칙을 고려하여 이 배치 결정을 하게 된다.

파드가 특정 노드에 배치되는 이유를 이해하려고 하거나 사용자 정의된 스케줄러를 직접 구현하려는 경우 이 페이지를 통해서 스케줄링에 대해 배울 수 있을 것이다.

nodeName

nodeName 은 가장 간단한 형태의 노트 선택 제약 조건이지만, 한계로 인해 일반적으로는 사용하지 않는다. nodeName 은 PodSpec의 필드이다. 만약 비어있지 않으면, 스케줄러는 파드를 무시하고 명명된 노드에서 실행 중인 kubelet이 파드를 실행하려고 한다. 따라서 만약 PodSpec에 nodeName 가 제공된 경우, 노드 선택을 위해 위의 방법보다 우선한다.

nodeName 을 사용해서 노드를 선택할 때의 몇 가지 제한은 다음과 같다.

만약 명명된 노드가 없으면, 파드가 실행되지 않고 따라서 자동으로 삭제될 수 있다.
만약 명명된 노드에 파드를 수용할 수 있는 리소스가 없는 경우 파드가 실패하고, 그 이유는 다음과 같이 표시된다. 예: OutOfmemory 또는 OutOfcpu.
클라우드 환경의 노드 이름은 항상 예측 가능하거나 안정적인 것은 아니다.

여기에 nodeName 필드를 사용하는 파드 설정 파일 예시가 있다.

myweb-rs-nn.yml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myweb-rs-nn
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      nodeName: node2
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb

nodeSelector

nodeSelector 는 가장 간단하고 권장되는 노드 선택 제약 조건의 형태이다. nodeSelector 는 PodSpec의 필드이다. 이는 키-값 쌍의 매핑으로 지정한다. 파드가 노드에서 동작할 수 있으려면, 노드는 키-값의 쌍으로 표시되는 레이블을 각자 가지고 있어야 한다(이는 추가 레이블을 가지고 있을 수 있다). 일반적으로 하나의 키-값 쌍이 사용된다.

0 단계: 사전 준비

이 예시는 쿠버네티스 파드에 대한 기본적인 이해를 하고 있고 쿠버네티스 클러스터가 설정되어 있다고 가정한다.

1 단계: 노드에 레이블 붙이기

kubectl get nodes 를 실행해서 클러스터 노드 이름을 가져온다. 이 중에 레이블을 추가하기 원하는 것 하나를 선택한 다음에 kubectl label nodes <노드 이름> <레이블 키>=<레이블 값> 을 실행해서 선택한 노드에 레이블을 추가한다. 예를 들어 노드의 이름이 'kubernetes-foo-node-1.c.a-robinson.internal' 이고, 원하는 레이블이 'disktype=ssd' 라면, kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd 를 실행한다.

kubectl get nodes --show-labels 를 다시 실행해서 노드가 현재 가진 레이블을 확인하여, 이 작업을 검증할 수 있다. 또한 kubectl describe node "노드 이름" 을 사용해서 노드에 주어진 레이블의 전체 목록을 확인할 수 있다.

2 단계: 파드 설정에 nodeSelector 필드 추가하기

실행하고자 하는 파드의 설정 파일을 가져오고, 이처럼 nodeSelector 섹션을 추가한다. 예를 들어 이것이 파드 설정이라면,

kubectl get nodes --show-labels
kubectl label nodes k8s-node1 gpu=highend
kubectl label nodes k8s-node2 gpu=lowend
kubectl label nodes k8s-node3 gpu=lowend
kubectl get nodes -L gpu

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myweb-rs-ns
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      nodeSelector:
        gpu: lowend
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb

kubectl get po -o wide

Affinity(선호도)

참조: https://waspro.tistory.com/582

affinity
- pod
- node
anti-affinity
- pod

affinity는 뜻 그대로 유연한 Scheduling이 가능하도록 구성할 수 있다.

앞서 살펴본 nodeSelector의 경우 label naming을 기준으로 Pod를 특정 노드 또는 특정 노드 그룹에 배포하는 방식을 사용하였다면, affinity는 다양한 조건을 제시할 수 있고 유연하게 처리할 수 있다.

affinity는 크게 노드를 기준으로 하는 node affinity와 pod 레벨에서 label을 관리할 수 있는 pod affinity으로 구분할 수 있다.

node affinity가 node level에서 배치를 관리하는다는점에서 nodeSelector와는 비슷하지만 다양한 조건을 명시할 수 있다는 유연성에서 차이가 있다.

node affinity는 크게 아래와 같이 4가지로 분류할 수 있다.

requiredDuringSchedulingIgnoredDuringExecution
preferredDuringSchedulingIgnoredDuringExecution
requiredDuringSchedulingRequiredDuringExecution
preferredDuringSchedulingRequiredDuringExecution

서두의 빨간색 required(hard affinity) & preferred(soft affinity)는 반드시 포함해야 하는지 또는 우선시하되 필수는 아닌지를 결정하는 조건이며, 중간의 파란색 Ignored & Required는 운영 중(Runtime) Node의 Label이 변경되면 무시할 것인지(Ignore) 또는 즉시 Eviction 처리(Required)하여 재기동을 수행할 것인지를 결정한다.

여기에 노드 어피니티를 사용하는 파드 예시가 있다.

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: k8s.gcr.io/pause:2.0

requiredDuringSchedulingIgnoredDuringExecution의 경우 아래 요구조건이 일치하는 node에 적용하겠다는 의미로 matchExpressions로 정의 된 key 값이 label의 [key], values 값이 label의 [value]와 일치해야 한다.

여기서 처음 정의되는 operator라는 항목이 있는데 nodeAffinity에서 사용할 수 있는 operator에는 In 외에도 NotIn, Exists, DoesNotExist, Gt, Lt 등을 활용할 수 있다.

Pod Affinity

pod affinity는 node affinity가 node의 label을 기준으로 기동했던것 처럼 pod의 label을 기준으로 조건을 만족할 경우 pod를 기동하는 방식으로 작성된다.

노드가 3개 있다. RS, STS 이 있다.

RS 에는 Web Pod 3개가 있다. STS 에는 DB Pod 가 3개 있다.

베스트 시나리오는 각각의 노드에 Web, DB 파드가 한 쌍 씩 있어야 한다.

최악의 시나리오는 노드 하나에 모든 Web Pod 가 있고 다른 노드에 DB Pod 가 나눠져서 존재하는 것이다.

베스트 시나리오 처럼 만들기 위해 Pod 와 Pod 간에 선호도를 설정해줘야 한다. 이 때 Pod Affinity 를 사용한다.

물론 최악의 시나리오로 하나의 노드에 모든 파드들이 몰려있을 수 있다. 이를 방지하기 위해 Pod anti-affinity 를 사용해야 한다. RS, STS 에서 레플리카로 Pod 가 생성되기 때문에 RS, STS 에 anti-affinity 를 적용하여 서로 같은 파드들은 배척하도록 하여 다른 노드에 배치되도록 해야 한다.

그래서 위와 같이 만들어지도록 시나리오를 작성해야 한다.

topologyKey: Pod 간에 같이 있어도 되는지, 같이 있으면 안되는지에 대한 기준이다. 즉 어떤 노드에 파드들을 어떻게 배치할지에 대해 설정한다.

myweb-rs-a.yml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myweb-a
spec:
  replicas: 3
  selector:
    matchLabels:
      app: a
  template:
    metadata:
      labels:
        app: a
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 10
              preference:
                matchExpressions:
                  - key: gpu
                    operator: Exists
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                  app: a
              topologyKey: kubernetes.io/hostname
      containers:
        - name: myweb
          image: nginx

myweb-rs-b.yml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myweb-b
spec:
  replicas: 2
  selector:
    matchLabels:
      app: b
  template:
    metadata:
      labels:
        app: b
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 10
              preference:
                matchExpressions:
                  - key: gpu
                    operator: Exists
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                 matchLabels:
                   app: b
              topologyKey: "kubernetes.io/hostname"
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                 matchLabels:
                   app: a
              topologyKey: "kubernetes.io/hostname"
      containers:
        - name: myweb
					image: ghcr.io/c1t1d0s7/go-myweb

        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                 matchLabels:
                   app: a
              topologyKey: "kubernetes.io/hostname"

labelSelector에 의해 pod의 라벨 정보가 app=a 인 pods가 기동 된 노드를 찾습니다.

topologyKey에 정의 된 key 값인 kubernetes.io/hostname의 value가 같은 모든 노드에 Pod를 배치한다. 이때 hostname은 모든 서버가 서로 다르므로 app=a 인 파드가 배포된 노드에만 배포가 가능하다는 결론이 나온다.

Cordon & Drain

Cordon

스케줄링 금지

kubectl cordon <노드_이름>

스케줄링 허용

kubectl uncordon <노드_이름>

drain: 노드의 Pod 들을 삭제 후 해당 노드 cordon. 데몬셋이 셋팅되어 있을 경우 ignore 옵션을 사용해야 한다. 주로 패치, 커널 업데이트를 할 때 사용한다.

kubectl drain <노드_이름>
kubectl drain <노드_이름> --ignore-daemonsets

kubectl uncordon <노드_이름>

Taint & Toleration

공식 문서: https://kubernetes.io/ko/docs/concepts/scheduling-eviction/taint-and-toleration/

Control Plane

Taint: “node-role.kubernetes.io/master:NoSchedule” → key:value == master:NoSchedule, 키밸류 형태로 master 에 스케줄링을 하지 않도록 설정한다.

Taint: 특정 노드에 역할을 부여

Toleration: Taint 노드에 스케줄링 허용

command 를 사용하여 Taint 걸기

kubectl taint node k8s-node1 node-role.kubernetes.io/master:NoSchedule

command 를 사용하여 Taint 해제

kubectl taint node k8s-node1 node-role.kubernetes.io/master:NoSchedule-

myweb-a.yml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myweb-a
spec:
  replicas: 3
  selector:
    matchLabels:
      app: a
  template:
    metadata:
      labels:
        app: a
    spec:
      tolerations:
        - key: "node-role.kubernetes.io/masters"
          operator: "Exists"
          effect: "NoSchedule"
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 10
              preference:
                matchExpressions:
                  - key: gpu
                    operator: Exists
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                  app: a
              topologyKey: kubernetes.io/hostname
      containers:
        - name: myweb
          image: nginx

toleration 을 사용하여 taint 된 노드에 스케줄링을 할 수 있다.

kubectl describe node k8s-node1 | grep -i taint

특정 노드에 taint 를 거는 것은 역할을 부여하는 것이다.

toleration 을 사용해서 특정 파드들을 taint 에 의해 역할이 부여된 노드에 파드를 배치할 수 있다.

taint 를 만든 목적은 노드에 역할을 부여하기 위해서이다. taint 된 노드들은 반드시 toleration 을 사용해야 파드가 배치될 수 있다.

Kubeconfig

~/.kube/config

apiVersion: v1
kind: Config
preferences: {}

clusters:
- name: cluster.local
  cluster:
    certificate-authority-data: LS0tLS... # CA 인증서
    server: https://127.0.0.1:6443 # 실제 api-sever 의 주소
  
- name: mycluster
  cluster: # 새로운 클러스터를 여기에 추가할 수 있다.
    server: https://x.x.x.x:6443
  
users:
- name: kubernetes-admin
  user:
    # 인증서와 키를 사용해서 서버에 사용자 인증을 한다.
    client-certificate-data: LS0tLS1CRUdJTi...  # 클라이언트 인증서
    client-key-data: LS0tLS1CRU... # 클라이언트 개인키

contexts:
- name: kubernetes-admin@cluster.local 
  context: # 사용자와 클러스터를 연결
    cluster: cluster.local
    user: kubernetes-admin
  

# 현재 사용할 컨텍스트 결정
current-context: kubernetes-admin@cluster.local

kubectl config view

kubectl config get-clusters

kubectl config get-contexts

kubectl config use-context myadmin@mycluster

[kubernetes] AutoScaling

ssunw — Sun, 29 May 2022 15:25:32 +0900

Auto Sacling

Resource Request & Limit

공식 문서: https://kubernetes.io/ko/docs/concepts/configuration/manage-resources-containers/

요청: request

제한: limit

요청 ≤ 제한

QoS(서비스 품질) Class:

BestEffort: 품질이 가장 안좋음, 리소스를 아예 할당받지 못할 수도 있다. 리소스가 없는 상태에서 파드가 생성되야 하는 경우 BestEffort Pod 가 먼저 삭제된다.
Burstable: 중간
Guranteed: 품질이 가장 좋음, 가장 베스트

요청/제한이 설정되어 있지 않으면: QoS
요청 < 제한: Burstable
요청 == 제한: Guranteed

pod.spec.containers.resources

requests
- cpu
- memory
limits
- cpu
- memory

CPU 요청 & 제한: milicore 단위를 사용

ex) 1500m → CPU 코어 1.5개, 1000m → CPU 코어 1개

ex) 1.5, 0.5

메모리 요청 & 제한: M, G, T, Mi, Gi, Ti

파드를 지정할 때, 컨테이너에 필요한 각 리소스의 양을 선택적으로 지정할 수 있다. 지정할 가장 일반적인 리소스는 CPU와 메모리(RAM) 그리고 다른 것들이 있다.

파드에서 컨테이너에 대한 리소스 요청(request) 을 지정하면, kube-scheduler는 이 정보를 사용하여 파드가 배치될 노드를 결정한다. 컨테이너에 대한 리소스 제한(limit) 을 지정하면, kubelet은 실행 중인 컨테이너가 설정한 제한보다 많은 리소스를 사용할 수 없도록 해당 제한을 적용한다. 또한 kubelet은 컨테이너가 사용할 수 있도록 해당 시스템 리소스의 최소 요청 량을 예약한다.

파드가 실행 중인 노드에 사용 가능한 리소스가 충분하면, 컨테이너가 해당 리소스에 지정한 request 보다 더 많은 리소스를 사용할 수 있도록 허용된다. 그러나, 컨테이너는 리소스 limit 보다 더 많은 리소스를 사용할 수는 없다.

예를 들어, 컨테이너에 대해 256MiB의 memory 요청을 설정하고, 해당 컨테이너가 8GiB의 메모리를 가진 노드로 스케줄된 파드에 있고 다른 파드는 없는 경우, 컨테이너는 더 많은 RAM을 사용할 수 있다.

해당 컨테이너에 대해 4GiB의 memory 제한을 설정하면, kubelet(그리고 컨테이너 런타임)이 제한을 적용한다. 런타임은 컨테이너가 구성된 리소스 제한을 초과하여 사용하지 못하게 한다. 예를 들어, 컨테이너의 프로세스가 허용된 양보다 많은 메모리를 사용하려고 하면, 시스템 커널은 메모리 부족(out of memory, OOM) 오류와 함께 할당을 시도한 프로세스를 종료한다.

제한은 반응적(시스템이 위반을 감지한 후에 개입)으로 또는 강제적(시스템이 컨테이너가 제한을 초과하지 않도록 방지)으로 구현할 수 있다. 런타임마다 다른 방식으로 동일한 제약을 구현할 수 있다.

로컬 임시(ephemeral) 스토리지

노드에는 로컬에 연결된 쓰기 가능 장치 또는, 때로는 RAM에 의해 지원되는 로컬 임시 스토리지가 있다. "임시"는 내구성에 대한 장기간의 보증이 없음을 의미한다.

파드는 스크래치 공간, 캐싱 및 로그에 대해 임시 로컬 스토리지를 사용한다. kubelet은 로컬 임시 스토리지를 사용하여 컨테이너에 emptyDir 볼륨을 마운트하기 위해 파드에 스크래치 공간을 제공할 수 있다.

kubelet은 이러한 종류의 스토리지를 사용하여 노드-레벨 컨테이너 로그, 컨테이너 이미지 및 실행 중인 컨테이너의 쓰기 가능 계층을 보유한다.

myweb-reqlim.yml

apiVersion: v1
kind: Pod
metadata:
  name: myweb-reqlim
spec:
  containers:
    - name: myweb
      image: ghcr.io/c1t1d0s7/go-myweb
      resources:
        requests:
          cpu: 200m
          memory: 200M
        limits:
          cpu: 200m
          memory: 200M

kubectl craete -f .

apiVersion: v1
kind: Pod
metadata:
  name: myweb-reqlim
spec:
  containers:
    - name: myweb
      image: ghcr.io/c1t1d0s7/go-myweb
      resources:
        requests:
          cpu: 200m
          memory: 200M
        limits:
          cpu: 300m
          memory: 300M

kubectl replace -f myweb-reqlim.yml --force

노드별 CPU & Memory 사용량 확인

kubectl top node

노드 요청/제한 확인

kubectl describe nodes <노드_이름>

파드별 CPU & Memory 사용량 확인

kubectl top pods
kubectl top pods -A

리소스 모니터링

Heapster 프로젝트(retire)

metric-server: 실시간 CPU/Memory 모니터링

prometheus: 실시간/이전 CPU/Memory/Network/Disk 모니터링

HPA: Horisontal Pod AutoScaler

공식 문서: https://kubernetes.io/ko/docs/tasks/run-application/horizontal-pod-autoscale/

AutoScaling

Pod
- HPA: Scale OUT
- VPA(Vertical Pod AutoScaler): Scale UP
Node
- ClusterScaler

HPA: Deployment, ReplicaSet, StatefulSet 의 복제본 개수를 조정

쿠버네티스에서, HorizontalPodAutoscaler 는 워크로드 리소스(예: 디플로이먼트 또는 스테이트풀셋)를 자동으로 업데이트하며, 워크로드의 크기를 수요에 맞게 자동으로 스케일링하는 것을 목표로 한다.

수평 스케일링은 부하 증가에 대해 파드를 더 배치하는 것을 뜻한다. 이는 수직 스케일링(쿠버네티스에서는, 해당 워크로드를 위해 이미 실행 중인 파드에 더 많은 자원(예: 메모리 또는 CPU)를 할당하는 것)과는 다르다.

부하량이 줄어들고, 파드의 수가 최소 설정값 이상인 경우, HorizontalPodAutoscaler는 워크로드 리소스(디플로이먼트, 스테이트풀셋, 또는 다른 비슷한 리소스)에게 스케일 다운을 지시한다.

Horizontal Pod Autoscaling은 크기 조절이 불가능한 오브젝트(예: 데몬셋)에는 적용할 수 없다.

HorizontalPodAutoscaler는 쿠버네티스 API 자원 및 컨트롤러 형태로 구현되어 있다. HorizontalPodAutoscaler API 자원은 컨트롤러의 행동을 결정한다. 쿠버네티스 컨트롤 플레인 내에서 실행되는 HPA 컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률, 또는 다른 커스텀 메트릭 등의 관측된 메트릭을 목표에 맞추기 위해 목표물(예: 디플로이먼트)의 적정 크기를 주기적으로 조정한다.

HorizontalPodAutoscaler는 디플로이먼트 및 디플로이먼트의 레플리카셋의 크기를 조정한다.

알고리즘 세부 정보

가장 기본적인 관점에서, HorizontalPodAutoscaler 컨트롤러는 원하는(desired) 메트릭 값과 현재(current) 메트릭 값 사이의 비율로 작동한다.

원하는 레플리카 수 = ceil[현재 레플리카 수 * ( 현재 메트릭 값 / 원하는 메트릭 값 )]

예를 들어 현재 메트릭 값이 200m이고 원하는 값이 100m인 경우 200.0 / 100.0 == 2.0이므로 복제본 수가 두 배가 된다. 만약 현재 값이 50m 이면, 50.0 / 100.0 == 0.5 이므로 복제본 수를 반으로 줄일 것이다. 컨트롤 플레인은 비율이 1.0(기본값이 0.1인 -horizontal-pod-autoscaler-tolerance 플래그를 사용하여 전역적으로 구성 가능한 허용 오차 내)에 충분히 가깝다면 스케일링을 건너 뛸 것이다.

targetAverageValue 또는 targetAverageUtilization가 지정되면, currentMetricValue는 HorizontalPodAutoscaler의 스케일 목표 안에 있는 모든 파드에서 주어진 메트릭의 평균을 취하여 계산된다.

허용치를 확인하고 최종 값을 결정하기 전에, 컨트롤 플레인은 누락된 메트릭이 있는지, 그리고 몇 개의 파드가 Ready인지도 고려한다. 삭제 타임스탬프가 설정된 모든 파드(파드에 삭제 타임스탬프가 있으면 셧다운/삭제 중임을 뜻한다)는 무시되며, 모든 실패한 파드는 버려진다.

워크로드 스케일링의 안정성

HorizontalPodAutoscaler를 사용하여 레플리카 그룹의 크기를 관리할 때, 측정하는 메트릭의 동적 특성 때문에 레플리카 수가 계속 자주 요동칠 수 있다. 이는 종종 thrashing 또는 flapping이라고 불린다. 이는 사이버네틱스 분야의 이력 현상(hysteresis) 개념과 비슷하다.

즉, 자주 스케일 인, 스케일 아웃이 계속해서 발생할 경우 성능이 더 떨어지기 때문에 metric monitoring 이 필요하다.

안정화 윈도우

안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카 수의 흔들림을 제한하기 위해 사용된다. 오토스케일링 알고리즘은 이전의 목표 상태를 추론하고 워크로드 수의 원치 않는 변화를 방지하기 위해 이 안정화 윈도우를 활용한다.

예를 들어, 다음 예제 스니펫에서, scaleDown에 대해 안정화 윈도우가 설정되었다.

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300

메트릭 관측 결과 스케일링 목적물이 스케일 다운 되어야 하는 경우, 알고리즘은 이전에 계산된 목표 상태를 확인하고, 해당 구간에서 계산된 값 중 가장 높은 값을 사용한다. 위의 예시에서, 이전 5분 동안의 모든 목표 상태가 고려 대상이 된다.

이를 통해 동적 최대값(rolling maximum)을 근사화하여, 스케일링 알고리즘이 빠른 시간 간격으로 파드를 제거하고 바로 다시 동일한 파드를 재생성하는 현상을 방지할 수 있다.

즉, 5분 동안 스케일링을 하지 않고 기다린 후에 스케일링이 이뤄진다.

예제

반드시 requests, limits 를 설정해줘야 HPA 가 가능하다.

myweb-deploy.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myweb-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 200m
            limits:
              cpu: 200m

myweb-hpa.yml

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: myweb-hpa
spec:
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myweb-deploy

부하 걸기

kubectl exec <POD> -- sha256sum /dev/zero

v2beta2 로 HPA 구성

myweb-hpa-v2beta2.yml

$ cat myweb-hpa-v2beta2.yml
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myweb-hpa
spec:
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 40
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myweb-deploy

[kubernetes] statefulSet

ssunw — Sun, 29 May 2022 15:24:35 +0900

Headless Service

headless 서비스는 Cluster IP 가 none 이다. 즉, 서비스의 IP 가 없는 서비스를 Headless 서비스라고 부른다.

myweb-rs.yml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myweb-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
      env: dev
  template:
    metadata:
      labels:
        app: web
        env: dev
    spec:
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb
          ports:
            - containerPort: 8080
              protocol: TCP

myweb-svc.yml

apiVersion: v1
kind: Service
metadata:
  name: myweb-svc
spec:
  type: ClusterIP
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

myweb-svc-headless.yml

apiVersion: v1
kind: Service
metadata:
  name: myweb-svc-headless
spec:
  type: ClusterIP
  clusterIP: None # <-- Headless Service
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

test

kubectl run nettool -it --image ghcr.io/c1t1d0s7/network-multitool --rm

> host myweb-svc
myweb-svc.default.svc.cluster.local has address 10.233.58.177

> host myweb-svc-headless
myweb-svc-headless.default.svc.cluster.local has address 10.233.81.32
myweb-svc-headless.default.svc.cluster.local has address 10.233.76.27
myweb-svc-headless.default.svc.cluster.local has address 10.233.111.28

host myweb-svc-headless 를 실행하면 myweb-svc-headless 의 서비스 주소가 none 이기 때문에 연결된 Pod 의 IP 주소가 나온다.

스테이트풀셋

공식 문서: https://kubernetes.io/ko/docs/concepts/workloads/controllers/statefulset/

pet vs cattle: http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/

pet 은 고유성, 상태를 가지고 있고 교체 하는 것이 상당히 어렵다. 그에 반해 cattle 고유성이랄게 없고 교체가 아주 쉽고 간단하다.

대표적인 pet 은 RDBMS 가 있다.

스테이트풀셋은 애플리케이션의 스테이트풀을 관리하는데 사용하는 워크로드 API 오브젝트이다.

파드 집합의 디플로이먼트와 스케일링을 관리하며, 파드들의 순서 및 고유성을 보장한다 .

디플로이먼트와 유사하게, 스테이트풀셋은 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다. 디플로이먼트와는 다르게, 스테이트풀셋은 각 파드의 독자성을 유지한다. 이 파드들은 동일한 스팩으로 생성되었지만, 서로 교체는 불가능하다. 다시 말해, 각각은 재스케줄링 간에도 지속적으로 유지되는 식별자를 가진다.

스토리지 볼륨을 사용해서 워크로드에 지속성을 제공하려는 경우, 솔루션의 일부로 스테이트풀셋을 사용할 수 있다. 스테이트풀셋의 개별 파드는 장애에 취약하지만, 퍼시스턴트 파드 식별자는 기존 볼륨을 실패한 볼륨을 대체하는 새 파드에 더 쉽게 일치시킬 수 있다.

스테이트풀셋 사용

스테이트풀셋은 다음 중 하나 또는 이상이 필요한 애플리케이션에 유용하다.

안정된, 고유한 네트워크 식별자.
안정된, 지속성을 갖는 스토리지.
순차적인, 정상 배포(graceful deployment)와 스케일링.
순차적인, 자동 롤링 업데이트.

위의 안정은 파드의 (재)스케줄링 전반에 걸친 지속성과 같은 의미이다. 만약 애플리케이션이 안정적인 식별자 또는 순차적인 배포, 삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카셋(ReplicaSet)을 제공하는 워크로드 오브젝트를 사용해서 애플리케이션을 배포해야 한다. 디플로이먼트 또는 레플리카셋과 같은 컨트롤러가 스테이트리스 요구에 더 적합할 수 있다.

제한사항

파드에 지정된 스토리지는 관리자에 의해 **퍼시스턴트 볼륨 프로비저너(PVC)**를 기반으로 하는 storage class 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다. STS 의 파드들은 각자가 고유성을 가져야 하기 때문에 각각의 파드들은 자신만의 볼륨을 가져야 한다. (.spec.volumeClaimTemplates 사용)
스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 삭제되지 않는다. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다.
스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 헤드리스 서비스가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다.
롤링 업데이트와 기본 파드 매니지먼트 폴리시 (OrderedReady)를 함께 사용시 복구를 위한 수동 개입이 필요한 파손 상태로 빠질 수 있다.

구성요소

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # .spec.template.metadata.labels 와 일치해야 한다
  serviceName: "nginx"
  replicas: 3 # 기본값은 1
  minReadySeconds: 10 # 기본값은 0
  template:
    metadata:
      labels:
        app: nginx # .spec.selector.matchLabels 와 일치해야 한다
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

안정적인 네트워크 신원

스테이트풀셋의 각 파드는 스테이트풀셋의 이름과 파드의 순번에서 호스트 이름을 얻는다. 호스트 이름을 구성하는 패턴은 $(statefulset name)-$(ordinal) 이다. 위의 예시에서 생성된 3개 파드의 이름은 web-0,web-1,web-2 이다.

스테이트풀셋은 스테이트풀셋에 있는 파드의 도메인을 제어하기위해 헤드리스 서비스를 사용할 수 있다. 이 서비스가 관리하는 도메인은 $(service name).$(namespace).svc.cluster.local 의 형식을 가지며, 여기서 "cluster.local"은 클러스터 도메인이다. 각 파드는 생성되면 $(podname).$(governing service domain) 형식을 가지고 일치되는 DNS 서브도메인을 가지며, 여기서 거버닝 서비스(governing service)는 스테이트풀셋의 serviceName 필드에 의해 정의된다.

클러스터에서 DNS가 구성된 방식에 따라, 새로 실행된 파드의 DNS 이름을 즉시 찾지 못할 수 있다. 이 동작은 클러스터의 다른 클라이언트가 파드가 생성되기 전에 파드의 호스트 이름에 대한 쿼리를 이미 보낸 경우에 발생할 수 있다. 네거티브 캐싱(DNS에서 일반적)은 이전에 실패한 조회 결과가 파드가 실행된 후에도 적어도 몇 초 동안 기억되고 재사용됨을 의미한다.

파드를 생성한 후 즉시 파드를 검색해야 하는 경우, 몇 가지 옵션이 있다.

DNS 조회에 의존하지 않고 쿠버네티스 API를 직접(예를 들어 watch 사용) 쿼리한다.
쿠버네티스 DNS 공급자의 캐싱 시간(일반적으로 CoreDNS의 컨피그맵을 편집하는 것을 의미하며, 현재 30초 동안 캐시함)을 줄인다.

제한사항 섹션에서 언급한 것처럼 사용자는 파드의 네트워크 신원을 책임지는 헤드리스 서비스를 생성할 책임이 있다.

여기 클러스터 도메인, 서비스 이름, 스테이트풀셋 이름을 선택을 하고, 그 선택이 스테이트풀셋 파드의 DNS이름에 어떻게 영향을 주는지에 대한 약간의 예시가 있다.

예제 1

myweb-sts.yml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: myweb-sts
spec:
  replicas: 3
  serviceName: myweb-svc-headless
  selector:
    matchLabels:
      app: web
      env: dev
  template:
    metadata:
      labels:
        app: web
        env: dev
    spec:
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb
          ports:
            - containerPort: 8080
              protocol: TCP

myweb-svc-headless

apiVersion: v1
kind: Service
metadata:
  name: myweb-svc-headless
spec:
  type: ClusterIP
  clusterIP: None # <-- Headless Service
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

$ kubectl get sts,po                              
NAME                         READY   AGE
statefulset.apps/myweb-sts   3/3     7m

NAME                                          READY   STATUS    RESTARTS       AGE
pod/myweb-sts-0                               1/1     Running   0              7m
pod/myweb-sts-1                               1/1     Running   0              6m57s
pod/myweb-sts-2                               1/1     Running   0              3m50s
pod/nettool                                   1/1     Running   0              2m2s
pod/nfs-client-provisioner-758f8cd4d6-rt2t8   1/1     Running   1 (141m ago)   21h

파드를 특정해서 해당 파드의 IP 주소를 가져올 수 있다.

kubectl run nettool -it --image ghcr.io/c1t1d0s7/network-multitool --rm

> host myweb-svc-headless
myweb-svc-headless.default.svc.cluster.local has address 10.233.111.30
myweb-svc-headless.default.svc.cluster.local has address 10.233.76.32
myweb-svc-headless.default.svc.cluster.local has address 10.233.81.35

> host myweb-sts-0.myweb-svc-headless
myweb-sts-0.myweb-svc-headless.default.svc.cluster.local has address 10.233.76.32

> host myweb-sts-1.myweb-svc-headless
myweb-sts-1.myweb-svc-headless.default.svc.cluster.local has address 10.233.111.30

> host myweb-sts-2.myweb-svc-headless
myweb-sts-1.myweb-svc-headless.default.svc.cluster.local has address 10.233.111.35

예제 2: PVC 템플릿 사용

myweb-svc-headless.yml

apiVersion: v1
kind: Service
metadata:
  name: myweb-svc-headless
spec:
  type: ClusterIP
  clusterIP: None # <-- Headless Service
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

myweb-sts-vol.yml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: myweb-sts-vol
spec:
  replicas: 3
  serviceName: myweb-svc-headless
  selector:
    matchLabels:
      app: web
      env: dev
  template:
    metadata:
      labels:
        app: web
        env: dev
    spec:
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb:alpine
          ports:
            - containerPort: 8080
              protocol: TCP
          volumeMounts:
            - name: myweb-pvc
              mountPath: /data
  volumeClaimTemplates:
    - metadata:
        name: myweb-pvc
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 1G
        storageClassName: nfs-client

test

kubectl create -f .

$ kubectl get sts,po,pv,pvc
NAME                             READY   AGE
statefulset.apps/myweb-sts-vol   3/3     25s

NAME                                          READY   STATUS    RESTARTS       AGE
pod/myweb-sts-vol-0                           1/1     Running   0              25s
pod/myweb-sts-vol-1                           1/1     Running   0              22s
pod/myweb-sts-vol-2                           1/1     Running   0              19s
pod/nfs-client-provisioner-758f8cd4d6-rt2t8   1/1     Running   1 (164m ago)   21h

NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                               STORAGECLASS   REASON   AGE
persistentvolume/pvc-43f39dc8-b423-4412-bf27-1dffa70829a1   1G         RWO            Delete           Bound    default/myweb-pvc-myweb-sts-vol-1   nfs-client              22s
persistentvolume/pvc-4d5e0960-f9c1-4ed9-bcb8-62482eb9dd84   1G         RWO            Delete           Bound    default/myweb-pvc-myweb-sts-vol-0   nfs-client              25s
persistentvolume/pvc-a3ace980-ef11-4cc9-bce8-a6a49197bd30   1G         RWO            Delete           Bound    default/myweb-pvc-myweb-sts-vol-2   nfs-client              19s

NAME                                              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/myweb-pvc-myweb-sts-vol-0   Bound    pvc-4d5e0960-f9c1-4ed9-bcb8-62482eb9dd84   1G         RWO            nfs-client     25s
persistentvolumeclaim/myweb-pvc-myweb-sts-vol-1   Bound    pvc-43f39dc8-b423-4412-bf27-1dffa70829a1   1G         RWO            nfs-client     22s
persistentvolumeclaim/myweb-pvc-myweb-sts-vol-2   Bound    pvc-a3ace980-ef11-4cc9-bce8-a6a49197bd30   1G         RWO            nfs-client     19s

kubectl scale sts myweb-sts-vol --replicas=2

$ kubectl get sts,po,pv,pvc
NAME                             READY   AGE
statefulset.apps/myweb-sts-vol   2/2     82s

NAME                                          READY   STATUS    RESTARTS       AGE
pod/myweb-sts-vol-0                           1/1     Running   0              82s
pod/myweb-sts-vol-1                           1/1     Running   0              79s
pod/nfs-client-provisioner-758f8cd4d6-rt2t8   1/1     Running   1 (165m ago)   21h

NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                               STORAGECLASS   REASON   AGE
persistentvolume/pvc-43f39dc8-b423-4412-bf27-1dffa70829a1   1G         RWO            Delete           Bound    default/myweb-pvc-myweb-sts-vol-1   nfs-client              79s
persistentvolume/pvc-4d5e0960-f9c1-4ed9-bcb8-62482eb9dd84   1G         RWO            Delete           Bound    default/myweb-pvc-myweb-sts-vol-0   nfs-client              82s
persistentvolume/pvc-a3ace980-ef11-4cc9-bce8-a6a49197bd30   1G         RWO            Delete           Bound    default/myweb-pvc-myweb-sts-vol-2   nfs-client              76s

NAME                                              STATUS   VOLUME
      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/myweb-pvc-myweb-sts-vol-0   Bound    pvc-4d5e0960-f9c1-4ed9-bcb8-62482eb9dd84   1G         RWO            nfs-client     82s
persistentvolumeclaim/myweb-pvc-myweb-sts-vol-1   Bound    pvc-43f39dc8-b423-4412-bf27-1dffa70829a1   1G         RWO            nfs-client     79s
persistentvolumeclaim/myweb-pvc-myweb-sts-vol-2   Bound    pvc-a3ace980-ef11-4cc9-bce8-a6a49197bd30   1G         RWO            nfs-client     76s

$ kubectl scale sts myweb-sts-vol --replicas=4

$ kubectl get sts,po,pv,pvc
NAME                             READY   AGE
statefulset.apps/myweb-sts-vol   4/4     2m27s

NAME                                          READY   STATUS    RESTARTS       AGE
pod/myweb-sts-vol-0                           1/1     Running   0              2m27s
pod/myweb-sts-vol-1                           1/1     Running   0              2m24s
pod/myweb-sts-vol-2                           1/1     Running   0              26s
pod/myweb-sts-vol-3                           1/1     Running   0              24s
pod/nfs-client-provisioner-758f8cd4d6-rt2t8   1/1     Running   1 (166m ago)   21h

NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                               STORAGECLASS   REASON   AGE
persistentvolume/pvc-43f39dc8-b423-4412-bf27-1dffa70829a1   1G         RWO            Delete           Bound    default/myweb-pvc-myweb-sts-vol-1   nfs-client              2m24s
persistentvolume/pvc-4d5e0960-f9c1-4ed9-bcb8-62482eb9dd84   1G         RWO            Delete           Bound    default/myweb-pvc-myweb-sts-vol-0   nfs-client              2m27s
persistentvolume/pvc-542ab02f-acaa-4de3-a28f-fdfeb2b6c82d   1G         RWO            Delete           Bound    default/myweb-pvc-myweb-sts-vol-3   nfs-client              24s
persistentvolume/pvc-a3ace980-ef11-4cc9-bce8-a6a49197bd30   1G         RWO            Delete           Bound    default/myweb-pvc-myweb-sts-vol-2   nfs-client              2m21s

NAME                                              STATUS   VOLUME
      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/myweb-pvc-myweb-sts-vol-0   Bound    pvc-4d5e0960-f9c1-4ed9-bcb8-62482eb9dd84   1G         RWO            nfs-client     2m27s
persistentvolumeclaim/myweb-pvc-myweb-sts-vol-1   Bound    pvc-43f39dc8-b423-4412-bf27-1dffa70829a1   1G         RWO            nfs-client     2m24s
persistentvolumeclaim/myweb-pvc-myweb-sts-vol-2   Bound    pvc-a3ace980-ef11-4cc9-bce8-a6a49197bd30   1G         RWO            nfs-client     2m21s
persistentvolumeclaim/myweb-pvc-myweb-sts-vol-3   Bound    pvc-542ab02f-acaa-4de3-a28f-fdfeb2b6c82d   1G         RWO            nfs-client     24s

각각의 파드들은 고유한 volume 을 가지기 때문에 볼륨의 타입이 nfs 이어도 상관 없이 데이터를 공유하지 않는다.

$ kubectl exec -it myweb-sts-vol-0 -- sh
> cd data/
/data > ls
/data > touch a b c
/data > ls
a  b  c
/data > exit
$ kubectl exec -it myweb-sts-vol-1 -- sh
> cd data/
/data > ls

pod 가 삭제되더라도 volume 은 반영구적으로 남아있다.

$ kubectl delete pod myweb-sts-vol-0
pod "myweb-sts-vol-1" deleted

$ kubectl get po
NAME                                      READY   STATUS    RESTARTS       AGE
myweb-sts-vol-0                           1/1     Running   0              2s
myweb-sts-vol-1                           1/1     Running   0              6m52s
myweb-sts-vol-2                           1/1     Running   0              6m58s
myweb-sts-vol-3                           1/1     Running   0              6m56s
nfs-client-provisioner-758f8cd4d6-rt2t8   1/1     Running   1 (173m ago)   21h

$ kubectl exec -it myweb-sts-vol-0 -- sh
/ > cd data/
/data > ls
a  b  c

예제 3

공식 문서: https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/

statefulse 으로 mysql 파드를 만든다. Master(RW) 와 Read Replicas 들로 구성한다.

ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql
  labels:
    app: mysql
data:
  primary.cnf: |
    # Apply this config only on the primary.
    [mysqld]
    log-bin
  replica.cnf: |
    # Apply this config only on replicas.
    [mysqld]
    super-read-only

Service

# Headless service for stable DNS entries of StatefulSet members.
apiVersion: v1
kind: Service
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  ports:
  - name: mysql
    port: 3306
  clusterIP: None # Headless 서비스
  selector:
    app: mysql
---
# Client service for connecting to any MySQL instance for reads.
# For writes, you must instead connect to the primary: mysql-0.mysql.
apiVersion: v1
kind: Service
metadata:
  name: mysql-read
  labels:
    app: mysql
spec:
  ports:
  - name: mysql
    port: 3306
  selector:
    app: mysql

statefulSet

command 필드를 사용해서 ENTRYPOINT 를 변경한다.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  serviceName: mysql
  replicas: 3
  template:
    metadata:
      labels:
        app: mysql
    spec:
      initContainers:
      - name: init-mysql
        image: mysql:5.7
        command:
        - bash
        - "-c"
        - |
          set -ex
          # Generate mysql server-id from pod ordinal index.
          [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
          ordinal=${BASH_REMATCH[1]}
          echo [mysqld] > /mnt/conf.d/server-id.cnf
          # Add an offset to avoid reserved server-id=0 value.
          echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf
          # Copy appropriate conf.d files from config-map to emptyDir.
          if [[ $ordinal -eq 0 ]]; then
            cp /mnt/config-map/primary.cnf /mnt/conf.d/
          else
            cp /mnt/config-map/replica.cnf /mnt/conf.d/
          fi          
        volumeMounts:
        - name: conf
          mountPath: /mnt/conf.d
        - name: config-map
          mountPath: /mnt/config-map
      - name: clone-mysql
        image: gcr.io/google-samples/xtrabackup:1.0
        command:
        - bash
        - "-c"
        - |
          set -ex
          # Skip the clone if data already exists.
          [[ -d /var/lib/mysql/mysql ]] && exit 0
          # Skip the clone on primary (ordinal index 0).
          [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
          ordinal=${BASH_REMATCH[1]}
          [[ $ordinal -eq 0 ]] && exit 0
          # Clone data from previous peer.
          ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql
          # Prepare the backup.
          xtrabackup --prepare --target-dir=/var/lib/mysql          
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
          subPath: mysql
        - name: conf
          mountPath: /etc/mysql/conf.d
      containers:
      - name: mysql
        image: mysql:5.7
        env:
        - name: MYSQL_ALLOW_EMPTY_PASSWORD
          value: "1"
        ports:
        - name: mysql
          containerPort: 3306
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
          subPath: mysql
        - name: conf
          mountPath: /etc/mysql/conf.d
        resources:
          requests:
            cpu: 500m
            memory: 1Gi
        livenessProbe:
          exec:
            command: ["mysqladmin", "ping"]
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
        readinessProbe:
          exec:
            # Check we can execute queries over TCP (skip-networking is off).
            command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"]
          initialDelaySeconds: 5
          periodSeconds: 2
          timeoutSeconds: 1
      - name: xtrabackup
        image: gcr.io/google-samples/xtrabackup:1.0
        ports:
        - name: xtrabackup
          containerPort: 3307
        command:
        - bash
        - "-c"
        - |
          set -ex
          cd /var/lib/mysql

          # Determine binlog position of cloned data, if any.
          if [[ -f xtrabackup_slave_info && "x$(<xtrabackup_slave_info)" != "x" ]]; then
            # XtraBackup already generated a partial "CHANGE MASTER TO" query
            # because we're cloning from an existing replica. (Need to remove the tailing semicolon!)
            cat xtrabackup_slave_info | sed -E 's/;$//g' > change_master_to.sql.in
            # Ignore xtrabackup_binlog_info in this case (it's useless).
            rm -f xtrabackup_slave_info xtrabackup_binlog_info
          elif [[ -f xtrabackup_binlog_info ]]; then
            # We're cloning directly from primary. Parse binlog position.
            [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1
            rm -f xtrabackup_binlog_info xtrabackup_slave_info
            echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\\
                  MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in
          fi

          # Check if we need to complete a clone by starting replication.
          if [[ -f change_master_to.sql.in ]]; then
            echo "Waiting for mysqld to be ready (accepting connections)"
            until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done

            echo "Initializing replication from clone position"
            mysql -h 127.0.0.1 \\
                  -e "$(<change_master_to.sql.in), \\
                          MASTER_HOST='mysql-0.mysql', \\
                          MASTER_USER='root', \\
                          MASTER_PASSWORD='', \\
                          MASTER_CONNECT_RETRY=10; \\
                        START SLAVE;" || exit 1
            # In case of container restart, attempt this at-most-once.
            mv change_master_to.sql.in change_master_to.sql.orig
          fi

          # Start a server to send backups when requested by peers.
          exec ncat --listen --keep-open --send-only --max-conns=1 3307 -c \\
            "xtrabackup --backup --slave-info --stream=xbstream --host=127.0.0.1 --user=root"          
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
          subPath: mysql
        - name: conf
          mountPath: /etc/mysql/conf.d
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
      volumes:
      - name: conf
        emptyDir: {}
      - name: config-map
        configMap:
          name: mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

test

$ kubectl run nettool -it --image ghcr.io/c1t1d0s7/network-multitool --rm

mysql-0 은 마스터로써 읽기와 쓰기가 모두 가능하고 mysql-1 은 read replica 이다.

/ > mysql -h mysql-0.mysql -u root

MySQL [(none)]> create database test;
Query OK, 1 row affected (0.008 sec)

MySQL [(none)]> show databases;
+------------------------+
| Database               |
+------------------------+
| information_schema     |
| mysql                  |
| performance_schema     |
| sys                    |
| test                   |
| xtrabackup_backupfiles |
+------------------------+
6 rows in set (0.003 sec)

MySQL [(none)]> use test;

MySQL [test]> create table message (message VARCHAR(50));
Query OK, 0 rows affected (0.032 sec)

MySQL [test]> show tables;
+----------------+
| Tables_in_test |
+----------------+
| message        |
+----------------+
1 row in set (0.004 sec)

MySQL [test]> insert into message values ("hello mysql");
Query OK, 1 row affected (0.017 sec)

MySQL [test]> select * from message;
+-------------+
| message     |
+-------------+
| hello mysql |
+-------------+
1 row in set (0.001 sec)

MySQL [(none)]> exit

/ > mysql -h mysql-1.mysql -u root

MySQL [(none)]> show databases;
+------------------------+
| Database               |
+------------------------+
| information_schema     |
| mysql                  |
| performance_schema     |
| sys                    |
| test                   |
| xtrabackup_backupfiles |
+------------------------+
6 rows in set (0.003 sec)

MySQL [(none)]> drop database test;
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

MySQL [(none)]> use test;

MySQL [test]> show tables;
+----------------+
| Tables_in_test |
+----------------+
| message        |
+----------------+
1 row in set (0.004 sec)

MySQL [test]> select * from message;
+-------------+
| message     |
+-------------+
| hello mysql |
+-------------+
1 row in set (0.001 sec)

MySQL [(test)]> exit

[kubernetes] TLS Termination

ssunw — Sun, 29 May 2022 15:23:23 +0900

TLS/SSL Termination with Ingress

위키피디아: https://en.wikipedia.org/wiki/TLS_termination_proxy

SSL 프로토콜은 3.X 버전까지 나왔으며 현재 더 이상 사용하지 않는다.

TLS 는 SSL 프로토콜을 변형해서 만든 프로토콜이다. 현재 1.3 버전까지 나왔다.

클라이언트와 Proxy(LB) 사이에 TLS 를 사용하고 Proxy 와 웹서비스 사이에서는 HTTP 로 통신을 하는 방식이 TLS Termination 이다.

즉, 외부로 노출된 LB 에 클라이언트는 HTTPS 로 통신을 하고 LB 는 뒷단에 연결된 백엔드들과 HTTP 로 통신을 하는 방식을 뜻한다.

이런 구성을 사용하는 이유는 첫번째 LB 뒷단에 연결되는 백엔드들과 HTTPS 로 통신을 할 경우 각각의 백엔드마다 인증서를 관리해줘야 하는데 이가 매우 불편하기 때문에 TLS Termination 구조를 사용하는 것이다.

두번째 수학적인 연산을 하는 작업들 즉, 암복호화 하는데 CPU 를 굉장히 많이 사용하기 때문에 TLS Termination 을 사용한다.

Proxy 와 백엔드도 HTTPS 로 통신하는 End To End 방식일 경우 보안이 좀 더 좋을 것이라고 생각할 수 있지만 꼭 그런 것도 아니다. 사용자가 해커라고 가정할 경우 로드 밸런서로 공격을 보낼 경우 해당 공격도 암호화가 되기 때문에 LB 에서 확인할 방법이 없다. 그래서 백엔드에서 복호화를 한 이후에 WAF, IDS, IPS, Anti DDoS, Anti Vius 등을 사용해서 확인을 해야한다. 이는 매우 좋지 않고 복잡하며 관리적인 측면에서 어려움이 있다.

비암호화 되는 구간이 있어야 백엔드로 도착하기 전에 보안 장치들로 확인을 할 수 있다.

보안적인 관점에서 E to E 가 정말 힘든 작업이다.

코드 작성

ingress-secret.yml

apiVersion: v1
kind: Secret
metadata:
  name: ingress-secret
type: kubernetes.io/tls
data:
  tls.crt: |
    LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUQ1VENDQXMyZ0F3SUJBZ0lVQ2NFOTM4WEZFSnBLYjU2NTlJZE...
	tls.key: |
    LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBMms4YTFBYS96NDRWcGZ...

nginx-deploy.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80
              protocol: TCP

nginx-svc.yml

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - name: http
      port: 80
      targetPort: 80

nginx-ing.yml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
    - hosts:
        - "*.nip.io"
      secretName: ingress-secret
  rules:
    - host: "*.nip.io"
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx-svc
                port:
                  number: 80

ingress 에서 tls 를 셋팅했기 때문에 따로 443 포트를 열지 않고 80 포트를 사용해도 자동으로 443 포트를 열어서 HTTPS 로 리다이렉션 해준다.

[kubernetes] ConfigMap & Secret

ssunw — Sun, 29 May 2022 15:22:15 +0900

ConfigMap & Secret

공식 문서: https://kubernetes.io/ko/docs/concepts/configuration/configmap/

컨피그맵은 키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트이다. 파드는 볼륨에서 환경 변수, 커맨드-라인 인수 또는 **구성 파일(key=파일명, value=내용)**로 컨피그맵을 사용할 수 있다.

주로 설정파일, 인증서, 암호화 키를 제공할 때 ConfigMap 과 Secret 을 사용한다.

컨피그맵을 사용하면 컨테이너 이미지에서 환경별 구성을 분리하여, 애플리케이션을 쉽게 이식할 수 있다.

예제

apiVersion: v1
kind: ConfigMap
metadata:
  name: game-demo
data:
  # 속성과 비슷한 키; 각 키는 간단한 값으로 매핑됨
  player_initial_lives: "3"
  ui_properties_file_name: "user-interface.properties"

  # 파일과 비슷한 키
  game.properties: |
    enemy.types=aliens,monsters
    player.maximum-lives=5    
  user-interface.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true

환경 변수

my-config.yml

apiVersion: v1
kind: ConfigMap
metadata:
  name: mymessage
data:
  MESSAGE: Customized Hello ConfigMap

mymessage 컨피그맵의 모든 키를 환경 변수로 등록한다.

myweb.yml

apiVersion: v1
kind: Pod
metadata:
  name: myweb-env
spec:
  containers:
    - name: myweb
      image: ghcr.io/c1t1d0s7/go-myweb:alpine
      envFrom:
        - configMapRef:
            name: mymessage

valueFrom 필드 사용, mymessage 컨피그맵의 특정 키를 뽑아서 환경 변수로 사용할 수 있다.

apiVersion: v1
kind: Pod
metadata:
  name: myweb-env
spec:
  containers:
    - name: myweb
      image: ghcr.io/c1t1d0s7/go-myweb:alpine
	    env:  
				valueFrom:
					configMapKeyRef:
						key: MESSAGE
						name: mymessage

kubectl exec -it myweb-env -- sh
/ # env
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.233.0.1:443
HOSTNAME=myweb-env
SHLVL=1
HOME=/root
TERM=xterm
KUBERNETES_PORT_443_TCP_ADDR=10.233.0.1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP=tcp://10.233.0.1:443
KUBERNETES_SERVICE_PORT_HTTPS=443
MESSAGE=Customized Hello ConfigMap
KUBERNETES_SERVICE_HOST=10.233.0.1
PWD=/

파일

myweb-cm-vol.yml

apiVersion: v1
kind: Pod
metadata:
  name: myweb-cm-vol
spec:
  containers:
    - name: myweb
      image: ghcr.io/c1t1d0s7/go-myweb:alpine
      volumeMounts:
        - name: cmvol
          mountPath: /myvol
  volumes:
    - name: cmvol
      configMap:
        name: mymessage

my-config.yml

apiVersion: v1
kind: ConfigMap
metadata:
  name: mymessage
data:
  MESSAGE: Customized Hello ConfigMap

Secret

공식 문서: https://kubernetes.io/ko/docs/concepts/configuration/secret/

value 를 base64 로 인코딩하여 encoded data 를 만든다. 암호화라고 하지만 전혀 안전한 방식은 아니다.

그래서 AWS KMS, Hashicorp Vault 와 연동하여 암호화를 하여 안전하게 사용할 수 있다.

시크릿은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를 포함하는 오브젝트이다. 이를 사용하지 않으면 중요한 정보가 파드 spec 이나 컨테이너 이미지에 포함될 수 있다. 시크릿을 사용한다는 것은 사용자의 기밀 데이터를 애플리케이션 코드에 넣을 필요가 없음을 뜻한다.

시크릿은 시크릿을 사용하는 파드와 독립적으로 생성될 수 있기 때문에, 파드를 생성하고, 확인하고, 수정하는 워크플로우 동안 시크릿(그리고 데이터)이 노출되는 것에 대한 위험을 경감시킬 수 있다. 쿠버네티스 및 클러스터에서 실행되는 애플리케이션은 기밀 데이터를 비휘발성 저장소에 쓰는 것을 피하는 것과 같이, 시크릿에 대해 추가 예방 조치를 취할 수도 있다.

시크릿은 컨피그맵과 유사하지만 특별히 기밀 데이터를 보관하기 위한 것이다.

시크릿 타입

시크릿을 생성할 때, Secret 리소스의 type 필드를 사용하거나, (활용 가능하다면) kubectl 의 유사한 특정 커맨드라인 플래그를 사용하여 시크릿의 타입을 명시할 수 있다. 시크릿 타입은 여러 종류의 기밀 데이터를 프로그래밍 방식으로 용이하게 처리하기 위해 사용된다.

쿠버네티스는 일반적인 사용 시나리오를 위해 몇 가지 빌트인 타입을 제공한다. 이 타입은 쿠버네티스가 부과하여 수행되는 검증 및 제약에 따라 달라진다.

Opaque, service-account-token, dockercfg, dockerconfigjson, tls 정도가 중요하다.

mydata.yml

apiVersion: v1
kind: Secret
metadata:
  name: mydata
type: Opaque
data:
  id: YWRtaW4K
  pwd: MTIzNAo=

myweb.yml

apiVersion: v1
kind: Pod
metadata:
  name: myweb-env
spec:
  containers:
    - name: myweb
      image: ghcr.io/c1t1d0s7/go-myweb:alpine
      envFrom:
        - configMapRef:
            name: mymessage

mydata 시크릿의 모든 키를 환경 변수로 등록한다.

myweb.yml

apiVersion: v1
kind: Pod
metadata:
  name: myweb-env
spec:
  containers:
    - name: myweb
      image: ghcr.io/c1t1d0s7/go-myweb:alpine
      envFrom:
        - secretRef:
            name: mymessage

valueFrom 필드 사용, mydata 시크릿의 특정 키를 뽑아서 환경 변수로 사용할 수 있다.

apiVersion: v1
kind: Pod
metadata:
  name: myweb-env
spec:
  containers:
    - name: myweb
      image: ghcr.io/c1t1d0s7/go-myweb:alpine
	    env:  
				valueFrom:
					secretKeyRef:
						key: id
						name: mydata

myweb-cm-vol.yml

apiVersion: v1
kind: Pod
metadata:
  name: myweb-secret-vol
spec:
  containers:
    - name: myweb
      image: ghcr.io/c1t1d0s7/go-myweb:alpine
      volumeMounts:
        - name: secret-vol
          mountPath: /myvol
  volumes:
    - name: secret-vol
      secret:
        name: mydata

Nginx POD 에 HTTPs 적용

Nginx

documentation root: /usr/share/nginx/html
Configuration File: /etc/nginx/conf.d

자체 서명 인증서 생성

Secret 리소스로 생성

Type:

Private key

openssl genrsa -out nginx-tls.key 2048

Public Key

openssl rsa -in nginx-tls.key -pubout -out nginx-tls

CSR

openssl req -new -key nginx-tls.key -out nginx-tls.csr

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) [AU]:KR
State or Province Name (full name) [Some-State]:Seoul
Locality Name (eg, city) []:Seoul
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Dev
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:admin@test.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

CRT(인증서)

원래라면 csr(certificate sign request) 파일을 CA 에 업로드해서 제 3자 인증을 받고 .crt 파일을 가져오면 되지만, 간단하게 자체 서명 인증을 통해 .crt 파일을 만든다.

openssl req -x509 -days 3650 -key nginx-tls.key -in nginx-tls.csr -out nginx-tls.crt

설정 파일

nginx-tls.conf

server {
    listen              80;
    listen              443 ssl;
    server_name         myapp.example.com;
    ssl_certificate     /etc/nginx/ssl/tls.crt;
    ssl_certificate_key /etc/nginx/ssl/tls.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    location / {
        root   /usr/share/nginx/html;
        index  index.html;
    }
}

Secret

base64 x509/nginx-tls.crt -w 0
base64 x509/nginx-tls.key -w 0

apiVersion: v1
kind: Secret
metadata:
	name: nginx-secret
type: kubernetes.io/tls
data:
	tls.crt: |
		LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUQ1VENDQXMyZ0F3SUJBZ0lVQ2NFOTM4WEZFSnBLYjU2NTlJZERTUFBJYmQwd0RRWUpLb1pJaHZjTkFRRUwKQlFBd2dZRXhDekFKQmdOVkJBWVRBa3RTTVE0d0RBWURWUVFJREFWVFpXOTFiREVPTUF3R0ExVUVCd3dGVTJWdgpkV3d4RERBS0JnTlZCQW9NQTBSbGRqRUxNQWtHQTFVRUN3d0NTVlF4R0RBV0JnTlZCQU1NRDNkM2R5NWxlR0Z0CmNHeGxMbU52YlRFZE1Cc0dDU3FHU0liM0RRRUpBUllPWVdSdGFXNUFkR1Z6ZEM1amIyMHdIaGNOTWpJd05USTAKTURjeE5UTTJXaGNOTXpJd05USXhNRGN4TlRNMldqQ0JnVEVMTUFrR0ExVUVCaE1DUzFJeERqQU1CZ05WQkFnTQpCVk5sYjNWc01RNHdEQVlEVlFRSERBVlRaVzkxYkRFTU1Bb0dBMVVFQ2d3RFJHVjJNUXN3Q1FZRFZRUUxEQUpKClZERVlNQllHQTFVRUF3d1BkM2QzTG1WNFlXMXdiR1V1WTI5dE1SMHdHd1lKS29aSWh2Y05BUWtCRmc1aFpHMXAKYmtCMFpYTjBMbU52YlRDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTnBQR3RRRwp2OCtPRmFYeW1rZlBrQVU3cHRodFBjWlZ4bGRYVVV0M2hYZUh5NWRBWjhNSDhFaVRNZXdDRmlmYUNqZHpqcVVmCjZzd1JjVkxBQzJWYkt5bk56Z0U1cVJYMXRhazJDd2Uwb1hRcUFBSE1rY3FJSlJIaTRKRThZVlJZU3p3dUpxZmUKOUZ5N2h5Ri9ZY0xZR05DVmpkYVpKOXR6SnZ3UW85S2VKaEFlcnVNZzZSRmE5UnFEUGxRNFBFbnNaNVRKTllxNApRbmRKRzJQZW8xMHYrUVF6TmUxYmZqOG1CMnFtc0ZmMktIeXdPb3dxNytLMEpKUjl4MlY3ZUtUTzVxU2N6RWdrCk9DQ3VhbFFRcmVBa2xvVUZSZGFYazJuWXFYcUhna3c0UkZIc3JHS3RYQlhsd2ppSVZsWXdMUURKTGxpTFdTNVAKTUx5bis5TEpRQzU0ZHA4Q0F3RUFBYU5UTUZFd0hRWURWUjBPQkJZRUZHZnk1VDZuSDRPYjVDRksrQWd0bktTMwpzNjVaTUI4R0ExVWRJd1FZTUJhQUZHZnk1VDZuSDRPYjVDRksrQWd0bktTM3M2NVpNQThHQTFVZEV3RUIvd1FGCk1BTUJBZjh3RFFZSktvWklodmNOQVFFTEJRQURnZ0VCQUZ0dlhBL1VCN3MvSDhGZHMyZXYxMjZlMU02aEtxTmoKRDhLV0dFMm1taW9hbjF0MVhPZGx1bDc1LzZEa0pkTGxNQVJWaGhUYzhHaVZDK2dqMXF5MVBlekpqQk5ZZDJXMApxVVVOcXYxczd4VmtKdEhpMSs1dlBDNy9OMXBhYXVPVDJXTFdNWlhMVVR4QWxLZmRwRWxHVWFYUzdsK0tLOUxmCjBEVEdxWFROemRsNE8xM2hFU1dkZ1dIQ1ptY0RSc2g5MTUxSG5JaU5vaHRuN1laY2FCL1RSbnJlbDJhRVRkeUYKS3ZablVRZTIvRHdGVzVNcVBMejQvdHYxbVlpWlZoMVN3bjl2ZHV5RG9qSTZUNUhnK0xHblBVOEhUZkg3eVBDUgp4cWRDMkovTnZFNWtOUEViTVF4MUlTMWhOR2o0TDJKVWNJNXEwNm1DM0VMUnpUSXBURi9mMTlRPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
	tls.key: |
		LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBMms4YTFBYS96NDRWcGZLYVI4K1FCVHVtMkcwOXhsWEdWMWRSUzNlRmQ0ZkxsMEJuCnd3ZndTSk14N0FJV0o5b0tOM09PcFIvcXpCRnhVc0FMWlZzcktjM09BVG1wRmZXMXFUWUxCN1NoZENvQUFjeVIKeW9nbEVlTGdrVHhoVkZoTFBDNG1wOTcwWEx1SElYOWh3dGdZMEpXTjFwa24yM01tL0JDajBwNG1FQjZ1NHlEcApFVnIxR29NK1ZEZzhTZXhubE1rMWlyaENkMGtiWTk2alhTLzVCRE0xN1Z0K1B5WUhhcWF3Vi9Zb2ZMQTZqQ3J2CjRyUWtsSDNIWlh0NHBNN21wSnpNU0NRNElLNXFWQkN0NENTV2hRVkYxcGVUYWRpcGVvZUNURGhFVWV5c1lxMWMKRmVYQ09JaFdWakF0QU1rdVdJdFpMazh3dktmNzBzbEFMbmgybndJREFRQUJBb0lCQUdLUFhEbGxZcXUrSmgvcAp5NldvSEFtQXlPN2xRd0tNTHlPM2xFaFNDYnZSWHlWR09wSmV2eWpFNjhEMW9ETVZ5WThIYU5zNzhiRjRIb1dSCmxwT0grWkRDRGNPWDJMTEZYK0twTjRtZkQxVjJzTklmSGFNbW5EWGJEREFGNXB0QjBaVzE4RlhSM3RrUEFROHEKaDJTRVU0KzROWFV4YUVFM1Y5NXRWTWorQllrNHU0eDM0bnZ2enJwdGFISER3QmVUOGdqYU9XbXMrd2lQWk5uZgpzanJGRWJ4VTZGeFZSazlWSEF3SGlTZ2ZPbGdOeFlzU25zYU85ZGtrV05GU0I1Mi8vVXRKK0szRnZrV3JLUG1qCmJYN3FtSlNaeHJFN09SeXFhK3lqZkZBWmYrajkxalczL09MNkM2ajNPMFRXV05aTlA1RjRldHFYZVBiN1lIMmkKOUcwb01jRUNnWUVBOG5qc1dUZnVmUVZYQVBLWHZGOW1UQUtsU0lzL3Vua2t3RVloWFh1WGtFRU9wOExEaVN2WQpwSnFzT3NUSlRRaE5mM0g0dWg4Rkl5SHFSb3BlS3VYYy9jSmFsRTFUejREZUN0d2c5R0xjVHpuaGV1RVVsTWhnCnNycVFucjFDTDJtRHd1MTFLL0w0MURHTkNaWFEyYWNmT1pYcCtLdkEzV0ZheVRLNzRDbHNKY2tDZ1lFQTVuMFMKYVlvQy9saEhHeGRqeDdOQTZUNDJVV1grMTFaRTZSSGRKWWtTa3NQWXdhYzlYUnFLWHlzcytrUnY4U2tUaUZMOAp5dnlRcjFyaWlGRWp6VkN2YjA5WjllRWw3UngyT3F3eEpISEJ3bFdKWUEvRFdLN3ZkbHdvZ21wbUhCVzdaQ1k1ClBRVVJSOWhmbC9TVk1selVjSFpyK1J1QmhqWElhTFd2KzdBM2pTY0NnWUFJeHArblN3THl1M0src2drVDVGQUwKaUR6N055OERUTWNydmw0T3lCNWdOanFWajlNTDcrNVRadFc4K3NwZVkyS0tybEZXU3pFZ2FHWFdUOFBBd2JrUgo1aXJwR3pOaFcwU3VGL0dKWnRxYWMzblp2TFBGL3NxaExXZDJsMXNCNUV2RWpsdWpUNVA1K2lFa3E2dDNkVGtJCkdJanpXeVFMM3k0dUFnd1N2TzBSSVFLQmdCVlZha2plZjF4dmExVjBtc1czTDhEbkF6d1JocjhEdXlrZmdDcWoKUDFiYVRjdk80UDBuSWJ1aFVXNXd1elBGSzR1b3NzRlBFMDFIeWtQM3pxcUlWMVNrTVoxeWs0SVk2bENQODVSOQord016eTUxYW1DZ3pPUExwb001QmJ1WVdsTnUyTmdJUjRBR1lZM0M3TUx3U240OHhSdGt0MUpWSmtSMHdBL1AxCjRZNXRBb0dCQUpHTlJKK3plRmdnR25OK25NdjNVa0ZTVDYxMEp3bi9QeWdUYTZPK3FZMlp0dHFITTBYKzRGM04KalpiSGpmTHlZZS9JaWZNMVpKR1M1ZUxTc0xjOFBjM0NaRUF3S05VUDkvQ2xsTCthamhibmwrdHRJOVBBZTFGeQorU1JSSVlPV1pZakFMNC82ZkNjL0UxY3g1OW9UVzR4eHBFRUtEck5rckxIY09iUTcxVVNuCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==

ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
	name: nginx-conf
data:  

server-conf: |
server {
    listen              80;
    listen              443 ssl;
    server_name         myapp.example.com;
    ssl_certificate     /etc/nginx/ssl/tls.crt;
    ssl_certificate_key /etc/nginx/ssl/tls.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    location / {
        root   /usr/share/nginx/html;
        index  index.html;
    }
}

Pod 생성

apiVersion: v1
kind: Pod
metadata:
	name: nginx-https-pod
	labels:
		app: nginx
spec:
	containers:
		- name: nginx
			image: nginx
			volumeMounts:
				- name: confvol
					mountPath: /etc/nginx/conf.d
				- name: secvol
					mountPath: /etc/nginx/ssl
	volumes:
		- name: confvol
			configMap:
				name: nginx-conf
		- name: secvol
			secret:
				name: nginx-secret

Service

apiVersion:
kind: Service
metadata:
	name: nginx-svc
spec:
	type: LoadBalancer
	selector:
		app: nginx
	ports:
		- name: http
			port: 80
			targetPort:80
		- name: httpsp
			port: 443
			targetPort: 443

Test

curl --insecure

Welcome to nginx!

If you see this page, the nginx web server is successfully installed and working. Further configuration is required.

For online documentation and support please refer to nginx.org.
Commercial support is available at nginx.com.

Thank you for using nginx.

ConfigMap & Secret

공식 문서: https://kubernetes.io/ko/docs/concepts/configuration/configmap/

주로 설정파일, 인증서, 암호화 키를 제공할 때 ConfigMap 과 Secret 을 사용한다.

컨피그맵을 사용하면 컨테이너 이미지에서 환경별 구성을 분리하여, 애플리케이션을 쉽게 이식할 수 있다.

예제

apiVersion: v1
kind: ConfigMap
metadata:
  name: game-demo
data:
  # 속성과 비슷한 키; 각 키는 간단한 값으로 매핑됨
  player_initial_lives: "3"
  ui_properties_file_name: "user-interface.properties"

  # 파일과 비슷한 키
  game.properties: |
    enemy.types=aliens,monsters
    player.maximum-lives=5    
  user-interface.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true

환경 변수

my-config.yml

apiVersion: v1
kind: ConfigMap
metadata:
  name: mymessage
data:
  MESSAGE: Customized Hello ConfigMap

mymessage 컨피그맵의 모든 키를 환경 변수로 등록한다.

myweb.yml

apiVersion: v1
kind: Pod
metadata:
  name: myweb-env
spec:
  containers:
    - name: myweb
      image: ghcr.io/c1t1d0s7/go-myweb:alpine
      envFrom:
        - configMapRef:
            name: mymessage

valueFrom 필드 사용, mymessage 컨피그맵의 특정 키를 뽑아서 환경 변수로 사용할 수 있다.

apiVersion: v1
kind: Pod
metadata:
  name: myweb-env
spec:
  containers:
    - name: myweb
      image: ghcr.io/c1t1d0s7/go-myweb:alpine
	    env:  
				valueFrom:
					configMapKeyRef:
						key: MESSAGE
						name: mymessage

kubectl exec -it myweb-env -- sh
/ # env
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.233.0.1:443
HOSTNAME=myweb-env
SHLVL=1
HOME=/root
TERM=xterm
KUBERNETES_PORT_443_TCP_ADDR=10.233.0.1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP=tcp://10.233.0.1:443
KUBERNETES_SERVICE_PORT_HTTPS=443
MESSAGE=Customized Hello ConfigMap
KUBERNETES_SERVICE_HOST=10.233.0.1
PWD=/

파일

myweb-cm-vol.yml

apiVersion: v1
kind: Pod
metadata:
  name: myweb-cm-vol
spec:
  containers:
    - name: myweb
      image: ghcr.io/c1t1d0s7/go-myweb:alpine
      volumeMounts:
        - name: cmvol
          mountPath: /myvol
  volumes:
    - name: cmvol
      configMap:
        name: mymessage

my-config.yml

apiVersion: v1
kind: ConfigMap
metadata:
  name: mymessage
data:
  MESSAGE: Customized Hello ConfigMap

Secret

공식 문서: https://kubernetes.io/ko/docs/concepts/configuration/secret/

value 를 base64 로 인코딩하여 encoded data 를 만든다. 암호화라고 하지만 전혀 안전한 방식은 아니다.

그래서 AWS KMS, Hashicorp Vault 와 연동하여 암호화를 하여 안전하게 사용할 수 있다.

시크릿은 컨피그맵과 유사하지만 특별히 기밀 데이터를 보관하기 위한 것이다.

시크릿 타입

Opaque, service-account-token, dockercfg, dockerconfigjson, tls 정도가 중요하다.

mydata.yml

apiVersion: v1
kind: Secret
metadata:
  name: mydata
type: Opaque
data:
  id: YWRtaW4K
  pwd: MTIzNAo=

myweb.yml

apiVersion: v1
kind: Pod
metadata:
  name: myweb-env
spec:
  containers:
    - name: myweb
      image: ghcr.io/c1t1d0s7/go-myweb:alpine
      envFrom:
        - configMapRef:
            name: mymessage

mydata 시크릿의 모든 키를 환경 변수로 등록한다.

myweb.yml

apiVersion: v1
kind: Pod
metadata:
  name: myweb-env
spec:
  containers:
    - name: myweb
      image: ghcr.io/c1t1d0s7/go-myweb:alpine
      envFrom:
        - secretRef:
            name: mymessage

valueFrom 필드 사용, mydata 시크릿의 특정 키를 뽑아서 환경 변수로 사용할 수 있다.

apiVersion: v1
kind: Pod
metadata:
  name: myweb-env
spec:
  containers:
    - name: myweb
      image: ghcr.io/c1t1d0s7/go-myweb:alpine
	    env:  
				valueFrom:
					secretKeyRef:
						key: id
						name: mydata

myweb-cm-vol.yml

apiVersion: v1
kind: Pod
metadata:
  name: myweb-secret-vol
spec:
  containers:
    - name: myweb
      image: ghcr.io/c1t1d0s7/go-myweb:alpine
      volumeMounts:
        - name: secret-vol
          mountPath: /myvol
  volumes:
    - name: secret-vol
      secret:
        name: mydata

Nginx POD 에 HTTPs 적용

Nginx

documentation root: /usr/share/nginx/html
Configuration File: /etc/nginx/conf.d

자체 서명 인증서 생성

Secret 리소스로 생성

Type:

Private key

openssl genrsa -out nginx-tls.key 2048

Public Key

openssl rsa -in nginx-tls.key -pubout -out nginx-tls

CSR

openssl req -new -key nginx-tls.key -out nginx-tls.csr

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) [AU]:KR
State or Province Name (full name) [Some-State]:Seoul
Locality Name (eg, city) []:Seoul
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Dev
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:admin@test.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

CRT(인증서)

openssl req -x509 -days 3650 -key nginx-tls.key -in nginx-tls.csr -out nginx-tls.crt

설정 파일

nginx-tls.conf

server {
    listen              80;
    listen              443 ssl;
    server_name         myapp.example.com;
    ssl_certificate     /etc/nginx/ssl/tls.crt;
    ssl_certificate_key /etc/nginx/ssl/tls.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    location / {
        root   /usr/share/nginx/html;
        index  index.html;
    }
}

Secret

base64 x509/nginx-tls.crt -w 0
base64 x509/nginx-tls.key -w 0

apiVersion: v1
kind: Secret
metadata:
	name: nginx-secret
type: kubernetes.io/tls
data:
	tls.crt: |
		LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUQ1VENDQXMyZ0F3SUJBZ0lVQ2NFOTM4WEZFSnBLYjU2NTlJZERTUFBJYmQwd0RRWUpLb1pJaHZjTkFRRUwKQlFBd2dZRXhDekFKQmdOVkJBWVRBa3RTTVE0d0RBWURWUVFJREFWVFpXOTFiREVPTUF3R0ExVUVCd3dGVTJWdgpkV3d4RERBS0JnTlZCQW9NQTBSbGRqRUxNQWtHQTFVRUN3d0NTVlF4R0RBV0JnTlZCQU1NRDNkM2R5NWxlR0Z0CmNHeGxMbU52YlRFZE1Cc0dDU3FHU0liM0RRRUpBUllPWVdSdGFXNUFkR1Z6ZEM1amIyMHdIaGNOTWpJd05USTAKTURjeE5UTTJXaGNOTXpJd05USXhNRGN4TlRNMldqQ0JnVEVMTUFrR0ExVUVCaE1DUzFJeERqQU1CZ05WQkFnTQpCVk5sYjNWc01RNHdEQVlEVlFRSERBVlRaVzkxYkRFTU1Bb0dBMVVFQ2d3RFJHVjJNUXN3Q1FZRFZRUUxEQUpKClZERVlNQllHQTFVRUF3d1BkM2QzTG1WNFlXMXdiR1V1WTI5dE1SMHdHd1lKS29aSWh2Y05BUWtCRmc1aFpHMXAKYmtCMFpYTjBMbU52YlRDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTnBQR3RRRwp2OCtPRmFYeW1rZlBrQVU3cHRodFBjWlZ4bGRYVVV0M2hYZUh5NWRBWjhNSDhFaVRNZXdDRmlmYUNqZHpqcVVmCjZzd1JjVkxBQzJWYkt5bk56Z0U1cVJYMXRhazJDd2Uwb1hRcUFBSE1rY3FJSlJIaTRKRThZVlJZU3p3dUpxZmUKOUZ5N2h5Ri9ZY0xZR05DVmpkYVpKOXR6SnZ3UW85S2VKaEFlcnVNZzZSRmE5UnFEUGxRNFBFbnNaNVRKTllxNApRbmRKRzJQZW8xMHYrUVF6TmUxYmZqOG1CMnFtc0ZmMktIeXdPb3dxNytLMEpKUjl4MlY3ZUtUTzVxU2N6RWdrCk9DQ3VhbFFRcmVBa2xvVUZSZGFYazJuWXFYcUhna3c0UkZIc3JHS3RYQlhsd2ppSVZsWXdMUURKTGxpTFdTNVAKTUx5bis5TEpRQzU0ZHA4Q0F3RUFBYU5UTUZFd0hRWURWUjBPQkJZRUZHZnk1VDZuSDRPYjVDRksrQWd0bktTMwpzNjVaTUI4R0ExVWRJd1FZTUJhQUZHZnk1VDZuSDRPYjVDRksrQWd0bktTM3M2NVpNQThHQTFVZEV3RUIvd1FGCk1BTUJBZjh3RFFZSktvWklodmNOQVFFTEJRQURnZ0VCQUZ0dlhBL1VCN3MvSDhGZHMyZXYxMjZlMU02aEtxTmoKRDhLV0dFMm1taW9hbjF0MVhPZGx1bDc1LzZEa0pkTGxNQVJWaGhUYzhHaVZDK2dqMXF5MVBlekpqQk5ZZDJXMApxVVVOcXYxczd4VmtKdEhpMSs1dlBDNy9OMXBhYXVPVDJXTFdNWlhMVVR4QWxLZmRwRWxHVWFYUzdsK0tLOUxmCjBEVEdxWFROemRsNE8xM2hFU1dkZ1dIQ1ptY0RSc2g5MTUxSG5JaU5vaHRuN1laY2FCL1RSbnJlbDJhRVRkeUYKS3ZablVRZTIvRHdGVzVNcVBMejQvdHYxbVlpWlZoMVN3bjl2ZHV5RG9qSTZUNUhnK0xHblBVOEhUZkg3eVBDUgp4cWRDMkovTnZFNWtOUEViTVF4MUlTMWhOR2o0TDJKVWNJNXEwNm1DM0VMUnpUSXBURi9mMTlRPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
	tls.key: |
		LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBMms4YTFBYS96NDRWcGZLYVI4K1FCVHVtMkcwOXhsWEdWMWRSUzNlRmQ0ZkxsMEJuCnd3ZndTSk14N0FJV0o5b0tOM09PcFIvcXpCRnhVc0FMWlZzcktjM09BVG1wRmZXMXFUWUxCN1NoZENvQUFjeVIKeW9nbEVlTGdrVHhoVkZoTFBDNG1wOTcwWEx1SElYOWh3dGdZMEpXTjFwa24yM01tL0JDajBwNG1FQjZ1NHlEcApFVnIxR29NK1ZEZzhTZXhubE1rMWlyaENkMGtiWTk2alhTLzVCRE0xN1Z0K1B5WUhhcWF3Vi9Zb2ZMQTZqQ3J2CjRyUWtsSDNIWlh0NHBNN21wSnpNU0NRNElLNXFWQkN0NENTV2hRVkYxcGVUYWRpcGVvZUNURGhFVWV5c1lxMWMKRmVYQ09JaFdWakF0QU1rdVdJdFpMazh3dktmNzBzbEFMbmgybndJREFRQUJBb0lCQUdLUFhEbGxZcXUrSmgvcAp5NldvSEFtQXlPN2xRd0tNTHlPM2xFaFNDYnZSWHlWR09wSmV2eWpFNjhEMW9ETVZ5WThIYU5zNzhiRjRIb1dSCmxwT0grWkRDRGNPWDJMTEZYK0twTjRtZkQxVjJzTklmSGFNbW5EWGJEREFGNXB0QjBaVzE4RlhSM3RrUEFROHEKaDJTRVU0KzROWFV4YUVFM1Y5NXRWTWorQllrNHU0eDM0bnZ2enJwdGFISER3QmVUOGdqYU9XbXMrd2lQWk5uZgpzanJGRWJ4VTZGeFZSazlWSEF3SGlTZ2ZPbGdOeFlzU25zYU85ZGtrV05GU0I1Mi8vVXRKK0szRnZrV3JLUG1qCmJYN3FtSlNaeHJFN09SeXFhK3lqZkZBWmYrajkxalczL09MNkM2ajNPMFRXV05aTlA1RjRldHFYZVBiN1lIMmkKOUcwb01jRUNnWUVBOG5qc1dUZnVmUVZYQVBLWHZGOW1UQUtsU0lzL3Vua2t3RVloWFh1WGtFRU9wOExEaVN2WQpwSnFzT3NUSlRRaE5mM0g0dWg4Rkl5SHFSb3BlS3VYYy9jSmFsRTFUejREZUN0d2c5R0xjVHpuaGV1RVVsTWhnCnNycVFucjFDTDJtRHd1MTFLL0w0MURHTkNaWFEyYWNmT1pYcCtLdkEzV0ZheVRLNzRDbHNKY2tDZ1lFQTVuMFMKYVlvQy9saEhHeGRqeDdOQTZUNDJVV1grMTFaRTZSSGRKWWtTa3NQWXdhYzlYUnFLWHlzcytrUnY4U2tUaUZMOAp5dnlRcjFyaWlGRWp6VkN2YjA5WjllRWw3UngyT3F3eEpISEJ3bFdKWUEvRFdLN3ZkbHdvZ21wbUhCVzdaQ1k1ClBRVVJSOWhmbC9TVk1selVjSFpyK1J1QmhqWElhTFd2KzdBM2pTY0NnWUFJeHArblN3THl1M0src2drVDVGQUwKaUR6N055OERUTWNydmw0T3lCNWdOanFWajlNTDcrNVRadFc4K3NwZVkyS0tybEZXU3pFZ2FHWFdUOFBBd2JrUgo1aXJwR3pOaFcwU3VGL0dKWnRxYWMzblp2TFBGL3NxaExXZDJsMXNCNUV2RWpsdWpUNVA1K2lFa3E2dDNkVGtJCkdJanpXeVFMM3k0dUFnd1N2TzBSSVFLQmdCVlZha2plZjF4dmExVjBtc1czTDhEbkF6d1JocjhEdXlrZmdDcWoKUDFiYVRjdk80UDBuSWJ1aFVXNXd1elBGSzR1b3NzRlBFMDFIeWtQM3pxcUlWMVNrTVoxeWs0SVk2bENQODVSOQord016eTUxYW1DZ3pPUExwb001QmJ1WVdsTnUyTmdJUjRBR1lZM0M3TUx3U240OHhSdGt0MUpWSmtSMHdBL1AxCjRZNXRBb0dCQUpHTlJKK3plRmdnR25OK25NdjNVa0ZTVDYxMEp3bi9QeWdUYTZPK3FZMlp0dHFITTBYKzRGM04KalpiSGpmTHlZZS9JaWZNMVpKR1M1ZUxTc0xjOFBjM0NaRUF3S05VUDkvQ2xsTCthamhibmwrdHRJOVBBZTFGeQorU1JSSVlPV1pZakFMNC82ZkNjL0UxY3g1OW9UVzR4eHBFRUtEck5rckxIY09iUTcxVVNuCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==

ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
	name: nginx-conf
data:  

server-conf: |
server {
    listen              80;
    listen              443 ssl;
    server_name         myapp.example.com;
    ssl_certificate     /etc/nginx/ssl/tls.crt;
    ssl_certificate_key /etc/nginx/ssl/tls.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    location / {
        root   /usr/share/nginx/html;
        index  index.html;
    }
}

Pod 생성

apiVersion: v1
kind: Pod
metadata:
	name: nginx-https-pod
	labels:
		app: nginx
spec:
	containers:
		- name: nginx
			image: nginx
			volumeMounts:
				- name: confvol
					mountPath: /etc/nginx/conf.d
				- name: secvol
					mountPath: /etc/nginx/ssl
	volumes:
		- name: confvol
			configMap:
				name: nginx-conf
		- name: secvol
			secret:
				name: nginx-secret

Service

apiVersion:
kind: Service
metadata:
  name: nginx-svc
spec:
  type: LoadBalancer
  selector:
	app: nginx
  ports:
	- name: http
		port: 80
		targetPort:80
	- name: httpsp
		port: 443
		targetPort: 443

Test

curl --insecure https://192.168.100.240
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

[kubernetes] NFS 동적 프로비저닝

ssunw — Sun, 29 May 2022 15:19:42 +0900

NFS 동적 프로비저닝

공식 문서: https://kubernetes.io/ko/docs/concepts/storage/storage-classes/#프로비저너

https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner

깃허브에서 코드를 다운로드 받는다.

역할을 만드는 rbac.yaml 파일을 실행한다.

cd ~

git clone <https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner.git>

cd ~/nfs-subdir-external-provisioner/deploy

kubectl create -f rbac.yaml

deployment.yaml 에서 실제 NFS Server 의 주소와 마운트되는 NFS 경로를 작성한 후에 파일을 실행한다.

~/nfs-subdir-external-provisioner/deploy/deployment.yaml

...
...
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: k8s-sigs.io/nfs-subdir-external-provisioner
            - name: NFS_SERVER
              value: 192.168.100.100
            - name: NFS_PATH
              value: /nfsvolume
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.100.100
            path: /nfsvolume

kubectl create -f deployment.yaml

kubectl create -f class.yaml

스토리지 클래스를 생성하는 class.yml 파일을 실행한다.

annotations 필드를 추가해서 생성되는 스토리지 클래스가 디폴트가 되도록 설정할 수 있다.

~/nfs-subdir-external-provisioner/class.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-client
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner # or choose another name, must match deployment's env PROVISIONER_NAME'
parameters:
  archiveOnDelete: "false"

kubectl apply -f class.yaml

class.yaml 에서 디폴트 스토리지 클래스를 설정했기 때문에 StorageClassName 를 작성하지 않아도 pvc 가 자동으로 설정된다.

mypvc.yml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc-dynamic
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1G
  # StorageClassName: 'nfs-cline'

kubectl get pv
NAME            ...
mypvc-dynamic   ...

[kubernetes] deployment

ssunw — Sun, 29 May 2022 15:19:02 +0900

디플로이먼트

공식 문서: https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment/

디플로이먼트(Deployment) 는 파드와 레플리카셋(ReplicaSet)에 대한 선언적 업데이트를 제공한다.

디플로이먼트에서 의도하는 상태 를 설명하고, 디플로이먼트 컨트롤러(Controller)는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다.

Use Case

다음은 디플로이먼트의 일반적인 사례이다.

레플리카셋을 롤아웃 할 디플로이먼트 생성. 레플리카셋은 백그라운드에서 파드를 생성한다. 롤아웃 상태를 체크해서 성공 여부를 확인한다.
디플로이먼트의 PodTemplateSpec을 업데이트해서 파드의 새로운 상태를 선언한다. 새 레플리카셋이 생성되면, 디플로이먼트는 파드를 기존 레플리카셋에서 새로운 레플리카셋으로 속도를 제어하며 이동하는 것을 관리한다. 각각의 새로운 레플리카셋은 디플로이먼트의 수정 버전에 따라 업데이트한다.
만약 디플로이먼트의 현재 상태가 안정적이지 않은 경우 디플로이먼트의 이전 버전으로 롤백한다. 각 롤백은 디플로이먼트의 수정 버전에 따라 업데이트한다.
더 많은 로드를 위해 디플로이먼트의 스케일 업.
디플로이먼트 롤아웃 일시 중지로 PodTemplateSpec에 여러 수정 사항을 적용하고, 재개하여 새로운 롤아웃을 시작한다.
롤아웃이 막혀있는지를 나타내는 디플로이먼트 상태를 이용.
더 이상 필요 없는 이전 레플리카셋 정리.

애플리케이션 배포 전략

어플리케이션 배포 전략: https://thenewstack.io/deployment-strategies/

Recreate

Pros

배포 설정하기가 아주 쉽다.
애플리케이션 상태가 완전히 갱신된다.

Cons

다운 타임이 발생한다. 그렇기 때문에 계획된 다운 타임을 사용하여 특정 시간에 서비스를 사용하지 못하게 하고 앱을 업데이트 한다.

Ramped(롤링 업데이트)

레플리카셋이 공존하고있는 상태로 하나씩 순차적으로 업데이트하는 방식이다.

Pros

배포 설정하기가 아주 쉽다.
업데이트가 인스턴스 간에 천천히 릴리스된다.
데이터 재조정을 처리할 수 있는 상태 저장 애플리케이션에 편리하다.
무중단 시스템이다.

Cons

롤아웃/롤백에 시간이 걸린다.
API 가 변경되는 경우 API 를 지원하는 데 문제가 발생한다.
트래픽을 컨트롤할 방법이 없다.

Blue/Green

recreate 와 비슷하지만 업데이트할 버전의 리소스를 미리 만들어놓은 후에 버전 업그레이드를 한다.

Pros

롤아웃/롤백을 즉각적으로 할 수 있다.
버전 관리 문제를 피할 수 있고, 전체 애플리케이션 상태가 한 번에 변경된다.

Cons

리소스를 더 많이 사용하여 비용이 많이 든다.
프로덕션에 배포하기 전에 전체 플랫폼에 대한 적절한 테스트를 수행해야 한다.
stateful 애플리케이션을 처리하는 것이 어렵다.

Canary

일부 트래픽을 업데이트하려는 버전으로 보내고 테스팅을 하며 문제가 있으면 해결하고 문제가 없으면 트래픽을 더 늘리는 방식이다.

Pros

일부 사용자를 위해 출시된 버전입니다.
오류나 성능 모니터링 하기에 매우 좋다.
롤백이 매우 빠르다.

Cons

롤아웃이 매우 느리다.

A/B testing

A/B 테스트 배포는 특정 종류를 테스팅할 때 사용한다. 브라우저 쿠키, 쿼리 파라미터, 지리적 위 등을 사용하여 다른 버전으로 라우팅되게 한다. 예를 들어, 모바일 사용자와 데스크톱 사용자가 사용하는 배포 버전을 다르게 하여 테스팅하는 방식이 될 수 있다.

Pros

여러 버전이 병렬로 실행된다.
트래픽 분산을 완벽하게 제어한다.

Cons

intelligent 로드 밸런서가 필요하다.
주어진 세션에 대한 오류를 해결하기 어렵기 때문에 분산 추적이 필수이다.

Shadow

로드 밸런서가 클라이언트로부터 받은 트래픽을 현재 버전과 업데이트 하려는 버전으로 모두 전송된다.

Pros

프로덕션 레벨에서 받은 트래픽으로 업그레이드 버전의 성능을 테스트 할 수 있다.
사용자에게 영향이 없다.
애플리케이션의 안정성과 성능이 요구 사항을 충족할 때까지 롤아웃이 없다.

Cons

두 배의 리소스가 필요하므로 비용이 많이 든다.
실제 사용자 테스트가 아니기 때문에 오해의 소지가 있다.
설정이 복잡하다.
특정 경우에 모의 서비스가 필요하다.

디플로이먼트 Rollout

apiVersion: v1
kind: Service
metadata:
  name: myweb-svc-lb
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myweb-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb:v1.0
          ports:
            - containerPort: 8080

Deployment → RS → Pod

kubectl rollout status deploy myweb-deploy

kubectl rollout history deploy myweb-deploy

kubectl set image deployments myweb-deploy myweb=ghcr.io/c1t1d0s7/go-myweb:v2.0 --record

디플로이먼트 전략

.spec.strategy 는 이전 파드를 새로운 파드로 대체하는 전략을 명시한다. .spec.strategy.type 은 "재생성" 또는 "롤링업데이트"가 될 수 있다. "롤링업데이트"가 기본값이다.

디플로이먼트 롤링 업데이트

디플로이먼트는 .spec.strategy.type==RollingUpdate 이면 파드를 롤링 업데이트 방식으로 업데이트 한다. maxUnavailable 와 maxSurge 를 명시해서 롤링 업데이트 프로세스를 제어할 수 있다.

최대 불가(Max Unavailable)

.spec.strategy.rollingUpdate.maxUnavailable 은 업데이트 프로세스 중에 사용할 수 없는 최대 파드의 수를 지정하는 선택적 필드이다. 이 값은 절대 숫자(예: 5) 또는 의도한 파드 비율(예: 10%)이 될 수 있다. 절대 값은 내림해서 백분율로 계산한다. 만약 .spec.strategy.rollingUpdate.maxSurge 가 0이면 값이 0이 될 수 없다. 기본 값은 25% 이다.

예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 즉각 이전 레플리카셋의 크기를 의도한 파드 중 70%를 스케일 다운할 수 있다. 새 파드가 준비되면 기존 레플리카셋을 스케일 다운할 수 있으며, 업데이트 중에 항상 사용 가능한 전체 파드의 수는 의도한 파드의 수의 70% 이상이 되도록 새 레플리카셋을 스케일 업할 수 있다.

최대 서지(Max Surge)

.spec.strategy.rollingUpdate.maxSurge 는 의도한 파드의 수에 대해 생성할 수 있는 최대 파드의 수를 지정하는 선택적 필드이다. 이 값은 절대 숫자(예: 5) 또는 의도한 파드 비율(예: 10%)이 될 수 있다. MaxUnavailable 값이 0이면 이 값은 0이 될 수 없다. 절대 값은 올림해서 백분율로 계산한다. 기본 값은 25% 이다.

예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 새 레플리카셋의 크기를 즉시 조정해서 기존 및 새 파드의 전체 갯수를 의도한 파드의 130%를 넘지 않도록 한다. 기존 파드가 죽으면 새로운 래플리카셋은 스케일 업할 수 있으며, 업데이트하는 동안 항상 실행하는 총 파드의 수는 최대 의도한 파드의 수의 130%가 되도록 보장한다.

즉, 최대 서지 값이 많으면 많을수록 기존의 파드를 삭제하지 않고 서지 값만큼 Rollout 이 가능하다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myweb-deploy
  annotations:
    kubernetes.io/change-cause: "Go Myweb version from 2 to 4"
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailabe: 1
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb:v4.0
          ports:
            - containerPort: 8080

진행 기한 시간(초)

.spec.progressDeadlineSeconds 는 디플로어먼트가 표면적으로 type: Progressing, status: "False"의 상태 그리고 리소스가 reason: ProgressDeadlineExceeded 상태로 진행 실패를 보고하기 전에 디플로이먼트가 진행되는 것을 대기시키는 시간(초)를 명시하는 선택적 필드이다. 디플로이먼트 컨트롤러는 디플로이먼트를 계속 재시도 한다. 기본값은 600(초)이다. 미래에 자동화된 롤백이 구현된다면 디플로이먼트 컨트롤러는 상태를 관찰하고, 그 즉시 디플로이먼트를 롤백할 것이다.

만약 명시된다면 이 필드는 .spec.minReadySeconds 보다 커야 한다.

최소 대기 시간(초)

.spec.minReadySeconds 는 새롭게 생성된 파드의 컨테이너가 어떤 것과도 충돌하지 않고 사 용할 수 있도록 준비되어야 하는 최소 시간(초)을 지정하는 선택적 필드이다. 이 기본 값은 0이다(파드는 준비되는 즉시 사용할 수 있는 것으로 간주됨). 파드가 준비되었다고 간주되는 시기에 대한 자세한 내용은 컨테이너 프로브를 참조한다.

프로브를 사용한다면 굳이 세팅할 필요는 없다.

수정 버전 기록 제한

디플로이먼트의 수정 버전 기록은 자신이 컨트롤하는 레플리카셋에 저장된다.

.spec.revisionHistoryLimit 은 롤백을 허용하기 위해 보존할 이전 레플리카셋의 수를 지정하는 선택적 필드이다. 이 이전 레플리카셋은 etcd 의 리소스를 소비하고, kubectl get rs 의 결과를 가득차게 만든다. 각 디플로이먼트의 구성은 디플로이먼트의 레플리카셋에 저장된다. 이전 레플리카셋이 삭제되면 해당 디플로이먼트 수정 버전으로 롤백할 수 있는 기능이 사라진다. 기본적으로 10개의 기존 레플리카셋이 유지되지만 이상적인 값은 새로운 디플로이먼트의 빈도와 안정성에 따라 달라진다.

더욱 구체적으로 이 필드를 0으로 설정하면 레플리카가 0이 되며 이전 레플리카셋이 정리된다. 이 경우, 새로운 디플로이먼트 롤아웃을 취소할 수 없다. 새로운 디플로이먼트 롤아웃은 수정 버전 이력이 정리되기 때문이다.

일시 정지

.spec.paused 는 디플로이먼트를 일시 중지나 재개하기 위한 선택적 부울 필드이다. 일시 중지 된 디플로이먼트와 일시 중지 되지 않은 디플로이먼트 사이의 유일한 차이점은 일시 중지된 디플로이먼트는 PodTemplateSpec에 대한 변경 사항이 일시중지 된 경우 새 롤아웃을 트리거 하지 않는다. 디플로이먼트는 생성시 기본적으로 일시 중지되지 않는다.

Ansible, Terraform, Packer 로 인프라 구현

ssunw — Mon, 23 May 2022 15:01:48 +0900

https://github.com/seongwoo-choi/ansible_terraform_packer

AWS

구성도

배스천 호스트와 관리 노드를 오토 스케일링 그룹으로 관리하고 EFS 를 사용해서 /var/www/html/wordpress 를 관리하는 인프라를 구현하고자 한다.

AWS 사용 서비스

VPC
Security Group
RDS
ASG, Launch Template, ALB, Target Group
EFS
EC2

Terraform

키 페어 생성

resource "aws_key_pair" "app_server_key" {  
  key_name   = "app_server_key"  
  public_key = file("/Users/csw/.ssh/id_rsa.pub")  
}

file 함수를 사용하여 id_rsa.pub 파일을 공개키로 등록을 했고 해당 키네임을 app_server_key 로 작성했다.

VPC 생성

# NAT 게이트 용 EIP  
resource "aws_eip" "nat" {  
  count = 1  
  vpc   = true  
}  

module "app_vpc" {  
  source = "terraform-aws-modules/vpc/aws"  
  #  version = "~> 3.0"  

  name = "app_vpc"  
  cidr = "10.0.0.0/16"  

  azs              = ["ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c", "ap-northeast-2d"]  
  public_subnets   = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24", "10.0.4.0/24"]  
  private_subnets  = ["10.0.10.0/24", "10.0.11.0/24", "10.0.12.0/24", "10.0.13.0/24"]  
  database_subnets = ["10.0.20.0/24", "10.0.21.0/24", "10.0.22.0/24", "10.0.23.0/24"]  

  # 하나의 가용 영역에 한 개의 nat 게이트웨이 설정  
  enable_nat_gateway     = true  
  single_nat_gateway     = true  
  one_nat_gateway_per_az = false  
  reuse_nat_ips          = false  
  external_nat_ip_ids    = aws_eip.nat.*.id  

  create_database_subnet_group = true  
}

VPC module 을 사용하면 한 개의 블록에서 VPC, subnets, az, nat 등 네트워크 설정들을 한 번에 관리할 수 있다.

NAT 게이트웨이를 위해 탄력적 IP 를 resource 블록에서 한 개 생성한다.

VPC 모듈에서 가용 영역을 설정하고 public subnet, private subnet, db subnet 의 CIDR 블록을 생성한다.

또한 하나의 가용 영역에 한 개의 NAT 게이트웨이를 추가할 것이기 때문에 nat 게이트웨이에 대한 설정을 해줬다.

enable_nat_gateway 은 nat 게이트웨이를 사용할 것인지 묻는 것이다.

single_nat_gateway 는 nat 게이트웨이를 하나만 사용할 것인지 묻는 것이다. one_nat_gateway_per_az 는 각 가용 영역 마다 nat 게이트웨이를 하나 씩 부착할 것인지 묻는 것이다.

reuse_nat_ips 는 nat 게이트웨이에 부착된 ip 를 재사용할 지에 대한 여부이다. external_nat_ip_ids 는 nat 게이트웨이에 부착할 탄력적 ip 주소의 id 를 적으면 된다.

create_database_subnet_group 은 database 용 서브넷을 생성할 것인지에 대한 여부를 묻는 것 이다. 이 VPC 에서 데이터베이스 서브넷을 생성할 것이기 때문에 true 로 설정했다.

실제로 VPC 는 위 사진과 같이 생성된 것을 확인할 수 있다.

서브넷도 코드로 작성한 값들이 제대로 생성된 것을 확인할 수 있다.

라우팅 테이블은 디폴트 값이 설정되어 있어 자동으로 생성된 것을 확인할 수 있다.

인터넷 게이트웨이가 생성된 것을 확인할 수 있고, 한 개의 가용 영역에서 EIP 를 가진채로 NAT 게이트웨이가 생성된 것을 확인할 수 있다.

Security Group 생성

resource "aws_security_group" "bastion_sg" {  
  name   = "bastion_security_group"  
  vpc_id = module.app_vpc.vpc_id  

  ingress {  
    from_port   = 22  
    to_port     = 22  
    protocol    = "tcp"  
    cidr_blocks = [file("./my_ip.txt")]  
  }  

  egress {  
    from_port   = 0  
    to_port     = 0  
    protocol    = "-1"  
    cidr_blocks = ["0.0.0.0/0"]  
  }  

  tags = {  
    Name = "bastion_security_group"  
  }  
}  

resource "aws_security_group" "node_sg" {  
  name   = "node_security_group"  
  vpc_id = module.app_vpc.vpc_id  

  ingress {  
    from_port   = 80  
    to_port     = 80  
    protocol    = "tcp"  
    cidr_blocks = ["0.0.0.0/0"]  
  }  

  ingress {  
    from_port       = 22  
    to_port         = 22  
    protocol        = "tcp"  
    security_groups = [aws_security_group.bastion_sg.id]  
  }  

  egress {  
    from_port   = 0  
    to_port     = 0  
    protocol    = "-1"  
    cidr_blocks = ["0.0.0.0/0"]  
  }  
  tags = {  
    Name = "node_security_group"  
  }  
}  

resource "aws_security_group" "alb_sg" {  
  name   = "alb_security_group"  
  vpc_id = module.app_vpc.vpc_id  

  ingress {  
    from_port   = 80  
    to_port     = 80  
    protocol    = "tcp"  
    cidr_blocks = ["0.0.0.0/0"]  
  }  

  egress {  
    from_port   = 0  
    to_port     = 0  
    protocol    = "-1"  
    cidr_blocks = ["0.0.0.0/0"]  
  }  

  tags = {  
    Name = "alb_security_group"  
  }  
}  

resource "aws_security_group" "node_efs_sg" {  
  name   = "node_efs_security_group"  
  vpc_id = module.app_vpc.vpc_id  

  ingress {  
    from_port       = 2049  
    protocol        = "tcp"  
    to_port         = 2049  
    security_groups = [aws_security_group.node_sg.id]  
  }  

  egress {  
    from_port       = 0  
    protocol        = "-1"  
    to_port         = 0  
    security_groups = [aws_security_group.node_sg.id]  
  }  

  tags = {  
    Name = "node_efs_sg"  
  }  
}

aws_security_group 이라는 리소스 블록을 사용하여 보안 그룹을 생성할 수 있다.

각각의 보안 그룹에 이름 태그를 달아두었다.

ingress 는 인바운드 규칙이고 egress 는 아웃바운드 규칙이다.

ingress 에서 살펴볼 것은 security_groups 와 cidr_blocks 이다.

security_groups 는 보안 그룹을 src 로 설정할 수 있고, cidr_blocks 은 CIDR 블록만 입력할 수 있다.

또한, vpc_id 를 입력하여 해당 보안 그룹을 원하는 VPC 에 설정할 수 있다.

실제로 생성된 보안 그룹은 위와 같다.

RDS 생성

module "rds_allow" {  
  source = "terraform-aws-modules/security-group/aws"  

  name            = "rds_allow_sg"  
  description     = "rds"  
  vpc_id          = module.app_vpc.vpc_id  
  use_name_prefix = false  

  ingress_with_source_security_group_id = [  
    {      
      rule                     = "mysql-tcp"  
      source_security_group_id = aws_security_group.node_sg.id  
    }  
  ]  

  egress_with_cidr_blocks = [  
    {      from_port   = 0  
      to_port     = 0  
      protocol    = "-1"  
      description = "all"  
      cidr_blocks = "0.0.0.0/0"  
    }  
  ]
}  

# 템플릿(프리티어), 디비 인스턴스 이름  
# 디비 마스터 사용자 이름, 비밀번호  
# 스토리지  
# 가용성 및 내구성(다중 AZ)  
# vpc 세팅 및 서브넷 설정, 퍼블릭 액세스 설정, VPC 보안 그룹 세팅  
# 데이터 베이스 인증 옵션(암호인증)  
# 초기 데이터베이스 이름 설정, 백업, 스냅샷, 디비 인스턴스 암호화 옵션 등  
module "db" {  
  source = "terraform-aws-modules/rds/aws"  

  identifier = "wordpress"  

  engine               = "mysql"  
  engine_version       = "8.0.20"  
  family               = "mysql8.0"  
  major_engine_version = "8.0"  
  instance_class       = "db.t3.micro"  

  allocated_storage     = 20  
  max_allocated_storage = 100  

  db_name                = "wordpress"  
  username               = "admin"  
  password               = "chma0326"  
  create_random_password = false  
  port                   = "3306"  

  # DB subnet group  
  multi_az               = true  
  subnet_ids             = module.app_vpc.database_subnets  
  vpc_security_group_ids = [module.rds_allow.security_group_id]  
  create_db_subnet_group = false  
  db_subnet_group_name   = module.app_vpc.database_subnet_group_name  

  # 삭제 시 스냅샷을 생성할지에 대한 여부, true 로 설정하여 스냅샷 생성 안 함  
  skip_final_snapshot = true  


  # 모니터링 환경 설정
  maintenance_window              = "Mon:00:00-Mon:03:00"  
  backup_window                   = "03:00-06:00"  
  enabled_cloudwatch_logs_exports = ["general"]  
  create_cloudwatch_log_group     = true  
  backup_retention_period         = 0  
  skip_final_snapshot             = true  
  deletion_protection             = false  

  parameters = [  
    { 
      name  = "character_set_client"  
      value = "utf8mb4"  
    },  
    {  
      name  = "character_set_server"  
      value = "utf8mb4"  
    }  
  ]  

  depends_on = [  
    module.app_vpc  
  ]  
}  

resource "null_resource" "rds_endpoint_info" {  
  provisioner "local-exec" {  
    command = "echo database_host: ${module.db.db_instance_endpoint} > /Users/csw/Downloads/terraform_anbile_packer/vars/rds_endpoint_info.yml"  
  }  

  depends_on = [  
    module.db  
  ]  
}

먼저 RDS 인스턴스 보안 그룹을 생성한다.

VPC 세팅과 이름을 설정해줬고 node_sg 보안 그룹에서 온 트래픽들이 데이터 베이스에 접속할 수 있도록 3306 포트를 열어놓았다.

실제 DB 설정은 RDS 모듈을 사용하였다.

  source = "terraform-aws-modules/rds/aws"  

  identifier = "wordpress"  

  engine               = "mysql"  
  engine_version       = "8.0.20"  
  family               = "mysql8.0"  
  major_engine_version = "8.0"  
  instance_class       = "db.t3.micro"  

  allocated_storage     = 20  
  max_allocated_storage = 100

identifier 는 생성되는 RDS 의 이름이고 engine, engine_version 은 어떤 데이터베이스를 사용할 것인지와 몇 버전을 사용할 것인지를 작성하는 곳이다.

instance_class 에서 사용하고자 하는 인스턴스 유형을 작성하면 되고, allocated_storage 와 max_allocated_storage 는 디비 인스턴스의 초기 용량 크기와 최대로 커질 수 있는 용량 크기를 정하는 곳이다.

  db_name                = "wordpress"  
  username               = "admin"  
  password               = "chma0326"  
  create_random_password = false  
  port                   = "3306"

db_name 은 데이터베이스 이름을, username 은 루트 사용자 이름을, password 는 루트 사용자 비밀번호를, create_random_password 는 랜덤하게 비밀번호를 생성할 것인지에 대한 여부를, port 어떤 포트로 트래픽이 들어오게 할 것인지를 작성하는 곳이다.

  # DB subnet group  
  # multi_az             = true  
  subnet_ids             = module.app_vpc.database_subnets  
  vpc_security_group_ids = [module.rds_allow.security_group_id]  
  create_db_subnet_group = false  
  db_subnet_group_name   = module.app_vpc.database_subnet_group_name  

  # 삭제 시 스냅샷을 생성할지에 대한 여부, true 로 설정하여 스냅샷 생성 안 함  
  skip_final_snapshot = true

multi_az 를 true 로 하여 마스터 슬레이브 형태로 디비 인스턴스를 띄울수도 있다.

subnet_ids 에 어떤 CIDR 블록들을 DB 서브넷으로 사용할 것인지 설정하고, vpc_security_group_ids 에 rds 보안 그룹을 세팅하고, 이미 VPC 에서 DB 서브넷을 만들었기 때문에 또 DB 서브넷을 만들 필요가 없다 그래서 create_db_subnet_group 를 false 로 세팅한다.

db_subnet_group_name 을 설정하지 않으면 디폴트 VPC 로 잡히기 때문에 꼭 여기에 DB 서브넷 그룹명을 넣어주면 된다.

skip_final_snapshot 은 디비 인스턴스 최종 삭제 시에 최종 스냅샷을 생성할 것인지 말 것인지에 대한 여부를 적는 곳으로 디폴트는 false 이다.

  maintenance_window              = "Mon:00:00-Mon:03:00"
  backup_window                   = "03:00-06:00"
  enabled_cloudwatch_logs_exports = ["general"]
  create_cloudwatch_log_group     = true

  backup_retention_period = 0
  skip_final_snapshot     = true
  deletion_protection     = false

위 설정들은 모두 모니터링에 관련된 설정들이다.

  parameters = [  
    { 
      name  = "character_set_client"  
      value = "utf8mb4"  
    },  
    {  
      name  = "character_set_server"  
      value = "utf8mb4"  
    }  
  ]

디비 서버와 클라이언트에서 utf8 사용하도록 설정

resource "null_resource" "rds_endpoint_info" {  
  provisioner "local-exec" {  
    command = "echo database_host: ${module.db.db_instance_endpoint} > /Users/csw/Downloads/terraform_anbile_packer/vars/rds_endpoint_info.yml"  
  }  

  depends_on = [  
    module.db  
  ]  
}

디비 인스턴스가 생성되고 난 후에 /Users/csw/Downloads/terraform_anbile_packer/vars 디렉토리 밑에 rds_endpoint_info.yml 파일에 생성된 RDS 의 엔드 포인트가 database: RDS엔드포인트 로 입력되도록 설정한 것이다.

database_host: wordpress.c8xnvne1yftk.ap-northeast-2.rds.amazonaws.com:3306 실제로 이렇게 작성된다.

실제로 디비 인스턴스는 위 사진처럼 생성된다.

EFS 생성

resource "aws_efs_file_system" "node_efs_file_system" {  
  creation_token   = "node_file_system"  
  performance_mode = "generalPurpose"  
  encrypted        = "true"  

  tags = {  
    Name = "node_file_system"  
  }  
}  

resource "aws_efs_mount_target" "node_efs_mount_target" {  
  file_system_id  = aws_efs_file_system.node_efs_file_system.id  
  subnet_id       = module.app_vpc.private_subnets[0]  
  security_groups = [aws_security_group.node_efs_sg.id]  
}  

resource "aws_efs_access_point" "node_efs_access_point" {  
  file_system_id = aws_efs_file_system.node_efs_file_system.id  
  root_directory {  
    path = "/var/www/html/wordpress"  
  }  
}

aws_efs_file_system 리소스로 efs 파일 시스템을 생성한다. 이름과 퍼포먼스 유형, 보안 여부 등을 설정한다.

aws_efs_mount_target 리소스로 efs 마운트 타겟을 설정한다. 어떤 파일 시스템을 사용할 것인지 어떤 서브넷에 존재하는지 해당 파일 시스템에 마운트 된 타겟에 대해 어떤 트래픽이 들어오고 나가게 할 것인지를 설정한다.

aws_efs_access_point 리소스로 액세스 포인트를 설정한다. 어떤 파일 시스템을 사용할 것인지 어떤 경로가 efs 로 사용될 것인지를 설정한다.

파일 시스템과 액세스 포인트는 위 사진처럼 생성된다.

Packer 로 AMI 생성

packer {  
  required_plugins {  
    amazon = {  
      version = ">= 0.0.2"  
      source  = "github.com/hashicorp/amazon"  
    }  
  }}  


source "amazon-ebs" "linux" {  
  region  = "ap-northeast-2"  
  profile = "default"  

  ami_name      = "wordpress_image"  
  instance_type = "t2.micro"  
  source_ami_filter {  
    filters = {  
      name                = var.image_filter  
      root-device-type    = "ebs"  
      virtualization-type = "hvm"  
    }  
    most_recent = true  
    owners      = ["099720109477"]  
  }  ssh_username     = var.ssh_account  
  force_deregister = true  
}  


build {  
  name = "wordpress_image"  
  sources = [  
    "source.amazon-ebs.linux"  
  ]  


  provisioner "ansible" {  
    playbook_file = "/Users/csw/Downloads/terraform_anbile_packer/ansible/web.yml"  
    extra_arguments = [  
      "--become"  
    ]  
    ansible_env_vars = [  
      "ANSIBLE_HOST_KEY_CHECKING=False",  
    ]  
  }}

ubuntu 18.04 LTS 버전에 /Users/csw/Downloads/terraform_anbile_packer/ansible/web.yml 플레이북 파일을 실행하여 AMI 를 생성한다.

- hosts: all  
  become: yes  
  vars_files:  
    - /Users/csw/Downloads/terraform_anbile_packer/vars/rds_endpoint_info.yml  
  roles:  
    - web

web.yml 은 위와 같이 구성되어 있고 vars_files 를 사용하여 rds_endpoint_info 파일의 변수들을 가져온다. 그리고 web roles 를 실행시킨다.

실제 roles 구조는 위와 같이 되어 있다.

---  
- name: Install Apache Server  
  apt:  
    name: apache2  
    state: present  

- name: Install mysql-client  
  apt:  
    name: mysql-client  
    state: present  

- name: Install php  
  apt:  
    name: "{{ php_packages }}"  
    state: present  

- name: Download Wordpress Archive file  
  get_url:  
    url: "{{ wordpress_url }}"  
    dest: /home/ubuntu  

- name: Decompress Archive file  
  unarchive:  
    src: "/home/ubuntu/{{ wordpress_filename }}"  
    remote_src: yes  
    dest: /var/www/html/  

- name: Copy Database Configure File for Wordpress  
  template:  
    src: wp-config.php.j2  
    dest: /var/www/html/wordpress/wp-config.php  

- name: restart apache2  
  service:  
    name: apache2  
    state: restarted

tasks 에선 apache2, mysql-client, php 관련 패키지들을 설치하고 wget 을 통해 워드프레스를 다운받은 후 압축해제 한 뒤 로컬 머신에 있는 wp-config.php.j2 파일을 가져가서 wp-config.php 파일로 사용한다.

---  
php_packages: php,php-curl,php-xml,php-gd,php-mysql,python3-mysqldb  
wordpress_version: 5.9.3  
wordpress_filename: "wordpress-{{ wordpress_version }}.tar.gz"  
wordpress_url: "https://wordpress.org/{{ wordpress_filename }}"  

# RDS  
database:  
  name: wordpress  
  user: admin  
  pwd: chma0326

변수 파일은 위와 같다.

<?php  
// ** Database settings - You can get this info from your web host ** //  
/** The name of the database for WordPress */  
define( 'DB_NAME', '{{ database["name"] }}' );  

/** Database username */  
define( 'DB_USER', '{{ database["user"] }}' );  

/** Database password */  
define( 'DB_PASSWORD', '{{ database["pwd"] }}' );  

/** Database hostname */  
define( 'DB_HOST', '{{ database_host }}' );  

/** Database charset to use in creating database tables. */  
define( 'DB_CHARSET', 'utf8' );  

/** The database collate type. Don't change this if in doubt. */  
define( 'DB_COLLATE', '' );  

define( 'AUTH_KEY',         'put your unique phrase here' );  
define( 'SECURE_AUTH_KEY',  'put your unique phrase here' );  
define( 'LOGGED_IN_KEY',    'put your unique phrase here' );  
define( 'NONCE_KEY',        'put your unique phrase here' );  
define( 'AUTH_SALT',        'put your unique phrase here' );  
define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );  
define( 'LOGGED_IN_SALT',   'put your unique phrase here' );  
define( 'NONCE_SALT',       'put your unique phrase here' );  

$table_prefix = 'wp_';  

define( 'WP_DEBUG', false );  

if ( ! defined( 'ABSPATH' ) ) {  
        define( 'ABSPATH', __DIR__ . '/' );  
}  

require_once ABSPATH . 'wp-settings.php';

템플릿 파일은 위와 같다.

packer 를 사용하여 위 사진처럼 AMI 를 생성할 수 있다.

Bation Host 생성

# 런치 템플릿, 오토 스케일링 그룹, alb  

resource "aws_launch_template" "bastion_host_template" {  

  name          = "bastion_host_template"  
  image_id      = "ami-02e05347a68e9c76f"  
  instance_type = "t3.small"  
  key_name      = aws_key_pair.app_server_key.key_name  

  vpc_security_group_ids = [aws_security_group.bastion_sg.id]  

  tags = {  
    Name = "bastion_host_template"  
  }  

  depends_on = [  
    aws_security_group.bastion_sg  
  ]  
}  

resource "aws_autoscaling_group" "bastion_host_asg" {  
  name              = "bastion_host_asg"  
  health_check_type = "ELB"  

  vpc_zone_identifier = module.app_vpc.public_subnets  
  min_size            = 1  
  max_size            = 3  

  launch_template {  
    id = aws_launch_template.bastion_host_template.id  
  }  
}  

resource "aws_autoscaling_policy" "bastion_host_asg_policy" {  
  name                   = "bastion_host_asg_policy"  
  policy_type            = "TargetTrackingScaling"  
  autoscaling_group_name = aws_autoscaling_group.bastion_host_asg.name  

  target_tracking_configuration {  
    predefined_metric_specification {  
      predefined_metric_type = "ASGAverageCPUUtilization"  
    }  
    target_value = 40.0  
  }  
}  

resource "aws_lb" "bastion_host_alb" {  
  name               = "bastion-host-alb"  
  internal           = false  
  load_balancer_type = "application"  
  security_groups    = [aws_security_group.alb_sg.id]  
  subnets            = module.app_vpc.public_subnets  

  tags = {  
    Name = "bastion_host_alb"  
  }  
}  

resource "aws_lb_listener" "bastion_host_alb_listener" {  
  load_balancer_arn = aws_lb.bastion_host_alb.arn  

  port     = 80  
  protocol = "HTTP"  

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

  tags = {  
    Name = "bastion_host_alb_listener"  
  }  
}  

resource "aws_lb_target_group" "bastion_host_target_group" {  
  name     = "bastion-host-target-group"  
  port     = 80  
  protocol = "HTTP"  
  vpc_id   = module.app_vpc.vpc_id  

  health_check {  
    port     = "traffic-port"  
    protocol = "HTTP"  
    path     = "/"  
  }  

  tags = {  
    Name = "bastion-host-target-group"  
  }  
}  

resource "aws_lb_target_group_attachment" "bastion_host_target_group_attachment" {  
  count = 1  

  port             = 80  
  target_group_arn = aws_lb_target_group.bastion_host_target_group.arn  
  target_id        = element(data.aws_instances.bastion_host_instances.ids, count.index)  
  depends_on       = [data.aws_instances.bastion_host_instances]  
}  

data "aws_instances" "bastion_host_instances" {  

  instance_tags = {  
    "aws:autoscaling:groupName" = aws_autoscaling_group.bastion_host_asg.name  
  }  
  depends_on = [aws_launch_template.bastion_host_template]  

}

resource "aws_launch_template" "bastion_host_template" {  

  name          = "bastion_host_template"  
  image_id      = "ami-02e05347a68e9c76f"  
  instance_type = "t3.small"  
  key_name      = aws_key_pair.app_server_key.key_name  

  vpc_security_group_ids = [aws_security_group.bastion_sg.id]  

  tags = {  
    Name = "bastion_host_template"  
  }  

  depends_on = [  
    aws_security_group.bastion_sg  
  ]  
}

먼저 aws_launch_template 을 생성한다. 이미지는 amazon_linux 이미지를 사용했고 인스턴스 유형은 t3.small 을 사용했다.

해당 인스턴스에 접속하기 위한 키 페어를 등록을 해야 하는데 미리 만들어놓은 키 페어의 이름을 작성한다.

보안 그룹도 미리 만들어놓은 보안 그룹을 작성해준다.

resource "aws_autoscaling_group" "bastion_host_asg" {  
  name              = "bastion_host_asg"  
  health_check_type = "ELB"  

  vpc_zone_identifier = module.app_vpc.public_subnets  
  min_size            = 1  
  max_size            = 3  

  launch_template {  
    id = aws_launch_template.bastion_host_template.id  
  }  
}

오토 스케일링 그룹을 생성한다. 헬스 체크 타입을 지정해주고, 어떤 서브넷에서 오토 스케일링 그룹이 위치할 지 지정하고 최소 최대 갯수를 지정해준다.

어떤 런치 템플릿을 사용할 지 id 값을 설정해준다.

resource "aws_autoscaling_policy" "bastion_host_asg_policy" {  
  name                   = "bastion_host_asg_policy"  
  policy_type            = "TargetTrackingScaling"  
  autoscaling_group_name = aws_autoscaling_group.bastion_host_asg.name  

  target_tracking_configuration {  
    predefined_metric_specification {  
      predefined_metric_type = "ASGAverageCPUUtilization"  
    }  
    target_value = 40.0  
  }  
}

오토 스케일링 정책을 생성한다. 이름과 정책 타입을 설정해준다.

어떤 오토 스케일링 그룹에 적용할지 설정하기 위해 오토 스케일링 그룹 이름도 설정해준다.

CPU 평균 사용률이 40% 가 초과하면 인스턴스가 생성되도록 설정했다.

resource "aws_lb" "bastion_host_alb" {  
  name               = "bastion-host-alb"  
  internal           = false  
  load_balancer_type = "application"  
  security_groups    = [aws_security_group.alb_sg.id]  
  subnets            = module.app_vpc.public_subnets  

  tags = {  
    Name = "bastion_host_alb"  
  }  
}  

resource "aws_lb_listener" "bastion_host_alb_listener" {  
  load_balancer_arn = aws_lb.bastion_host_alb.arn  

  port     = 80  
  protocol = "HTTP"  

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

  tags = {  
    Name = "bastion_host_alb_listener"  
  }  
}

bastion host 용 application load balancer 를 생성한다. 보안 그룹, 로드 밸런서 타입, 이름, 내부용인지 외부용인지, 어떤 서브넷을 사용할 것인지에 대한 설정을 해준다.

로드 밸런서 리스너를 설정해준다.

80 번 포트로 HTTP 프로토콜로 트래픽이 로드 밸런서로 들어올 경우에 기본적으로 대상 그룹으로 포워딩하게 설정했다.

resource "aws_lb_target_group" "bastion_host_target_group" {  
  name     = "bastion-host-target-group"  
  port     = 80  
  protocol = "HTTP"  
  vpc_id   = module.app_vpc.vpc_id  

  health_check {  
    port     = "traffic-port"  
    protocol = "HTTP"  
    path     = "/"  
  }  

  tags = {  
    Name = "bastion-host-target-group"  
  }  
}  

resource "aws_lb_target_group_attachment" "bastion_host_target_group_attachment" {  
  count = 1  

  port             = 80  
  target_group_arn = aws_lb_target_group.bastion_host_target_group.arn  
  target_id        = element(data.aws_instances.bastion_host_instances.ids, count.index)  
  depends_on       = [data.aws_instances.bastion_host_instances]  
}  

data "aws_instances" "bastion_host_instances" {  

  instance_tags = {  
    "aws:autoscaling:groupName" = aws_autoscaling_group.bastion_host_asg.name  
  }  
  depends_on = [aws_launch_template.bastion_host_template]  

}

로드 밸런서 대상 그룹을 생성한다. HTTP 프로토콜로 80번 포트로 오는 요청만 받아들이도록 설정했고 헬스 체크를 하도록 설정했다.

실제 대상 그룹에 인스턴스를 설정하기 위해서 data 소스로 인스턴스를 가져오고 해당 인스턴스를 대상 그룹에 붙여준다.

Node

# 런치 템플릿, 오토 스케일링 그룹, alb  

resource "aws_launch_template" "node_template" {  
  name          = "node_template"  
  image_id      = data.aws_ami.wordpress_image.id  
  instance_type = "t3.small"  
  key_name      = aws_key_pair.app_server_key.key_name  

  vpc_security_group_ids = [aws_security_group.node_sg.id]  

  tags = {  
    Name = "node_template"  
  }  
}  

resource "aws_autoscaling_group" "node_asg" {  
  name              = "node_asg"  
  health_check_type = "ELB"  

  vpc_zone_identifier = module.app_vpc.private_subnets  
  min_size            = 1  
  max_size            = 3  

  launch_template {  
    id = aws_launch_template.node_template.id  
  }  
}  

resource "aws_autoscaling_policy" "node_asg_policy" {  
  name                   = "node_asg_policy"  
  policy_type            = "TargetTrackingScaling"  
  autoscaling_group_name = aws_autoscaling_group.node_asg.name  

  target_tracking_configuration {  
    predefined_metric_specification {  
      predefined_metric_type = "ASGAverageCPUUtilization"  
    }  

    target_value = 40.0  
  }  
}  

resource "aws_lb" "node_alb" {  
  name               = "node-alb"  
  internal           = false  
  load_balancer_type = "application"  
  security_groups    = [aws_security_group.alb_sg.id]  
  subnets            = module.app_vpc.public_subnets  

  tags = {  
    Name = "node_alb"  
  }  
}  

resource "aws_lb_listener" "node_alb_listener" {  
  load_balancer_arn = aws_lb.node_alb.arn  

  port     = 80  
  protocol = "HTTP"  

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

  tags = {  
    Name = "node_alb_listener"  
  }  
}  

resource "aws_lb_target_group" "node_target_group" {  
  name     = "node-target-group"  
  port     = 80  
  protocol = "HTTP"  
  vpc_id   = module.app_vpc.vpc_id  

  health_check {  
    port     = "traffic-port"  
    protocol = "HTTP"  
    path     = "/wordpress"  
    matcher  = "301"  
  }  
  
  # efs 를 ansible 에서 mount 하지 않았기 때문에 sticky session 을 사용했다.
  stickiness {
    type            = "app_cookie"
    enabled         = true
    cookie_duration = 86400
  }

  tags = {  
    Name = "node_target_group"  
  }  
}  

resource "aws_lb_target_group_attachment" "node_target_group_attachment" {  
  count = 1  

  port             = 80  
  target_group_arn = aws_lb_target_group.node_target_group.arn  
  target_id        = element(data.aws_instances.node_instances.ids, count.index)  
  depends_on       = [data.aws_instances.node_instances]  
}  

data "aws_instances" "node_instances" {  
  instance_tags = {  
    "aws:autoscaling:groupName" = aws_autoscaling_group.node_asg.name  
  }  
  depends_on = [aws_launch_template.node_template]  
}

전체적으로 Bation Host 와 동일하지만 AMI 만 다르다.

data "aws_ami" "wordpress_image" {  
  most_recent = true  
  owners      = ["self"]  
  name_regex  = "wordpress-*"  

  filter {  
    name   = "architecture"  
    values = ["x86_64"]  
  }  
  filter {  
    name   = "root-device-type"  
    values = ["ebs"]  
  }  
  filter {  
    name   = "virtualization-type"  
    values = ["hvm"]  
  }}

런치 템플릿에서 사용하는 AMI 는 packer 로 만든 ami 를 사용해야 한다.

ami 는 이미 만들어졌기 때문에 data 소스를 사용하여 ami 를 가져오도록 했다.

resource "aws_launch_template" "node_template" {  
  name          = "node_template"  
  image_id      = data.aws_ami.wordpress_image.id  
  instance_type = "t3.small"  
  key_name      = aws_key_pair.app_server_key.key_name  

  vpc_security_group_ids = [aws_security_group.node_sg.id]  

  tags = {  
    Name = "node_template"  
  }  
}

ami 에 data 소스에서 가져온 ami id 값을 입력하도록 했다.

실제로 생성된 런치 템플릿은 위와 같다.

실제로 생성된 대상 그룹은 위와 같다.

실제로 생성된 오토 스케일링 그룹은 위와 같다.

실제로 생성된 로드 밸런서는 위와 같다.

실제로 생성된 노드와 bastion host

node 로드 밸런서의 DNS 이름으로 접속할 경우 위와 같이 페이지가 나타나는 것을 볼 수 있다.

개선할 점

EFS 를 terraform 에서 구현하는 것은 간단했지만 ansible 에서 EFS 를 마운트하기 위해 efs 전용 모듈을 사용하고 packer 로 ami 를 만들어야 한다.
변수를 거의 사용하지 않았다.
HTTPS 설정을 하지 않았고, Route 53 을 사용하여 레코드를 등록하여 사용하면 좋을 것이다.
디렉토리 구조를 더 깔끔하게 바꿀 수 있을 것이다.
템플릿이나 AMI 등 버전 관리 설정 등을 사용하여 편하게 관리할 수 있도록 설정할 수 있을 것이다.
data 소스를 적극적으로 사용하여 모듈 별로 실행할 수 있게 분리하면 좋을 것같다.

[kubernetes] Service & Ingress

ssunw — Mon, 23 May 2022 13:19:23 +0900

Service

공식 문서: https://kubernetes.io/ko/docs/concepts/services-networking/service/

파드 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 방법

쿠버네티스를 사용하면 익숙하지 않은 서비스 디스커버리 메커니즘을 사용하기 위해 애플리케이션을 수정할 필요가 없다.

쿠버네티스는 파드에게 고유한 IP 주소와 파드 집합에 대한 단일 DNS 명을 부여하고, 그것들 간에 로드-밸런스를 수행할 수 있다.

서비스는 selector 를 사용해서 pod 의 label 을 찾고 뒷단으로 연결시키기 때문에 만약 다른 pod 에서 만든 컨테이너의 label 이 셀렉터에서 찾는 label 과 같다면 서비스의 뒷단에 연결해버린다.

그래서, label 과 selector 를 잘 설정해줘야 한다.

kubectl explain svc.spec

clusteIP: 서비스에 IP 주소를 지정한다. 서비스의 갯수가 많아지면 IP 주소를 관리하기 힘들어지기 때문에 굳이 사용하지 않는다.
ports: 서비스의 포트를 지정한다. 즉, 클라이언트가 서비스에 접속할 포트 번호이다.
selector: 서비스가 연결하기 위한 파드의 label 을 지정한다.
type: 서비스의 타입을 지정한다. ExternalName, ClusterIP, NodePort, LoadBalancer 가 있다.
- NodePort, LoadBalancer: 클러스터 외부에 노출하기 위한 것
- ClusterIP: 클러스터 내부에서 사용하기 위한 것

kubectl explain svc.spec.ports

name: 포트의 이름
port: 서비스를 외부에 노출시킬 포트를 지정
protocol: 프로토콜을 지정한다. (TCP, UDP, STCP)
targetPort: 서비스와 연결하려는 파드의 포트를 지정한다.

서비스의 이름과 똑같은 엔드포인트가 만들어지고, 엔드포인트가 실제 파드의 정보를 갖고 있다. 연결된 파드가 삭제되거나 종료될 경우 자동으로 파드를 만들어서 엔드포인트에 연결시켜준다.

myweb-rs.yml

metadata:
  name: myweb-rs-set
spec:
  replicas: 3
  selector:
    matchExpressions:
      - key: app
        operator: In
        values:
          - web
      - key: env
        operator: Exists
  template:
    metadata:
      labels:
        app: web
        env: dev
    spec:
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb
          ports:
            - containerPort: 8080
              protocol: TCP

myweb-svc.yml

apiVersion: v1
kind: Service
metadata:
  name: myweb-svc
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

kubectl run nettool -it --image ghcr.io/c1t1d0s7/network-multitool

bash-5.1# curl 10.101.197.28
Hello World!
myweb-rs-set-89q25

bash-5.1# cat /etc/resolv.conf
nameserver 10.96.0.10  # <- 쿠버네티스 CoreDNS 주소. 즉, 쿠버네티스 안에서 자기들끼리 통신이 가능하다.
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

bash-5.1# curl myweb-svc
Hello World!

sessionAffinity

kubectl explain svc.spec

sessionAffinity: 스티키 세션. 즉, 세션을 고정시키는 것

[~/k8s/svc]$ cat myweb-svc-ses.yml
apiVersion: v1
kind: Service
metadata:
  name: myweb-svc-ses
spec:
  type: ClusterIP
  sessionAffinity: ClientIP
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

[~/k8s/svc]$ kubectl create -f myweb-svc-ses.yml -f myweb-rs.yml
service/myweb-svc-ses created
[~/k8s/svc]$ kubectl get svc,ep,rs,pod
NAME                    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/kubernetes      ClusterIP   10.96.0.1      <none>        443/TCP   35h
service/myweb-svc-ses   ClusterIP   10.99.16.135   <none>        80/TCP    11s

NAME                      ENDPOINTS                                         AGE
endpoints/kubernetes      192.168.49.2:8443                                 35h
endpoints/myweb-svc-ses   10.244.0.3:8080,10.244.1.2:8080,10.244.2.2:8080   11s

NAME                           DESIRED   CURRENT   READY   AGE
replicaset.apps/myweb-rs-set   3         3         3       28s

NAME                     READY   STATUS    RESTARTS   AGE
pod/myweb-rs-set-69bgq   1/1     Running   0          28s
pod/myweb-rs-set-8h7ht   1/1     Running   0          28s
pod/myweb-rs-set-n6xzw   1/1     Running   0          28s
[~/k8s/svc]$ kubectl run nettool -it --image ghcr.io/c1t1d0s7/network-multitool --rm
If you don't see a command prompt, try pressing enter.
/ # curl myweb-svc-ses
Hello World!
myweb-rs-set-n6xzw
/ # curl myweb-svc-ses
Hello World!
myweb-rs-set-n6xzw
/ # curl myweb-svc-ses
Hello World!

Named Port

[~/k8s/svc]$ cat myweb-rs-named.yml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myweb-rs-naemd
spec:
  replicas: 3
  selector:
    matchExpressions:
      - key: app
        operator: In
        values:
          - web
      - key: env
        operator: Exists
  template:
    metadata:
      labels:
        app: web
        env: dev
    spec:
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb
          ports:
            - containerPort: 8080
              protocol: TCP
              name: web8080 # containerPort/protocol 의 alias 를 뜻함. 즉, 8080/TCP 라고 생각하면 된다.

[~/k8s/svc]$ cat myweb-svc-named.yml
apiVersion: v1
kind: Service
metadata:
  name: myweb-svc-named
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: web8080 # containerPort/protocol 의 alias 를 가져온다.

[~/k8s/svc]$ kubectl get svc,ep,rs,pod
NAME                      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
service/kubernetes        ClusterIP   10.96.0.1        <none>        443/TCP   35h
service/myweb-svc-named   ClusterIP   10.110.107.247   <none>        80/TCP    4s

NAME                        ENDPOINTS                                         AGE
endpoints/kubernetes        192.168.49.2:8443                                 35h
endpoints/myweb-svc-named   10.244.0.4:8080,10.244.1.3:8080,10.244.2.5:8080   4s

NAME                             DESIRED   CURRENT   READY   AGE
replicaset.apps/myweb-rs-naemd   3         3         3       4s

NAME                       READY   STATUS    RESTARTS   AGE
pod/myweb-rs-naemd-4qs2k   1/1     Running   0          4s
pod/myweb-rs-naemd-ctnrn   1/1     Running   0          4s
pod/myweb-rs-naemd-xfgfj   1/1     Running   0          4s

name 필드로 containerPort/protocol 의 alias 를 사용하여 쓸 수 있다.

multi-port

[~/k8s/svc]$ cat myweb-svc-multi.yml
apiVersion: v1
kind: Service
metadata:
  name: myweb-svc-multi
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080
      name: http
    - port: 443
      targetPort: 8443
      name: https
[~/k8s/svc]$ cat myweb-rs-multi.yml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myweb-rs-multi
spec:
  replicas: 3
  selector:
    matchExpressions:
      - key: app
        operator: In
        values:
          - web
      - key: env
        operator: Exists
  template:
    metadata:
      labels:
        app: web
        env: dev
    spec:
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb
          ports:
            - containerPort: 8080
              protocol: TCP
            - containerPort: 8443
              protocol: TCP

[~/k8s/svc]$ kubectl get svc,ep,rs,pod
NAME                      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/kubernetes        ClusterIP   10.96.0.1       <none>        443/TCP          35h
service/myweb-svc-multi   ClusterIP   10.104.41.191   <none>        80/TCP,443/TCP   5s

NAME                        ENDPOINTS                                                     AGE
endpoints/kubernetes        192.168.49.2:8443                                             35h
endpoints/myweb-svc-multi   10.244.0.5:8443,10.244.1.4:8443,10.244.2.6:8443 + 3 more...   5s

NAME                             DESIRED   CURRENT   READY   AGE
replicaset.apps/myweb-rs-multi   3         3         3       46s

NAME                       READY   STATUS    RESTARTS   AGE
pod/myweb-rs-multi-489wk   1/1     Running   0          46s
pod/myweb-rs-multi-fbvhm   1/1     Running   0          46s
pod/myweb-rs-multi-jqcl2   1/1     Running   0          46s

multi-port 는 말 그대로 포트를 여러개 열어놓고 해당하는 포트로 들어올 경우 연결된 포트로 포워딩 시켜준다.

여기서는 80 으로 들어올 경우 8080 으로 포워딩하고 443 으로 들어올 경우 8443 으로 포워딩 해준다.

Service Discovery - DNS

SVC 로드 밸런서를 찾을 수 있는 DNS 이름이 필요로 하다.

환경 변수를 이용한 Service Discovery

모든 파드는 실행 시 현재 시점의 서비스 목록을 환경 변수로 제공한다.

[~/k8s/svc]$ kubectl run nettool -it --image ghcr.io/c1t1d0s7/network-multitool --rm
/ # env
MYWEB_SVC_PORT_80_TCP_ADDR=10.108.235.162
PWD=/
KUBERNETES_SERVICE_HOST=10.96.0.1
MYWEB_SVC_SERVICE_PORT=80
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_SERVICE_PORT_HTTPS=443
MYWEB_SVC_PORT=tcp://10.108.235.162:80
MYWEB_SVC_SERVICE_HOST=10.108.235.162
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=443
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
TERM=xterm
MYWEB_SVC_PORT_80_TCP=tcp://10.108.235.162:80
HOME=/root
SHLVL=1
HOSTNAME=nettool
MYWEB_SVC_PORT_80_TCP_PROTO=tcp
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.96.0.1:443
MYWEB_SVC_PORT_80_TCP_PORT=80

DNS 를 이용한 Service Discovery

host 명령어는 DNS 서버에 쿼리하는 명령어이다.

/ # host myweb-svc
myweb-svc.default.svc.cluster.local has address 10.108.235.162

myweb-svc.default.svc.cluster.local 는 FQDN 으로 완전한 주소 이름이다.

쿠버네티스 내부에서 FQDN 은 [서비스_이름].[Name_Space].[오브젝트_타입].[Domain] 으로 구성된다.

cat /etc/resolv.conf
nameserver 169.254.25.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

여기서 nameserver 는 coredns 주소가 아닌 nodelocal DNS(DNS Cache Server) 주소이다.

search default.svc.cluster.local svc.cluster.local cluster.local 라고 되어있는 데 myweb-svc 를 질의를 던질 때 myweb-svc 뒤에 search 에 있는 것을 하나씩 붙여서 DNS 에 쿼리를 날리는 것이다.

즉, myweb-svc 로 쿼리를 날리면 myweb-svc.default.svc.cluster.local 라는 FQDN 을 만들어서 쿼리를 날린다.

만약 myweb-svc.default 로 쿼리를 날리면 search 순서에 따라 myweb-svc.default.default.svc.cluster.local 으로 쿼리를 날린다. 당연하게도 쿼리가 실패하게 되고 그 다음 search 를 붙여서 쿼리를 날린다. 즉, svc.cluster.local 를 붙여서 myweb-svc.default.svc.cluster.local 를 쿼리로 날리는 것이다.

/ # host myweb-svc
myweb-svc.default.svc.cluster.local has address 10.108.235.162
/ # host myweb-svc.default
myweb-svc.default.svc.cluster.local has address 10.108.235.162
/ # host myweb-svc.default.svc
myweb-svc.default.svc.cluster.local has address 10.108.235.162
/ # host myweb-svc.default.svc.cluster.local
myweb-svc.default.svc.cluster.local has address 10.108.235.162

만약 Name Space 가 dev 일 경우

공식 문서: https://kubernetes-docsy-staging.netlify.app/ko/docs/concepts/services-networking/dns-pod-service/, https://kubernetes.io/ko/docs/tasks/administer-cluster/dns-custom-nameservers/

Name Space 가 default 가 아닐 경우에는 dns 서버에 쿼리를 날려도 호스트 IP 를 가져올 수 없다. 왜냐하면 etc/resolv.conf 의 search 에 세팅된 Name Space 가 dev 로 설정되어 있기 때문이다.

그래서 Name Space 가 default 인 녀석을 추가해줘야 한다.

kubectl create ns dev
kubectl run nettool -it --image ghcr.io/c1t1d0s7/network-multitool --rm --namespace=dev --overrides='{"spec": { "dnsConfig": { "searches": ["default.svc.cluster.local"] } }}'

run 할 때 --overrides 옵션을 사용하여 default.svc.cluster.local 을 추가해준다.

--overrides='{"spec": { "dnsConfig": { "searches": ["default.svc.cluster.local"] } }}'

nodelocal DNS(DNS Cache Server, DNS Forwarder)

공식 문서: https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/

Cache Hit: 캐시 서버에 캐싱된 값을 돌려준다.

Cache miss: 캐시 서버에 캐싱되지 않아 실제 서버에 쿼리를 보내서 값을 가져온다.

vagrant@node-1 ~ » sudo ss -tnlp
State  Recv-Q Send-Q     Local Address:Port    Peer Address:Port Process
LISTEN 0      4096       169.254.25.10:9254         0.0.0.0:*     users:(("node-cache",pid=1978,fd=7))
LISTEN 0      4096           127.0.0.1:10248        0.0.0.0:*     users:(("kubelet",pid=772,fd=21))
....

169.254.25.10:9254 을 보면 node-cache 로 되어있는데 이게 바로 nodelocal DNS 이다.

가상의 DNS 로, pod 가 어떤 노드에 배치되든 간에 pod 는 coredns SVC(kube-system NS) 로 바로 쿼리를 날리지 않고 nodelocal DNS 에 쿼리를 날린다.

Cache DNS Server 에 실질적인 레코드는 없고 pod 로 부터 쿼리를 받으면 해당 쿼리를 대신해서 DNS Server 에 보내고 DNS Answer 가 오면 해당 값을 캐싱한다.

vagrant@node-1 ~ » kubectl get pod -A                                                            
NAMESPACE     NAME                                      READY   STATUS    RESTARTS        AGE
....
kube-system   nodelocaldns-42hw5                        1/1     Running   50 (179m ago)   3d21h
kube-system   nodelocaldns-4rdnt                        1/1     Running   32 (178m ago)   3d21h
kube-system   nodelocaldns-kdz54                        1/1     Running   3 (177m ago)    24h

실행 중인 각각의 노드 마다 하나의 nodelocaldns 가 세팅된 것을 확인할 수 있다.

nodelocal DNS 캐시 사용 시

Pod --dns → DNS Cache Server → coredns SVC(kube-system NS) → coredns Pod

nodelocal DNS 캐시 사용 X

Pod --dns → corends SVC(kube-system NS) → coredns Pod

Service - nodePort

NodePort의 범위: 30000-32767

ClusterIP: 클러스터 내부에서 사용하는 LB
Load Balancer: 클러스터 외부에서 접근하는 LB
NodePort: 클러스터 외부에서 접근하는 포트

Service - LoadBalancer

Metallb - Addon

metallb 공식 문서: https://metallb.universe.tf/

kubespray metallb 설치 공식문서: https://kubespray.io/#/docs/metallb?id=metallb

https://cyuu.tistory.com/170

https://velog.io/@youwins/MetalLB

bareMetal 환경에서 LoadBalancer type의 서비스를 만들기 위해 사용한다.

왜 metalLB을 사용하느냐 클라우드 없이 LoadBalancer type의 서비스를 구현할 때 사용한다.

Pod는 휘발성을 가지므로 고정된 엔드포인트를 자체적으로 가지기 힘들다. Kubernetes의 Pod는 상황에 따라 소멸-재생성을 반복하게 된다. 문제는 이 때마다 지정되는 IP가 바뀌어 엔드포인트로 호출이 어렵다. 또한 여러 Pod에 같은 애플리케이션을 운용할 때 어느 Pod로 트래픽을 보낼지 결정해주는 로드밸런싱 기능이 필요하다.
Service가 고정된 IP로 Pod에 접근할 수 있게 해준다. Kubernetes에서는 Service가 Pod의 한계를 보완해주는 역할을 한다. Service는 4개의 Type-ClusterIP, NodePort, LoadBalancer, ExternalName-으로 나누어져 있다. 각 타입별로 네트워크 구성이 달라진다. 상용 서비스에서 외부로 IP를 노출시킬 때는 LoadBalancer Type을 주로 사용한다. 더 상세한 설명은 여기를 참고
Service type 중 LoadBalancer type을 쓰려면 External IP를 만들어줘야한다. LoadBalancer type을 쓰려면 로드밸런서에 외부에서 접근가능한 External IP(외부 IP)를 만들어 줘야 한다. 기존에는 이 LoadBalancer Type의 Kubernetes Service 객체를 만들려면 클라우드 공급자(ex IBM 클라우드, AWS, GCP 등)가 제공해주는 IP를 사용해야 했다. 이 IP가 없으면 External IP에 영원히 pending이라고 찍혀있는 것을 봐야했다. 그럼 만약 클라우드 서비스를 못쓰는 환경이라면 어떻게 해야할까
**MetalLB를 활용하면 클라우드 공급자에서 실행되지 않는 클러스터에서도 External IP를 할당할 수 있고, 결과적으로 LoadBalancer Type의 Service 객체를 만들 수 있다.** 이름부터 BareMetal LoadBalancer.

kubespray 에는 group_vars 를 변경하는 것으로 아주 간단하게 metallb 를 설치할 수 있다.

아래를 참고하여 설치할 수 있다.

~/kubespray/inventory/mycluster/group_vars/k8s_cluster/addons.yml

...
138 # MetalLB deployment
139 metallb_enabled: true
140 metallb_speaker_enabled: true
141 metallb_ip_range:
142   - "192.168.100.240-192.168.100.249"
...
168 metallb_protocol: "layer2"
...

~/kubespray/inventory/mycluster/group_vars/k8s_cluster/k8s_cluster.yml

129 kube_proxy_strict_arp: true

cd ~/kubespray
ansible-playbook -i inventory/mycluster/inventory.ini cluster.yml

Metallb 는 Layer2 모드(소규모 10대 미만)와 BGP 모드(대규모 10대 이상) 두 가지 방식이 있다. 디폴트는 layer2 방식이다.

Metallb 는 Layer2 모드로 실행할 경우 각각의 노드에 speaker 파드가 띄워진다. 그리고 contoller 파드가 띄워지는데 이게 바로 LB 역할을 해준다.

정리하면 사용자가 speaker 파드의 IP 주소로 접속을 하면 speaker 파드는 controller 파드로 보내준다. 이 controller 가 LB 역할을 하고 뒷단에 연결된 NodePort 중 하나로 보내주고 NodePort 가 연결된 Service 로 보내주게 된다. 그 후에 Service 에 연결된 파드들로 분배된다.

즉, 정리하자면 speker → controller(LB) → NodePort → SVC → Pod 로 이동한다.

BGP 모드를 사용하기 위해서는 물리적인 L3 스위치가 있어야 한다.

L3 스위치가 로드 밸런서의 역할을 하고 서비스로 분배해준다. 이게 옳게 된 구성이다.

Service - ExternalName

클러스터 내부에서 클러스터 외부의 특정 서비스에 접속하기 위해 DNS CANME 을 설정

vagrant@node-1 svc/extname » cat weather-svc.yml
apiVersion: v1
kind: Service
metadata:
  name: weather-service
spec:
  type: ExternalName
  externalName: wttr.in

vagrant@node-1 svc/extname » kubectl get svc
NAME              TYPE           CLUSTER-IP     EXTERNAL-IP       PORT(S)        AGE
kubernetes        ClusterIP      10.233.0.1     <none>            443/TCP        4d
myweb-svc-np      LoadBalancer   10.233.22.31   192.168.100.240   80:31313/TCP   49m
weather-service   ExternalName   <none>         google.com        <none>         10m

외부 IP

하나 이상의 클러스터 노드로 라우팅되는 외부 IP가 있는 경우, 쿠버네티스 서비스는 이러한 externalIPs에 노출될 수 있다. 서비스 포트에서 외부 IP (목적지 IP)를 사용하여 클러스터로 들어오는 트래픽은 서비스 엔드포인트 중 하나로 라우팅된다. externalIPs는 쿠버네티스에 의해 관리되지 않으며 클러스터 관리자에게 책임이 있다.

서비스 명세에서, externalIPs는 모든 ServiceTypes와 함께 지정할 수 있다. 아래 예에서, 클라이언트는 "80.11.12.10:80"(외부 IP:포트)로 "my-service"에 접근할 수 있다.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376
  externalIPs:
    - 80.11.12.10

Service - Ingress

공식 문서: https://kubernetes.io/ko/docs/concepts/services-networking/ingress-controllers/

인그레스 컨트롤러

인그레스 리소스가 작동하려면, 클러스터는 실행 중인 인그레스 컨트롤러가 반드시 필요하다.

kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는 클러스터와 함께 자동으로 실행되지 않는다. 클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다.

프로젝트로서 쿠버네티스는 AWS, GCE와 nginx 인그레스 컨트롤러를 지원하고 유지한다.

인그레스(Ingress)

클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리함.

인그레스는 부하 분산, SSL Termination, 명칭 기반의 가상 호스팅을 제공할 수 있다.

인그레스는 클러스터 외부에서 클러스터 내부 서비스로 HTTP와 HTTPS 경로를 노출한다. 트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다.

다음은 인그레스가 모든 트래픽을 하나의 서비스로 보내는 간단한 예시이다.

서비스의 타입은 일반적으로 NodePort 타입이다.

인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. 인그레스 컨트롤러는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.

인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통 Service.Type=NodePort 또는 Service.Type=LoadBalancer 유형의 서비스를 사용한다.

ingress-example.yml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx-example
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

여기서 rules 는 라우팅 규칙을 뜻한다

pathType

Exact: URL 경로의 대소문자를 엄격하게 일치시킨다.
Prefix: URL 경로의 접두사를 / 를 기준으로 분리한 값과 일치시킨다. 일치는 대소문자를 구분하고, 요소별로 경로 요소에 대해 수행한다. 모든 p 가 요청 경로의 요소별 접두사가 p 인 경우 요청은 p 경로에 일치한다.
implementationSpecific: 이 경로 유형의 일치 여부는 IngressClass에 따라 달라진다. 이를 구현할 때 별도 pathType 으로 처리하거나, Prefix 또는 Exact 경로 유형과 같이 동일하게 처리할 수 있다.

backend

resource: 다른 쿠버네티스의 리소스 그룹을 넣어줄 수 있다.
- api Group
- kind
- name
service
- name: 실제 서비스의 이름을 지정한다.
- port:
  - name: 포트 이름
  - number: 포트 번호

전제 조건들

인그레스 컨트롤러가 있어야 인그레스를 충족할 수 있다. 인그레스 리소스만 생성한다면 효과가 없다.

ingress-nginx와 같은 인그레스 컨트롤러를 배포해야 할 수도 있다. 여러 인그레스 컨트롤러 중에서 선택할 수도 있다.

이상적으로, 모든 인그레스 컨트롤러는 참조 사양이 맞아야 한다. 실제로, 다양한 인그레스 컨트롤러는 조금 다르게 작동한다.

kubespray 에 ingress-nginx 설치

간단하게 애드온 설정 파일에서 ingress-nginx 를 true 로 설정하면 된다.

Niginx Ingress Controller

~/kubespray/inventory/mycluster/group_vars/k8s-cluster/addons.yml

 93 ingress_nginx_enabled: true

metrics-server

~/kubespray/inventory/mycluster/group_vars/k8s-cluster/addons.yml

 16 metrics_server_enabled: true

아래 명령어를 사용하여 애드온을 kubespray 에 적용한다.

cd ~/kubespray
ansible-playbook -i inventory/mycluster/inventory.ini cluster.yml -b

인그레스 리소스

다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 apiVersion, kind, 그리고 metadata 필드가 필요하다.

인그레스 오브젝트의 이름은 유효한 DNS 서브도메인 이름이어야 한다. 설정 파일의 작성에 대한 일반적인 내용은 애플리케이션 배포하기, 컨테이너 구성하기, 리소스 관리하기를 참조한다.

인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데, 그 예시는 재작성-타겟 어노테이션이다. 서로 다른 인그레스 컨트롤러는 서로 다른 어노테이션을 지원한다. 지원되는 어노테이션을 확인하려면 선택한 인그레스 컨트롤러의 설명서를 검토한다.

인그레스 사양 에는 로드 밸런서 또는 프록시 서버를 구성하는데 필요한 모든 정보가 있다. 가장 중요한 것은, 들어오는 요청과 일치하는 규칙 목록을 포함하는 것이다. 인그레스 리소스는 HTTP(S) 트래픽을 지시하는 규칙만 지원한다.

인그레스 규칙

각 HTTP 규칙에는 다음의 정보가 포함된다.

선택적 호스트. 이 예시에서는, 호스트가 지정되지 않기에 지정된 IP 주소를 통해 모든 인바운드 HTTP 트래픽에 규칙이 적용 된다. 만약 호스트가 제공되면(예, foo.bar.com), 규칙이 해당 호스트에 적용된다.
경로 목록 (예, /testpath)에는 각각 service.name 과 service.port.name 또는 service.port.number 가 정의되어 있는 관련 백엔드를 가지고 있다. 로드 밸런서가 트래픽을 참조된 서비스로 보내기 전에 호스트와 경로가 모두 수신 요청의 내용과 일치해야 한다.
백엔드는 서비스 문서 또는 사용자 정의 리소스 백엔드에 설명된 바와 같이 서비스와 포트 이름의 조합이다. 호스트와 규칙 경로가 일치하는 인그레스에 대한 HTTP(와 HTTPS) 요청은 백엔드 목록으로 전송된다.

defaultBackend 는 종종 사양의 경로와 일치하지 않는 서비스에 대한 모든 요청을 처리하도록 인그레스 컨트롤러에 구성되는 경우가 많다.

DefaultBackend

규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. defaultBackend 는 일반적으로 인그레스 컨트롤러의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.

만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은 기본 백엔드로 라우팅 된다.

리소스 백엔드

Resource 백엔드는 인그레스 오브젝트와 동일한 네임스페이스 내에 있는 다른 쿠버네티스 리소스에 대한 ObjectRef이다. Resource 는 서비스와 상호 배타적인 설정이며, 둘 다 지정하면 유효성 검사에 실패한다. Resource 백엔드의 일반적인 용도는 정적 자산이 있는 오브젝트 스토리지 백엔드로 데이터를 수신하는 것이다.

아래와 같은 방식으로 구성을 할 수 있다.

myweb-rs-np.yml

vagrant@node-1 cont/ing » cat myweb-rs-np.yml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myweb-rs-set
spec:
  replicas: 3
  selector:
    matchExpressions:
      - key: app
        operator: In
        values:
          - web
      - key: env
        operator: Exists
  template:
    metadata:
      labels:
        app: web
        env: dev
    spec:
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb
          ports:
            - containerPort: 8080
              protocol: TCP

myweb-svc-np.yml

vagrant@node-1 cont/ing » cat myweb-svc-np.yml
apiVersion: v1
kind: Service
metadata:
  name: myweb-svc-np
spec:
  type: NodePort
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

myweb-ing.yml

vagrant@node-1 cont/ing » cat myweb-ing.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  rules:
  - http:
      paths:
      - pathType: Prefix
        path: /
        backend:
          service:
            name: myweb-svc-np
            port:
              number: 80

도메인을 구매하지 않고 호스트 필드 사용하기

vagrant@node-1 cont/ing » cat myweb-ing.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  rules:
	- host: '*.test.xyz'
    http:
      paths:
      - pathType: Prefix
        path: /
        backend:
          service:
            name: myweb-svc-np
            port:
              number: 80

방법 1

curl --resolve 옵션을 사용

curl --resolve <host>:<port>:<ingress_ip> <host>

curl --resolve www.test.xyz:80:192.168.100.103 www.test.xyz

방법 2

/etc/nsswitch.conf 에서 hosts 가 files dns 로 되어있는지 확인

/etc/hosts 파일 수정

...
192.168.100.103 www.test.xyz

curl <http://www.test.xyz>

방법 3

https://nip.io/

와일드 카드 DNS 서비스를 사용한다.

와일드 카드 DNS: 어떤 URL 을 요청해도 response 를 돌려준다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  rules:
    - host: '*.nip.io'
      http:
        paths:
        - pathType: Prefix
          path: /
          backend:
            service:
              name: myweb-svc-np
              port:
                number: 80

vagrant@node-1 cont/ing » curl <http://app-192-168-100-103.nip.io>
Hello World!
myweb-rs-set-l6z59

Ingress 예제

이미지 생성 및 레지스트리에 푸시
레플리카셋 구성
서비스 구성(NodePort 타입)
인그레스 구성

hello:one 이미지 Dockerfile

FROM httpd
COPY index.html /usr/local/apache2/htdocs/index.html

index.html

<h1> Hello One </h1>

hello:two 이미지 Dockerfile

FROM httpd
COPY index.html /usr/local/apache2/htdocs/index.html

index.html

<h1> Hello Two </h1>

docker image build X/hello:one
docker image build X/hello:two

docker login

docker push X/hello:one
docker push X/hello:two

one-rs.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: one-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-one
  template:
    metadata:
      labels:
        app: hello-one
    spec:
      containers:
        - name: hello-one
          image: c1t1d0s7/hello:one
          ports:
            - containerPort: 80
              protocol: TCP

two-rs.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: two-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-two
  template:
    metadata:
      labels:
        app: hello-two
    spec:
      containers:
        - name: hello-two
          image: c1t1d0s7/hello:two
          ports:
            - containerPort: 80
              protocol: TCP

one-svc-np.yaml

apiVersion: v1
kind: Service
metadata:
  name: one-svc-np
spec:
  type: NodePort
  selector:
    app: hello-one
  ports:
    - port: 80
      targetPort: 80

two-svc-np.yaml

apiVersion: v1
kind: Service
metadata:
  name: two-svc-np
spec:
  type: NodePort
  selector:
    app: hello-two
  ports:
    - port: 80
      targetPort: 80

hello-ing.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-ing
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: '*.nip.io'
      http:
        paths:
          - path: /one
            pathType: Prefix
            backend:
              service:
                name: one-svc-np
                port:
                  number: 80
          - path: /two
            pathType: Prefix
            backend:
              service:
                name: two-svc-np
                port:
                  number: 80

x.nip.io/one 으로 접속을 하게 되면 pod_ip/one 주소로 접속하게 된다. 현재 /one 경로에는 아무런 값이 없기 때문에 x.nip.io/one 으로 접속해도 / 경로로 접속이 되어야 한다.

그래서 어노테이션에서 nginx.ingress.kubernetes.io/rewrite-target: / 을 사용했다. rewrite-target: / 은 어떤 경로로 들어오든 간에 타겟 경로를 / 경로로 들어오도록 변경하는 것이다.

kubectl create -f .

curl http://192-168-100-103.nip.io/one
<h1> Hello One </h1>

curl http://192-168-100-103.nip.io/two
<h1> Hello Two </h1>

Readiness Probe

서비스에 파드를 연결시키기 전에 파드의 상태가 정상적인지 확인(헬스 체크)을 하고 엔드포인트에 등록을 시켜준다.

myweb-rs-set.yml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myweb-rs-set
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
      env: dev
  template:
    metadata:
      labels:
        app: web
        env: dev
    spec:
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb:alpine
          ports:
            - containerPort: 8080
              protocol: TCP
          readinessProbe:
            exec:
              command:
                - ls
                - /tmp/ready

myweb-svc-np.yml

apiVersion: v1
kind: Service
metadata:
  name: myweb-svc-np
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 31313

readiness probe 가 ls /tmp/ready 명령어를 실행하여 제대로 작동을 하는지 헬스 체크를 한다. 하지만 현재 pod 에는 해당 파일이 존재하지 않기 때문에 비정상적인 파드라고 판단을 하여 파드가 준비 상태로 변하지 않는다. 따라서 endpoint 에 파드의 IP 주소가 등록되지 않는다.

vagrant@node-1 cont/readiness » kubectl get pod,svc,rs,ep
NAME                     READY   STATUS    RESTARTS   AGE
pod/myweb-rs-set-b7mxc   0/1     Running   0          7m48s
pod/myweb-rs-set-wknpx   0/1     Running   0          7m48s
pod/myweb-rs-set-x74kb   0/1     Running   0          7m48s

NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP       PORT(S)        AGE
service/kubernetes     ClusterIP      10.233.0.1     <none>            443/TCP        6d21h
service/myweb-svc-np   LoadBalancer   10.233.53.30   192.168.100.240   80:31313/TCP   7m48s

NAME                           DESIRED   CURRENT   READY   AGE
replicaset.apps/myweb-rs-set   3         3         0       36s

NAME                     ENDPOINTS              AGE
endpoints/kubernetes     192.168.100.103:6443   6d21h
endpoints/myweb-svc-np                          36s

아래 명령어를 사용하여 파드에 /tmp/ready 파일을 생성하면 pod 가 준비 상태가 되고 서비스에 연결된다.

kubectl exec <POD> -- touch /tmp/ready

vagrant@node-1 cont/readiness » kubectl exec myweb-rs-set-b7mxc -- touch /tmp/ready
vagrant@node-1 cont/readiness » kubectl exec myweb-rs-set-wknpx -- touch /tmp/ready
vagrant@node-1 cont/readiness » kubectl exec myweb-rs-set-x74kb -- touch /tmp/ready

vagrant@node-1 cont/readiness » kubectl get pod,svc,rs,ep
NAME                     READY   STATUS    RESTARTS   AGE
pod/myweb-rs-set-b7mxc   1/1     Running   0          7m48s
pod/myweb-rs-set-wknpx   1/1     Running   0          7m48s
pod/myweb-rs-set-x74kb   1/1     Running   0          7m48s

NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP       PORT(S)        AGE
service/kubernetes     ClusterIP      10.233.0.1     <none>            443/TCP        6d21h
service/myweb-svc-np   LoadBalancer   10.233.53.30   192.168.100.240   80:31313/TCP   7m48s

NAME                           DESIRED   CURRENT   READY   AGE
replicaset.apps/myweb-rs-set   3         3         3       7m48s

NAME                     ENDPOINTS                                                 AGE
endpoints/kubernetes     192.168.100.103:6443                                      6d21h
endpoints/myweb-svc-np   10.233.109.23:8080,10.233.112.42:8080,10.233.69.54:8080   7m48s

[kubernetes] DaemonSet & Job

ssunw — Mon, 23 May 2022 12:59:08 +0900

crictl

container runtime interface controller 의 약자로 말 그대로 실행 중인 컨테이너를 제어하는 컨트롤러이다.

공식 문서: https://kubernetes.io/docs/reference/tools/map-crictl-dockercli/

k8s 에서 crictl 로 도커 명령어를 대신할 수 있다.

데몬셋

데몬셋은 모든(또는 일부) 노드가 파드의 사본을 실행하도록 한다. 노드가 클러스터에 추가되면 파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로 수집된다. 데몬셋을 삭제하면 데몬셋이 생성한 파드들이 정리된다.

데몬셋은 모든 노드에 하나씩 존재한다.

데몬셋의 일부 대표적인 용도는 다음과 같다. 주로 에이전트의 역할을 한다.

모든 노드에서 클러스터 스토리지 데몬 실행
모든 노드에서 로그 수집 데몬 실행
모든 노드에서 노드 모니터링 데몬 실행

단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다. 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, 각기 다른 하드웨어 유형에 따라 서로 다른 플래그, 메모리, CPU 요구가 달라진다.

myweb-ds.yml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: myweb-ds
spec:
  selector:
    matchExpressions:
      - key: app
        operator: In
        values:
          - myweb
      - key: env
        operator: Exists
  template:
    metadata:
      labels:
        app: myweb
        env: dev
    spec:
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb
          ports:
            - containerPort: 8080
              protocol: TCP

kubespray 에서 node 추가 및 삭제

https://kubespray.io/#/docs/getting-started

cd ~/kubespray

노드 제거

ansible-playbook inventory/mycluster/inventory.ini remove-node.yml -b --extra-vars "node=node-2,node-3" --extra-vars reset_nodes=false

노드 추가

ansible-playbook inventory/mycluster/inventory.ini scale.yml -b

잡

잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료될 때까지 계속해서 파드의 실행을 재시도한다. 파드가 성공적으로 완료되면, 성공적으로 완료된 잡을 추적한다. 지정된 수의 성공 완료에 도달하면, 작업(즉, 잡)이 완료된다. 잡을 삭제하면 잡이 생성한 파드가 정리된다. 작업을 일시 중지하면 작업이 다시 재개될 때까지 활성 파드가 삭제된다.

간단한 사례는 잡 오브젝트를 하나 생성해서 파드 하나를 안정적으로 실행하고 완료하는 것이다. 첫 번째 파드가 실패 또는 삭제된 경우(예로는 노드 하드웨어의 실패 또는 노드 재부팅) 잡 오브젝트는 새로운 파드를 기동시킨다.

잡을 사용하면 여러 파드를 병렬로 실행할 수도 있다.

파드 템플릿의 레이블 / 잡 컨트롤러의 레이블 셀렉터는 지정하지 않는다. → 잘못된 매핑으로 기존의 파드를 종료하지 않게 하기 위함이다.

잡 예제

다음은 잡 설정 예시이다. 예시는 파이(π)의 2000 자리까지 계산해서 출력한다. 이를 완료하는 데 약 10초가 소요된다.

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

kubectl 을 사용해서 잡 상태를 확인한다.

kubectl describe jobs/pi

출력 결과는 다음과 같다.

Name:           pi
Namespace:      default
Selector:       controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
Labels:         controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
                job-name=pi
Annotations:    kubectl.kubernetes.io/last-applied-configuration:
                  {"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":...
Parallelism:    1
Completions:    1
Start Time:     Mon, 02 Dec 2019 15:20:11 +0200
Completed At:   Mon, 02 Dec 2019 15:21:16 +0200
Duration:       65s
Pods Statuses:  0 Running / 1 Succeeded / 0 Failed
Pod Template:
  Labels:  controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
           job-name=pi
  Containers:
   pi:
    Image:      perl
    Port:       <none>
    Host Port:  <none>
    Command:
      perl
      -Mbignum=bpi
      -wle
      print bpi(2000)
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From            Message
  ----    ------            ----  ----            -------
  Normal  SuccessfulCreate  14m   job-controller  Created pod: pi-5rwd7

kubectl get pods 를 사용해서 잡의 완료된 파드를 본다.

잡에 속하는 모든 파드를 기계적으로 읽을 수 있는 양식으로 나열하려면, 다음과 같은 명령을 사용할 수 있다.

pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
echo $pods

출력 결과는 다음과 같다.

pi-5rwd7

여기서 셀렉터는 잡의 셀렉터와 동일하다. --output=jsonpath 옵션은 반환된 목록에 있는 각 파드의 이름으로 표현식을 지정한다.

파드 중 하나를 표준 출력으로 본다.

kubectl logs $pods

출력 결과는 다음과 같다.

3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901

잡 spec 작성하기

다른 쿠버네티스의 설정과 마찬가지로 잡에는 apiVersion, kind 그리고 metadata 필드가 필요하다. 잡의 이름은 유효한 DNS 서브도메인 이름이어야 한다.

잡에는 .spec 섹션도 필요하다.

파드 템플릿

.spec.template 은 .spec 의 유일한 필수 필드이다.

.spec.template 은 파드 템플릿이다. 이것은 apiVersion 또는 kind 가 없다는 것을 제외한다면 파드와 정확하게 같은 스키마를 가지고 있다.

추가로 파드의 필수 필드 외에도 잡의 파드 템플릿은 적절한 레이블(파드 셀렉터를 본다)과 적절한 재시작 정책을 명시해야 한다.

Never 또는 OnFailure 와 같은 RestartPolicy만 허용된다.

파드 셀렉터

.spec.selector 필드는 선택 사항이다. 대부분의 케이스에서 지정해서는 안된다. 자신의 파드 셀렉터를 지정하기 섹션을 참고한다.

잡에 대한 병렬 실행

잡으로 실행하기에 적합한 작업 유형은 크게 세 가지가 있다.

비-병렬(Non-parallel) 잡:
- 일반적으로, 파드가 실패하지 않은 한, 하나의 파드만 시작된다.
- 파드가 성공적으로 종료하자마자 즉시 잡이 완료된다.
고정적(fixed)인 완료 횟수 를 가진 병렬 잡:
- .spec.completions 에 0이 아닌 양수 값을 지정한다.
- 잡은 전체 작업을 나타내며, .spec.completions 성공한 파드가 있을 때 완료된다.
- .spec.completionMode="Indexed" 를 사용할 때, 각 파드는 0에서 .spec.completions-1 범위 내의 서로 다른 인덱스를 가져온다.
작업 큐(queue) 가 있는 병렬 잡:
- .spec.completions 를 지정하지 않고, .spec.parallelism 를 기본으로 한다.
- 파드는 각자 또는 외부 서비스 간에 조정을 통해 각각의 작업을 결정해야 한다. 예를 들어 파드는 작업 큐에서 최대 N 개의 항목을 일괄로 가져올(fetch) 수 있다.
- 각 파드는 모든 피어들의 작업이 완료되었는지 여부를 독립적으로 판단할 수 있으며, 결과적으로 전체 잡이 완료되게 한다.
- 잡의 모든 파드가 성공적으로 종료되면, 새로운 파드는 생성되지 않는다.
- 하나 이상의 파드가 성공적으로 종료되고, 모든 파드가 종료되면 잡은 성공적으로 완료된다.
- 성공적으로 종료된 파드가 하나라도 생긴 경우, 다른 파드들은 해당 작업을 지속하지 않아야 하며 어떠한 출력도 작성하면 안 된다. 파드들은 모두 종료되는 과정에 있어야 한다.

비-병렬 잡은 .spec.completions 와 .spec.parallelism 모두를 설정하지 않은 채로 둘 수 있다. 이때 둘 다 설정하지 않은 경우 1이 기본으로 설정된다.

고정적인 완료 횟수 잡은 .spec.completions 을 필요한 완료 횟수로 설정해야 한다. .spec.parallelism 을 설정할 수 있고, 설정하지 않으면 1이 기본으로 설정된다.

작업 큐 잡은 .spec.completions 를 설정하지 않은 상태로 두고, .spec.parallelism 을 음수가 아닌 정수로 설정해야 한다.

다른 유형의 잡을 사용하는 방법에 대한 더 자세한 정보는 잡 패턴 섹션을 본다.

병렬 처리 제어하기

parallelism: 3 일 경우 3개의 파드를 병렬적으로 처리한다.

요청된 병렬 처리(.spec.parallelism)는 음수가 아닌 값으로 설정할 수 있다. 만약 지정되지 않은 경우에는 1이 기본이 된다. 만약 0으로 지정되면 병렬 처리가 증가할 때까지 사실상 일시 중지된다.

실제 병렬 처리(모든 인스턴스에서 실행되는 파드의 수)는 여러가지 이유로 요청된 병렬 처리보다 많거나 적을 수 있다.

고정적인 완료 횟수(fixed completion count) 잡의 경우, 병렬로 실행 중인 파드의 수는 남은 완료 수를 초과하지 않는다. .spec.parallelism 의 더 큰 값은 사실상 무시된다.
작업 큐 잡은 파드가 성공한 이후에 새로운 파드가 시작되지 않는다. 그러나 나머지 파드는 완료될 수 있다.
만약 잡 컨트롤러 가 반응할 시간이 없는 경우
만약 잡 컨트롤러가 어떤 이유(ResourceQuota 의 부족, 권한 부족 등)로든 파드 생성에 실패한 경우, 요청한 것보다 적은 수의 파드가 있을 수 있다.
잡 컨트롤러는 동일한 잡에서 과도하게 실패한 이전 파드들로 인해 새로운 파드의 생성을 조절할 수 있다.
파드가 정상적으로(gracefully) 종료되면, 중지하는데 시간이 소요된다.

완료 모드

completions: 3 일 경우에는 첫 번째 파드를 만들어서 실행한 후 종료하고, 두 번째 파드를 만들고 실행한 후 종료하고, 세 번 째 파드를 만들고 실행한 후 종료한다. 즉 작업의 완료 횟수가 3번 이라는 뜻이다.

completions 의 수는 parallelism 의 수 보다 많아야 한다.

완료 횟수가 고정적인 완료 횟수 즉, null이 아닌 .spec.completions 가 있는 잡은 .spec.completionMode 에 지정된 완료 모드를 가질 수 있다.

NonIndexed (기본값): .spec.completions 가 성공적으로 완료된 파드가 있는 경우 작업이 완료된 것으로 간주된다. 즉, 각 파드 완료는 서로 상동하다(homologous). null .spec.completions 가 있는 잡은 암시적으로 NonIndexed 이다.
Indexed: 잡의 파드는 연결된 완료 인덱스를 0에서 .spec.completions-1 까지 가져온다. 이 인덱스는 다음의 세 가지 메카니즘으로 얻을 수 있다.
- 파드 어노테이션 batch.kubernetes.io/job-completion-index.
- 파드 호스트네임 중 일부($(job-name)-$(index) 형태). 인덱스된(Indexed) 잡과 서비스를 결합하여 사용하고 있다면, 잡에 속한 파드는 DNS를 이용하여 서로를 디스커버 하기 위해 사전에 결정된 호스트네임을 사용할 수 있다.
- 컨테이너화된 태스크의 경우, JOB_COMPLETION_INDEX 환경 변수.
각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로 간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은 정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡을 참고한다. 참고로, 드물기는 하지만, 동일한 인덱스에 대해 둘 이상의 파드를 시작할 수 있지만, 그 중 하나만 완료 횟수에 포함된다.

파드와 컨테이너 장애 처리하기

파드내 컨테이너의 프로세스가 0이 아닌 종료 코드로 종료되었거나 컨테이너 메모리 제한을 초과해서 죽는 등의 여러가지 이유로 실패할 수 있다. 만약 이런 일이 발생하고 .spec.template.spec.restartPolicy = "OnFailure" 라면 파드는 노드에 그대로 유지되지만, 컨테이너는 다시 실행된다. 따라서 프로그램은 로컬에서 재시작될 때의 케이스를 다루거나 .spec.template.spec.restartPolicy = "Never" 로 지정해야 한다. 더 자세한 정보는 파드 라이프사이클의 restartPolicy 를 본다.

파드가 노드에서 내보내지는 경우(노드 업그레이드, 재부팅, 삭제 등) 또는 파드의 컨테이너가 실패되고 .spec.template.spec.restartPolicy = "Never" 로 설정됨과 같은 여러 이유로 전체 파드가 실패할 수 있다.

파드가 실패하면 잡 컨트롤러는 새 파드를 시작한다. 이 의미는 애플리케이션이 새 파드에서 재시작될 때 이 케이스를 처리해야 한다는 점이다. 특히, 이전 실행으로 인한 임시파일, 잠금, 불완전한 출력 그리고 이와 유사한 것들을 처리해야 한다.

.spec.parallelism = 1, .spec.completions = 1 그리고 .spec.template.spec.restartPolicy = "Never" 를 지정하더라도 같은 프로그램을 두 번 시작하는 경우가 있다는 점을 참고한다.

.spec.parallelism 그리고 .spec.completions 를 모두 1보다 크게 지정한다면 한번에 여러 개의 파드가 실행될 수 있다. 따라서 파드는 동시성에 대해서도 관대(tolerant)해야 한다.

파드 백오프(backoff) 실패 정책

구성 등의 논리적 오류로 인해 약간의 재시도 이후에 잡을 실패하게 만들려는 경우가 있다.

이렇게 하려면 .spec.backoffLimit 에 잡을 실패로 간주하기 이전에 재시도할 횟수를 설정한다. 백오프 제한은 기본적으로 6으로 설정되어 있다.

잡과 관련한 실패한 파드는 최대 6분안에서 기하급수적으로 증가하는 백-오프 지연 (10초, 20초, 40초 ...) 한도가 되어 잡 컨트롤러에 의해 재생성된다. 잡의 파드가 삭제되거나 해당 시간 동안 잡에 대한 다른 파드가 실패 없이 성공했을 때 백 오프 카운트가 재설정된다.

참고: 만약 잡에 restartPolicy = "OnFailure" 가 있는 경우 잡 백오프 한계에 도달하면 잡을 실행 중인 파드가 종료된다. 이로 인해 잡 실행 파일의 디버깅이 더 어려워질 수 있다. 디버깅하거나 로깅 시스템을 사용해서 실패한 작업의 결과를 실수로 손실되지 않도록 하려면 restartPolicy = "Never" 로 설정하는 것을 권장한다.

잡의 종료와 정리

잡이 완료되면 파드가 더 이상 생성되지도 않지만, 일반적으로는 삭제되지도 않는다.

이를 유지하면 완료된 파드의 로그를 계속 보며 에러, 경고 또는 다른 기타 진단 출력을 확인할 수 있다.

잡 오브젝트는 완료된 후에도 상태를 볼 수 있도록 남아 있다. 상태를 확인한 후 이전 잡을 삭제하는 것은 사용자의 몫이다.

kubectl 로 잡을 삭제할 수 있다 (예: kubectl delete jobs/pi 또는 kubectl delete -f ./job.yaml). kubectl 을 사용해서 잡을 삭제하면 생성된 모든 파드도 함께 삭제된다.

기본적으로 파드의 실패(restartPolicy=Never) 또는 컨테이너가 오류(restartPolicy=OnFailure)로 종료되지 않는 한, 잡은 중단되지 않고 실행되고 이때 위에서 설명했던 .spec.backoffLimit 까지 연기된다. .spec.backoffLimit 에 도달하면 잡은 실패로 표기되고 실행 중인 모든 파드는 종료된다.

잡을 종료하는 또 다른 방법은 유효 데드라인을 설정하는 것이다. 잡의 .spec.activeDeadlineSeconds 필드를 초 단위로 설정하면 된다. activeDeadlineSeconds 는 생성된 파드의 수에 관계 없이 잡의 기간에 적용된다. 잡이 activeDeadlineSeconds 에 도달하면, 실행 중인 모든 파드가 종료되고 잡의 상태는 reason: DeadlineExceeded 와 함께 type: Failed 가 된다.

잡의 .spec.activeDeadlineSeconds 는 .spec.backoffLimit 보다 우선한다는 점을 참고한다. 따라서 하나 이상 실패한 파드를 재시도하는 잡은 backoffLimit 에 도달하지 않은 경우에도 activeDeadlineSeconds 에 지정된 시간 제한에 도달하면 추가 파드를 배포하지 않는다.

예시

apiVersion: batch/v1
kind: Job
metadata:
  name: pi-with-timeout
spec:
  backoffLimit: 5
  activeDeadlineSeconds: 100
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

잡의 사양과 잡의 파드 템플릿 사양에는 모두 activeDeadlineSeconds 필드가 있다는 점을 참고한다. 이 필드를 적절한 레벨로 설정해야 한다.

restartPolicy 는 잡 자체에 적용되는 것이 아니라 파드에 적용된다는 점을 유념한다. 잡의 상태가 type: Failed 이 되면, 잡의 자동 재시작은 없다. 즉, .spec.activeDeadlineSeconds 와 .spec.backoffLimit 로 활성화된 잡의 종료 메커니즘은 영구적인 잡의 실패를 유발하며 이를 해결하기 위해 수동 개입이 필요하다.

완료된 잡을 자동으로 정리

완료된 잡은 일반적으로 시스템에서 더 이상 필요로 하지 않는다. 시스템 내에 이를 유지한다면 API 서버에 부담이 된다. 만약 크론잡과 같은 상위 레벨 컨트롤러가 잡을 직접 관리하는 경우, 지정된 용량 기반 정리 정책에 따라 크론잡이 잡을 정리할 수 있다.

완료된 잡을 위한 TTL 메커니즘

완료된 잡 (Complete 또는 Failed)을 자동으로 정리하는 또 다른 방법은 잡의 .spec.ttlSecondsAfterFinished 필드를 지정해서 완료된 리소스에 대해 TTL 컨트롤러에서 제공하는 TTL 메커니즘을 사용하는 것이다.

TTL 컨트롤러는 잡을 정리하면 잡을 계단식으로 삭제한다. 즉, 잡과 함께 파드와 같은 종속 오브젝트를 삭제한다. 잡을 삭제하면 finalizer와 같은 라이프사이클 보증이 보장되는 것을 참고한다.

예시

apiVersion: batch/v1
kind: Job
metadata:
  name: pi-with-ttl
spec:
  ttlSecondsAfterFinished: 100
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

pi-with-ttl 잡은 완료 후 100 초 이후에 자동으로 삭제될 수 있다.

만약 필드를 0 으로 설정하면, 잡이 완료된 직후에 자동으로 삭제되도록 할 수 있다. 만약 필드를 설정하지 않으면, 이 잡이 완료된 후에 TTL 컨트롤러에 의해 정리되지 않는다.

Cron Job

크론잡은 반복 일정에 따라 잡을 만든다.

하나의 크론잡 오브젝트는 크론탭 (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 크론 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다.

크론잡은 백업, 리포트 생성 등의 정기적 작업을 수행하기 위해 사용된다. 각 작업은 무기한 반복되도록 구성해야 한다(예: 1일/1주/1달마다 1회). 작업을 시작해야 하는 해당 간격 내 특정 시점을 정의할 수 있다.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

크론 스케줄 문법

# ┌───────────── 분 (0 - 59)
# │ ┌───────────── 시 (0 - 23)
# │ │ ┌───────────── 일 (1 - 31)
# │ │ │ ┌───────────── 월 (1 - 12)
# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
# │ │ │ │ │                                   특정 시스템에서는 7도 일요일)
# │ │ │ │ │
# │ │ │ │ │
# * * * * *

예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정에도 시작되어야 한다는 뜻이다.

0 0 13 * 5

크론잡 스케줄 표현을 생성하기 위해서 crontab.guru와 같은 웹 도구를 사용할 수도 있다.

모든 크론잡에 대해 크론잡 컨트롤러는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다.

Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.

중요한 것은 만약 startingDeadlineSeconds 필드가 설정이 되면(nil 이 아닌 값으로), 컨트롤러는 마지막 일정부터 지금까지 대신 startingDeadlineSeconds 값에서 몇 개의 잡이 누락되었는지 카운팅한다. 예를 들면, startingDeadlineSeconds 가 200 이면, 컨트롤러는 최근 200초 내 몇 개의 잡이 누락되었는지 카운팅한다.

크론잡은 정해진 일정에 잡 실행을 실패하면 놓쳤다고 카운팅된다. 예를 들면, concurrencyPolicy 가 Forbid 로 설정되었고, 크론잡이 이전 일정이 스케줄되어 여전히 시도하고 있을 때, 그 때 누락되었다고 판단한다.

즉, 크론잡이 08:30:00 에 시작하여 매 분마다 새로운 잡을 실행하도록 설정이 되었고, startingDeadlineSeconds 값이 설정되어 있지 않는다고 가정해보자. 만약 크론잡 컨트롤러가 08:29:00 부터 10:21:00 까지 고장이 나면, 일정을 놓친 작업 수가 100개를 초과하여 잡이 실행되지 않을 것이다.

이 개념을 더 자세히 설명하자면, 크론잡이 08:30:00 부터 매 분 실행되는 일정으로 설정되고, startingDeadlineSeconds 이 200이라고 가정한다. 크론잡 컨트롤러가 전의 예시와 같이 고장났다고 하면 (08:29:00 부터 10:21:00 까지), 잡은 10:22:00 부터 시작될 것이다. 이 경우, 컨트롤러가 마지막 일정부터 지금까지가 아니라, 최근 200초 안에 얼마나 놓쳤는지 체크하기 때문이다. (여기서는 3번 놓쳤다고 체크함)

크론잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고, 잡은 그 잡이 대표하는 파드 관리에 책임이 있다.

[kubernetes] Controller

ssunw — Mon, 23 May 2022 12:54:36 +0900

Controller

워크로드는 쿠버네티스에서 구동되는 애플리케이션이다. 컨트롤러는 하나 이상의 파드의 집합이다.

각 Pod 를 직접 관리할 필요는 없도록 만들었다. 대신, 사용자를 대신하여 파드 집합을 관리하는 워크로드 리소스를 사용할 수 있다. 이러한 리소스는 지정한 상태와 일치하도록 올바른 수의 올바른 파드 유형이 실행되고 있는지 확인하는 컨트롤러를 구성한다.

쿠버네티스는 다음과 같이 여러 가지 빌트인(built-in) 워크로드 리소스를 제공한다.

Deployment 및 ReplicaSet (레거시 리소스 레플리케이션 컨트롤러(ReplicationController)를 대체). Deployment 는 Deployment 의 모든 Pod 가 필요 시 교체 또는 상호 교체 가능한 경우, 클러스터의 스테이트리스 애플리케이션 워크로드를 관리하기에 적합하다.
StatefulSet는 어떻게든 스테이트(state)를 추적하는 하나 이상의 파드를 동작하게 해준다. 예를 들면, 워크로드가 데이터를 지속적으로 기록하는 경우, 사용자는 Pod 와 PersistentVolume을 연계하는 StatefulSet 을 실행할 수 있다. 전체적인 회복력 향상을 위해서, StatefulSet 의 Pods 에서 동작 중인 코드는 동일한 StatefulSet 의 다른 Pods 로 데이터를 복제할 수 있다.
DaemonSet은 노드-로컬 기능(node-local facilities)을 제공하는 Pods 를 정의한다. 이러한 기능들은 클러스터를 운용하는 데 기본적인 것일 것이다. 예를 들면, 네트워킹 지원 도구 또는 add-on 등이 있다. DaemonSet 의 명세에 맞는 노드를 클러스터에 추가할 때마다, 컨트롤 플레인은 해당 신규 노드에 DaemonSet 을 위한 Pod 를 스케줄한다.
Job 및 CronJob은 실행 완료 후 중단되는 작업을 정의한다. CronJobs 이 스케줄에 따라 반복되는 반면, 잡은 단 한 번의 작업을 나타낸다.

Replication Controller

디플로이먼트나 레플리카셋을 더 추천한다.

레플리케이션 컨트롤러의 동작방식

파드가 너무 많으면 레플리케이션 컨트롤러가 추가적인 파드를 제거한다. 너무 적으면 레플리케이션 컨트롤러는 더 많은 파드를 시작한다. 수동으로 생성된 파드와 달리 레플리케이션 컨트롤러가 유지 관리하는 파드는 실패하거나 삭제되거나 종료되는 경우 자동으로 교체(새로운 파드를 만들어서 교체)된다.

예를 들어, 커널 업그레이드와 같이 파괴적인 유지 보수 작업을 하고 난 이후의 노드에서 파드가 다시 생성된다. 따라서 애플리케이션에 하나의 파드만 필요한 경우에도 레플리케이션 컨트롤러를 사용해야 한다.

레플리케이션 컨트롤러는 프로세스 감시자(supervisor)와 유사하지만 단일 노드에서 개별 프로세스를 감시하는 대신 레플리케이션 컨트롤러는 여러 노드에서 여러 파드를 감시한다.

레플리케이션 컨트롤러는 디스커션에서 종종 "rc"로 축약되며 kubectl 명령에서 숏컷으로 사용된다.

간단한 경우는 하나의 레플리케이션 컨트롤러 오브젝트를 생성하여 한 개의 파드 인스턴스를 영구히 안정적으로 실행하는 것이다. 보다 복잡한 사용 사례는 웹 서버와 같이 복제된 서비스의 동일한 레플리카를 여러 개 실행하는 것이다.

vagrant@node-1 cont/rc » kubectl explain rc.spec
KIND:     ReplicationController
VERSION:  v1

RESOURCE: spec 

DESCRIPTION:
     Spec defines the specification of the desired behavior of the replication
     controller. More info:
     <https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status>

     ReplicationControllerSpec is the specification of a replication controller.

FIELDS:
   minReadySeconds      
     Minimum number of seconds for which a newly created pod should be ready
     without any of its container crashing, for it to be considered available.
     Defaults to 0 (pod will be considered available as soon as it is ready)

   replicas     
     Replicas is the number of desired replicas. This is a pointer to
     distinguish between explicit zero and unspecified. Defaults to 1. More
     info:
     <https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#what-is-a-replicationcontroller>

   selector     <map[string]string>
     Selector is a label query over pods that should match the Replicas count.
     If Selector is empty, it is defaulted to the labels present on the Pod
     template. Label keys and values that must match in order to be controlled
     by this replication controller, if empty defaulted to labels on Pod
     template. More info:
     <https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors>

   template     
     Template is the object that describes the pod that will be created if
     insufficient replicas are detected. This takes precedence over a
     TemplateRef. More info:
     <https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template>
</map[string]string>

rc.spec.replicas → 내가 설정하고 싶은 복제본 갯수

rc.spec.template → Pod 를 만들 템플릿을 정의

rc.spec.template.metadata → 여기서 반드시 Pod 의 label 을 지정해줘야 한다.

rc.spec.template.spec → Pod 의 spec 을 정의

rc.spec.selector → 수많은 Pod 중에 원하는 label 을 갖는 Pod 의 key, value 를 입력한다.

apiVersion: v1
kind: ReplicationController
metadata:
  name: myweb-rc
spec:
  replicas: 3
  # template 에서 생성된 Pod 의 label 을 확인하고 가져올 수 있다.  
  selector:
    app: web

  # Pod Configuration
  # 여기서 Pod 를 구성하고 label 을 붙인다.
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: myweb
          image: httpd
          ports:
            - containerPort: 80
              protocol: TCP

RC 스케일링

replace

명령형 커맨드

kubectl scale rc <RC_이름> --replicas=5

yml 파일에서 replicas 를 3개에서 2개로 변경 후에 변경사항을 적용시키고 싶다.

apiVersion: v1
kind: ReplicationController
metadata:
  name: myweb-rc
spec:
#  replicas: 3
  replicas: 2 
  selector: 
    app: web

  # Pod Configuration
  template:
    metadata:
      labels: 
        app: web
        env: dev
    spec:
      containers:
        - name: myweb
          image: httpd
          ports: 
            - containerPort: 80
              protocol: TCP

이때는 replace 명령어를 사용한다. replace 명령어를 사용하면 변경한 필드값을 업데이트 할 수 있다.

kubectl replace -f <파일명.yml>

물론 업데이트가 불가능한 필드도 있다. 업데이트가 가능하고 불가능한 필드를 확인하기 위해서 explain 명령어를 사용해서 확인 가능하다.

단, template 을 변경하고 새로 적용하고 싶다면 pod 를 일부러 지워야 한다.

왜냐하면 template 은 RC 를 새로 만들 때 적용되기 때문이다.

kubectl delete pods -l <labels_key=labels_value>

patch

kubectl patch -f <파일_이름.yml> -p '{"spec": {"replicas": 2}}'
kubectl patch rc <RC_이름> -p '{"spec": {"replicas": 2}}'
kubectl patch rc <RC_이름> --patch-file <파일_이름.json>

kubectl patch -f myweb-rc.yml -p '{"spec": {"replicas": 2}}'
kubectl patch rc myweb-rc -p '{"spec": {"replicas": 2}}'ㅣ
kubectl patch rc myweb-rc --patch-file replace.json

여기서 파일 이름을 적었다고 해서 파일을 수정하는 것이 아니라 어떤 리소스를 수정할 지 찾기 위해 사용하는 것이다. 변경할 수 없는 값은 변경할 수 없다.

replace 는 파일을 수정하고 replace 명령어를 사용하여 업데이트 한다. 즉, 파일의 spec 자체가 변경된 것이다. replace 는 완전한 구조(yml 파일 자체)를 제공해야 한다.

patch 는 JSON 형태로 일부만 제공하여 업데이트 할 수 있다. 즉, 필요한 부분만 골라서 업데이트할 수 있다는 것이다.

edit

kubectl edit -f <파일_이름.yml>
kubectl edit rc/<RC_이름>
kubectl edit rc <RC_이름>

파일 이름을 적었다고 해서 파일을 수정하는 것이 아니라 어떤 리소스를 수정할 지 찾기 위해 사용하는 것이다.

edit 를 사용하면 etcd 에 저장된 파일 자체를 수정할 수 있다. 변경할 수 없는 값은 변경할 수 없다.

apply

선언형 오브젝트 구성

kubectl apply -f <파일_이름.yml>
kubectl apply rc <RC_이름>

없으면 생성해주고 변경됐으면 변경사항을 적용해준다. 즉, create 로 RC 를 생성하지 않고 apply 로도 생성이 가능하다. 변경 사항이 생겼을 경우에도 apply 를 사용하면 자동으로 업데이트가 된다.

logs

kubectl logs rc/<RC_이름>

기본적으로 logs 명령어는 pods 로그를 디폴트로해서 로그를 찾기 때문에 pods 가 아닌 리소스의 로그를 찾을 때는 어떤 리소스 타입인지 표기해야 한다.

ReplicaSet

ReplicationController → ReplicaSet

ReplicaSet 은 파드의 metadata.ownerReferences 필드를 통해 파드에 연결ㅏ되며, 이는 현재 오브젝트가 소유한 리소스를 명시한다. 레플리카셋이 가지고 있는 모든 파드의 ownerReferences 필드는 해당 파드를 소유한 레플리카셋을 식별하기 위한 소유자 정보를 가진다. 이 링크를 통해 레플리카셋은 자신이 유지하는 파드의 상태를 확인하고 이에 따라 관리 한다.

레플리카셋은 셀렉터를 이용해서 필요한 새 파드를 식별한다. 만약 파드에 OwnerReference이 없거나 OwnerReference가 컨트롤러(Controller) 가 아니고 레플리카셋의 셀렉터와 일치한다면 레플리카셋이 즉각 파드를 가지게 될 것이다.

파드에 어떤 컨트롤러에 의해 관리되는지 정보가 추가 되어 파드의 labels 가 같더라도 컨트롤러에 따라 별개로 작동한다.

레플리카셋을 사용하는 시기

레플리카셋은 지정된 수의 파드 레플리카가 항상 실행되도록 보장한다. 그러나 디플로이먼트는 레플리카셋을 관리하고 다른 유용한 기능과 함께 파드에 대한 선언적 업데이트를 제공하는 상위 개념이다.

따라서 우리는 사용자 지정 오케스트레이션이 필요하거나 업데이트가 전혀 필요하지 않은 경우라면 레플리카셋을 직접적으로 사용하기 보다는 디플로이먼트를 사용하는 것을 권장한다.

이는 레플리카셋 오브젝트를 직접 조작할 필요가 없다는 것을 의미한다. 대신 디플로이먼트를 이용하고 사양 부분에서 애플리케이션을 정의하면 된다.

myweb-rs-set.yml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myweb-rs-set
spec:
  replicas: 2
  selector:
    matchExpressions:
      - key: app
        operator: In
        values: 
          - web
      - key: env
        operator: Exists
  template:
    metadata:
      labels:
        app: web
        env: dev
    spec:
      containers:
        - name: myweb
          image: nginx
          ports: 
            - containerPort: 8080
              protocol: TCP

frontend-rs.yml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # 케이스에 따라 레플리카를 수정한다.
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

메타데이터의 ownerReferences 필드에 설정되어 있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다.

kubectl get pods frontend-b2zdv -o yaml

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2022-05-12T07:06:16Z"
  generateName: frontend-
  labels:
    tier: frontend
  name: frontend-b2zdv
  namespace: default
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: frontend
    uid: f391f6db-bb9b-4c09-ae74-6a1f77f3d5cf
...

[kubernetes] POD Lifecycle

ssunw — Mon, 23 May 2022 12:53:18 +0900

Pod Lifecycle

공식 문서: https://kubernetes.io/ko/docs/concepts/workloads/pods/pod-lifecycle/

파드의 단계

파드의 status 필드는 phase 필드를 포함하는 PodStatus 오브젝트로 정의된다.

파드의 phase는 파드가 라이프사이클 중 어느 단계에 해당하는지 표현하는 간단한 고수준의 요약이다. Phase는 컨테이너나 파드의 관측 정보에 대한 포괄적인 롤업이나, 포괄적인 상태 머신을 표현하도록 의도되지는 않았다.

파드 phase 값에서 숫자와 의미는 엄격하게 지켜진다. 여기에 문서화된 내용 이외에는, 파드와 파드에 주어진 phase 값에 대해서 어떤 사항도 가정되어서는 안 된다.

phase에 가능한 값은 다음과 같다.

Pending: 스케줄링 되기 전, 이미지를 받기 전, 컨테이너가 준비되기 전

Running: 컨테이너가 실행 중, 실행 전, 재시작 중

Succeeded: 정상 종료(0)

Failed: 비정상 종료(!0)

Unknown: 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 이 단계는 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생한다.

Container 상태

Waiting: 이미지 받기 전, 볼륨 연결 되기 전
Running: 실행 중
Terminated: 종료

재시작 정책

pod.spec.restartPolicy
- Always(기본)
- OnFailure
- Never

지수 백오프

파드 실패 시 재시작 정책에 의해 재시작을 하게 됨
- 재시작 시간 10, 20, 40, 80…300 초 까지 유예 시간을 갖는다.

컨테이너 프로브(probe)

프로브 는 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단(diagnostic)이다. 진단을 수행하기 위해서, kubelet은 컨테이너 안에서 코드를 실행하거나, 또는 네트워크 요청을 전송한다.

프로브 종류

livenessProbe: 컨테이너가 동작 중인지 여부를 나타낸다. 만약 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는 재시작 정책의 대상이 된다. 만약 컨테이너가 활성 프로브를 제공하지 않는 경우, 기본 상태는 Success 이다.
- kubectl explain pods.spec.containers.livenessProbe
readinessProbe: 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다. 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의 초기 지연 이전의 기본 상태는 Failure 이다. 만약 컨테이너가 준비성 프로브를 지원하지 않는다면, 기본 상태는 Success 이다.
- kubectl explain pods.spec.containers.readinessProbe
startupProbe: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다. 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때까지 다른 나머지 프로브는 활성화되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고, 컨테이너는 재시작 정책에 따라 처리된다. 컨테이너에 스타트업 프로브가 없는 경우, 기본 상태는 Success 이다. startupProbe 의 상태가 Success 가 되어야만 livenessProbe 가 실행된다.
- kubectl explain pods.spec.containers.startupProbe

체크 메커니즘

프로브를 사용하여 컨테이너를 체크하는 방법에는 4가지가 있다. 각 프로브는 다음의 4가지 메커니즘 중 단 하나만을 정의해야 한다.

exec: 컨테이너 내에서 지정된 명령어를 실행한다. 명령어가 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다.

grpc: gRPC를 사용하여 원격 프로시저 호출을 수행한다. 체크 대상이 gRPC 헬스 체크를 구현해야 한다. 응답의 status 가 SERVING 이면 진단이 성공했다고 간주한다. gRPC 프로브는 알파 기능이며 GRPCContainerProbe 기능 게이트를 활성화해야 사용할 수 있다.

httpGet: 지정한 포트 및 경로에서 컨테이너의 IP주소에 대한 HTTP GET 요청을 수행한다. 응답의 상태 코드가 200 이상 400 미만이면 진단이 성공한 것으로 간주한다. 애플리케이션이 web app 일 경우 사용한다.

kubectl explain pods.spec.containers.livenessProbe.httpGet

tcpSocket: 지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다. 포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다. 원격 시스템(컨테이너)가 연결을 연 이후 즉시 닫는다면, 이 또한 진단이 성공한 것으로 간주한다.

kubectl explain pods.spec.containers.livenessProbe.tcpSocket

프로브 결과

각 probe는 다음 세 가지 결과 중 하나를 가진다.

Success: 컨테이너가 진단을 통과함.

Failure: 컨테이너가 진단에 실패함.

Unknown: 진단 자체가 실패함(아무런 조치를 수행해서는 안 되며, kubelet이 추가 체크를 수행할 것이다)

오류를 일으키키 위한 코드는 아래와 같다. livenessProbe 의 port 를 80 으로 수정하면 정상 작동한다.

myweb-liveness-err.yml

apiVersion: v1
kind: Pod
metadata:
  name: myweb-liveness-err
  labels:
    APP: apache
    ENV: dev
  annotations:
    Created-by: Choi
spec:
  containers:
    - name: myweb
      image: httpd
      livenessProbe:
        httpGet:
          path: "/"
#          port: 80
          port: 8080
      ports:
        - containerPort: 80
          name: myweb
          protocol: TCP

Liveness probe 가 실패한 것을 describe 에서 확인할 수 있다.

kubectl create -f myweb-liveness-err.yml

kubectl describe pods myweb-liveness-err
...
Events:
  Type     Reason     Age   From               Message
  ----     ------     ----  ----               -------
  Normal   Scheduled  13s   default-scheduler  Successfully assigned default/myweb-liveness-err to node-2
  Normal   Pulling    12s   kubelet            Pulling image "httpd"
  Normal   Pulled     10s   kubelet            Successfully pulled image "httpd" in 1.932221412s
  Normal   Created    10s   kubelet            Created container myweb
  Normal   Started    10s   kubelet            Started container myweb
  Warning  Unhealthy  3s    kubelet            Liveness probe failed: Get "<http://10.233.69.13:8080/>": dial tcp 10.233.69.13:8080: connect: connection refused

--watch 옵션으로 상태를 추적하면 계속해서 재시작되는 것을 확인할 수 있다.

kubectl get pods --watch
NAME                 READY   STATUS    RESTARTS   AGE
myweb-liveness       1/1     Running   0          2m42s
myweb-liveness-err   1/1     Running   0          24s
myweb-liveness-err   1/1     Running   1 (3s ago)   34s
myweb-liveness-err   1/1     Running   2 (3s ago)   64s

오류를 발생시키기 위한 startup 코드는 아래와 같다.

myweb-startup.yml

apiVersion: v1
kind: Pod
metadata:
  name: myweb-startup
  labels:
    APP: apache
    ENV: dev
  annotations:
    Created-by: Choi
spec:
  containers:
    - name: myweb
      image: httpd
      livenessProbe:
        httpGet:
          path: "/"
          port: 80
      startupProbe:
        exec:
          command:
            - "ls /tmp/abc"
# httpGet 으로 정상 작동시킬 수 있다.
#        httpGet:
#          path: "/"
#          port: 80
      ports:
        - containerPort: 80
          name: myweb
          protocol: TCP

Startup probe 가 실패한 것을 describe 에서 확인할 수 있다.

또한 Startup probe 의 특성상 성공할 때까지 다른 나머지 프로브는 활성화되지 않는다.

Events:
  Type     Reason     Age                    From               Message
  ----     ------     ----                   ----               -------
  Normal   Scheduled  7m9s                   default-scheduler  Successfully assigned default/myweb-startup to node-3
  Normal   Pulling    7m9s                   kubelet            Pulling image "httpd"
  Normal   Pulled     7m7s                   kubelet            Successfully pulled image "httpd" in 1.869534872s
  Normal   Created    7m7s                   kubelet            Created container myweb
  Normal   Started    7m7s                   kubelet            Started container myweb
  Warning  Unhealthy  6m59s                  kubelet            Startup probe errored: rpc error: code = Unknown desc = failed to exec in container: failed to start exec "d159db91a9f554ab155bd15e47b782ee35adee733973ef21baa90450ca04792e": OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "ls /tmp/abc": stat ls /tmp/abc: no such file or directory: unknown
  Warning  Unhealthy  6m49s                  kubelet            Startup probe errored: rpc error: code = Unknown desc = failed to exec in container: failed to start exec "b49bcf86f7748bcb6824f1868264dcd09031c62a82de86b6bef11117d6b80292": OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "ls /tmp/abc": stat ls /tmp/abc: no such file or directory: unknown

[kubernetes] NameSpace & Label & Annotation

ssunw — Mon, 23 May 2022 12:52:25 +0900

Namespace

리소스를 분리(격리)한다.

서비스 별
사용자 별
환경: 개발, 스테이징, 프로덕션

서비스: NDS 이름이 분리되는 용도

RBAC: 권한을 NS 에 설정

[~]$ kubectl get namespace
NAME              STATUS   AGE
default           Active   23h
kube-node-lease   Active   23h
kube-public       Active   23h
kube-system       Active   23h

kube-system: Kubernetes 의 핵심 컴포넌트
kube-public: 모든 사용자가 읽기 권한
kube-node-lease: Worker Node 에 장애가 발생했는지 확인
default: 기본 작업 공간

kubectl create ns developments
kubectl delete ns developments

kubectl get pods -A | --all-namespaces
kubectl get pods -n kube-system

ns-dev.yml

apiVersion: v1
kind: Namespace
metadata:
  name: dev

kubectl create -f ns-dev.yml

myweb-dev.yml

apiVersion: v1
kind: Pod
metadata:
  name: myweb
  namespace: dev
spec:
  containers:
    - name: myweb
      image: httpd
      ports:
      - containerPort: 80
        name: myweb
        protocol: TCP

레이블과 셀렉터

공식 문서: https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/labels/

레이블 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이다. 레이블은 오브젝트의 특성을 식별하는 데 사용되어 사용자에게 중요하지만, 코어 시스템에 직접적인 의미는 없다. 레이블로 오브젝트의 하위 집합을 선택하고, 구성하는데 사용할 수 있다. 레이블은 오브젝트를 생성할 때에 붙이거나 생성 이후에 붙이거나 언제든지 수정이 가능하다. 오브젝트마다 키와 값으로 레이블을 정의할 수 있다. 오브젝트의 키는 고유한 값이어야 한다.

"metadata": {
  **"labels"**: {
    **"key1"** : "value1",
    **"key2"** : "value2"
  }
}

레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 어노테이션으로 기록해야 한다.

권장 레이블

권장 레이블 공식 문서: https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/common-labels/

레이블은 주로 검색을 하거나 리소스를 연결할 때 사용한다.

레이블 명령어

레이블 확인

kubectl get pods --show-labels

kubectl get pods <파드_이름> -o yaml

kubectl describe pods <파드_이름>

레이블 관리

kubectl label pods <파드_이름> Key=Value # key 추가

kubectl label pods <파드_이름> Key=Value --overwrite # value 덮어쓰기

kubectl label pods <파드_이름> Key-   # key 삭제

YAML 파일에서 label

apiVersion: v1
kind: Pod
metadata:
  name: myweb
  namespace: dev
  labels:
    APP: apache
    ENV: dev
spec:
  containers:
    - name: myweb
      image: httpd
      ports:
      - containerPort: 80
        name: myweb
        protocol: TCP

사용 동기

레이블을 이용하면 사용자가 느슨하게 결합한 방식으로 조직 구조와 시스템 오브젝트를 매핑할 수 있으며, 클라이언트에 매핑 정보를 저장할 필요가 없다.

서비스 배포와 배치 프로세싱 파이프라인은 흔히 다차원의 엔티티들이다(예: 다중 파티션 또는 배포, 다중 릴리스 트랙, 다중 계층, 계층 속 여러 마이크로 서비스들). 관리에는 크로스-커팅 작업이 필요한 경우가 많은데 이 작업은 사용자보다는 인프라에 의해 결정된 엄격한 계층 표현인 캡슐화를 깨트린다.

레이블 예시:

"release" : "stable", "release" : "canary"
"environment" : "dev", "environment" : "qa", "environment" : "production"
"tier" : "frontend", "tier" : "backend", "tier" : "cache"
"partition" : "customerA", "partition" : "customerB"
"track" : "daily", "track" : "weekly"

이 예시는 일반적으로 사용하는 레이블이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.

구문과 캐릭터 셋

레이블 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시(/)로 구분되는 선택한 접두사와 이름이라는 2개의 세그먼트가 있다. 이름 세그먼트는 63자 미만으로 시작과 끝은 알파벳과 숫자([a-z0-9A-Z])이며, 대시(-), 밑줄(_), 점(.)과 함께 사용할 수 있다. 접두사는 선택이다. 만약 접두사를 지정한 경우 접두사는 DNS의 하위 도메인으로 해야 하며, 점(.)과 전체 253자 이하, 슬래시(/)로 구분되는 DNS 레이블이다.

접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: kube-scheduler, kube-controller-manager, kube-apiserver, kubectl 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.

kubernetes.io/와 k8s.io/ 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어 있다.

kubectl get nodes --show-labels
NAME     STATUS   ROLES                  AGE   VERSION   LABELS
node-1   Ready    control-plane,master   24h   v1.22.8   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-1,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=,node.kubernetes.io/exclude-from-external-load-balancers=
node-2   Ready    <none>                 24h   v1.22.8   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-2,kubernetes.io/os=linux
node-3   Ready    <none>                 24h   v1.22.8   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-3,kubernetes.io/os=linux

LabelSelector

검색을 담당
리소스 간의 연결을 담당

일치성(equality base)

kubectl get pods -l APP=nginx

kubectl get pods -l APP==nginx

kubectl get pods -l 'APP!=nginx'

집합성(set base)

in
notin
exists: 키만 매칭
doesnotexists: 키 제외 매칭

kubectl get pods -l 'ENV in (dev, staging)'

kubectl get pods -l 'ENV notin (dev)'

kubectl get pods -l 'ENV'

kubectl get pods -l '!ENV'

Annotations

쿠버네티스 어노테이션을 사용하여 임의의 비-식별 메타데이터를 오브젝트에 첨부할 수 있다. 도구 및 라이브러리와 같은 클라이언트는 이 메타데이터를 검색할 수 있다.

즉, 레이블과 다르게 검색과 리소스 간 연결을 하는 특별한 기능이 없다.

오브젝트에 메타데이터 첨부

레이블이나 어노테이션을 사용하여 쿠버네티스 오브젝트에 메타데이터를 첨부할 수 있다. 레이블을 사용하여 오브젝트를 선택하고, 특정 조건을 만족하는 오브젝트 컬렉션을 찾을 수 있다. 반면에, 어노테이션은 오브젝트를 식별하고 선택하는데 사용되지 않는다. 어노테이션의 메타데이터는 작거나 크고, 구조적이거나 구조적이지 않을 수 있으며, 레이블에서 허용되지 않는 문자를 포함할 수 있다.

어노테이션은 레이블과 같이 키/값 맵이다.

"metadata": {
  "annotations": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

다음은 어노테이션에 기록할 수 있는 정보의 예제이다.

필드는 선언적 구성 계층에 의해 관리된다. 이러한 필드를 어노테이션으로 첨부하는 것은 클라이언트 또는 서버가 설정한 기본 값, 자동 생성된 필드, 그리고 오토사이징 또는 오토스케일링 시스템에 의해 설정된 필드와 구분된다.
빌드, 릴리스, 또는 타임 스탬프, 릴리스 ID, git 브랜치, PR 번호, 이미지 해시 및 레지스트리 주소와 같은 이미지 정보.
로깅, 모니터링, 분석 또는 감사 리포지터리에 대한 포인터.
디버깅 목적으로 사용될 수 있는 클라이언트 라이브러리 또는 도구 정보: 예를 들면, 이름, 버전, 그리고 빌드 정보.
다른 생태계 구성 요소의 관련 오브젝트 URL과 같은 사용자 또는 도구/시스템 출처 정보.
경량 롤아웃 도구 메타데이터. 예: 구성 또는 체크포인트
책임자의 전화번호 또는 호출기 번호, 또는 팀 웹 사이트 같은 해당 정보를 찾을 수 있는 디렉터리 진입점.
행동을 수정하거나 비표준 기능을 수행하기 위한 최종 사용자의 지시 사항.

어노테이션을 사용하는 대신, 이 유형의 정보를 외부 데이터베이스 또는 디렉터리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한 공유 클라이언트 라이브러리와 도구 생성을 훨씬 더 어렵게 만들 수 있다.

명령형 커맨드

kubectl annotate pods <파드_이름> Key=Value  # 어노테이션 추가
 
kubectl annotate pods <파드_이름> Key=Value --overwrite # 어노테이션 덮어 쓰기

kubectl annotate pods <파드_이름> Key-  # 어노테이션 삭제

YAML

apiVersion: v1
kind: Pod
metadata:
  name: myweb
  labels:
    APP: apache
    ENV: dev
  annotations:
    Created-by: Choi
spec:
  containers:
    - name: myweb
      image: httpd
      ports:
      - containerPort: 80
        name: myweb
        protocol: TCP

[kubernetes] POD

ssunw — Mon, 23 May 2022 12:51:18 +0900

Pod

공식 문서: https://kubernetes.io/ko/docs/concepts/workloads/pods/

파드는 컨테이너의 모음이다. 하나의 파드에 한 개 이상의 컨테이너가 있을 수 있다.
쿠버네티스는 컨테이너를 직접 관리하지 않는다. 쿠버네티스에서 관리하는 가장 작은 워크로드는 파드이다.

kubelet 이 서비스인 이유

kubelet 은 api-server, cm, 스케줄러 등 쿠버네티스의 필수 불가결한 리소스들을 실행시켜주는 역할을 하기 때문에 파드가 아닌 서비스로서 동작한다. 만약 kubelet 까지 파드로 구성되어 있다면 kubernetes 를 띄울 녀석이 존재하지가 않기 때문에 서비스로 동작을 한다.

정적 파드

정적 파드 는 API 서버가 관찰하는 대신 특정 노드의 kubelet 데몬에 의해 직접 관리된다.

대부분의 파드는 컨트롤 플레인(예를 들어, 디플로이먼트)에 의해 관리되고, 정적 파드의 경우, kubelet이 각 정적 파드를 직접 감독한다(실패하면 다시 시작한다).

정적 파드는 항상 특정 노드의 Kubelet 하나에 바인딩된다. 정적 파드의 주요 용도는 자체 호스팅 컨트롤 플레인을 실행하는 것이다. 즉, kubelet을 사용하여 개별 컨트롤 플레인 컴포넌트를 감독한다.

kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버에서 미러 파드를 생성하려고 한다. 즉, 노드에서 실행되는 파드는 API 서버에서 보이지만, 여기에서 제어할 수는 없다는 의미이다.

/etc/kubernetes/manifest 에서 yml 파일로 pod 를 작성한 후 실행하면 정적 파드가 생성된다.

kubectl 명령의 서브 명령

kubectl 에서 자주 사용하는 서브 명령어

create
get
describe
logs
delete
replace
patch
apply
diff

명령형 커맨드로 파드 생성

kubectl run myweb --image httpd

kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
myweb   1/1     Running   0          26s

kubectl get pods -o wide
NAME    READY   STATUS    RESTARTS   AGE     IP             NODE     NOMINATED NODE   READINESS GATES
myweb   1/1     Running   0          2m21s   10.233.109.1   node-3   <none>           <none>

파드 상세 정보

kubectl get pods -o yaml 를 사용해서 yaml 형태로 etcd 에서 원본 데이터를 가져온다.

-o wide, -o json 등으로 원하는 포맷팅으로 가져올 수 있다.

kubectl get pods -o yaml
apiVersion: v1
items:
- apiVersion: v1
  kind: Pod
  metadata:
    annotations:
      cni.projectcalico.org/containerID: ba98ccabd6b2b011e9654d76181414a90e7eec9729e207ceb6391d513bccfab2
      cni.projectcalico.org/podIP: 10.233.109.1/32
      cni.projectcalico.org/podIPs: 10.233.109.1/32
    creationTimestamp: "2022-05-17T01:38:18Z"
    labels:
      run: myweb
    name: myweb
    namespace: default
    resourceVersion: "18433"
    uid: 4741205a-6581-4ab6-bae5-dc0f6ac35dbc
  spec:
    containers:
    - image: httpd
      imagePullPolicy: Always
      name: myweb
      resources: {}
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      volumeMounts:
      - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
        name: kube-api-access-ff6tf
        readOnly: true
    dnsPolicy: ClusterFirst
    enableServiceLinks: true
    nodeName: node-3
    preemptionPolicy: PreemptLowerPriority
    priority: 0
    restartPolicy: Always
    schedulerName: default-scheduler
    securityContext: {}
    serviceAccount: default
    serviceAccountName: default
    terminationGracePeriodSeconds: 30
    tolerations:
    - effect: NoExecute
      key: node.kubernetes.io/not-ready
      operator: Exists
      tolerationSeconds: 300
    - effect: NoExecute
      key: node.kubernetes.io/unreachable
      operator: Exists
      tolerationSeconds: 300
    volumes:
    - name: kube-api-access-ff6tf
      projected:
        defaultMode: 420
        sources:
        - serviceAccountToken:
            expirationSeconds: 3607
            path: token
        - configMap:
            items:
            - key: ca.crt
              path: ca.crt
            name: kube-root-ca.crt
        - downwardAPI:
            items:
            - fieldRef:
                apiVersion: v1
                fieldPath: metadata.namespace
              path: namespace
  status:
    conditions:
    - lastProbeTime: null
      lastTransitionTime: "2022-05-17T01:38:19Z"
      status: "True"
      type: Initialized
    - lastProbeTime: null
      lastTransitionTime: "2022-05-17T01:38:38Z"
      status: "True"
      type: Ready
    - lastProbeTime: null
      lastTransitionTime: "2022-05-17T01:38:38Z"
      status: "True"
      type: ContainersReady
    - lastProbeTime: null
      lastTransitionTime: "2022-05-17T01:38:19Z"
      status: "True"
      type: PodScheduled
    containerStatuses:
    - containerID: containerd://8129401885bc9f1e85e5051c514be51183a784134ad58c2581461e1a2d46e6f7
      image: docker.io/library/httpd:latest
      imageID: docker.io/library/httpd@sha256:2d1f8839d6127e400ac5f65481d8a0f17ac46a3b91de40b01e649c9a0324dea0
      lastState: {}
      name: myweb
      ready: true
      restartCount: 0
      started: true
      state:
        running:
          startedAt: "2022-05-17T01:38:38Z"
    hostIP: 192.168.100.105
    phase: Running
    podIP: 10.233.109.1
    podIPs:
    - ip: 10.233.109.1
    qosClass: BestEffort
    startTime: "2022-05-17T01:38:19Z"
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

describe

kubectl describe pods myweb
Name:         myweb
Namespace:    default
Priority:     0
Node:         node-3/192.168.100.105
Start Time:   Tue, 17 May 2022 01:38:19 +0000
Labels:       run=myweb
Annotations:  cni.projectcalico.org/containerID: ba98ccabd6b2b011e9654d76181414a90e7eec9729e207ceb6391d513bccfab2
              cni.projectcalico.org/podIP: 10.233.109.1/32
              cni.projectcalico.org/podIPs: 10.233.109.1/32
Status:       Running
IP:           10.233.109.1
IPs:
  IP:  10.233.109.1
Containers:
  myweb:
    Container ID:   containerd://8129401885bc9f1e85e5051c514be51183a784134ad58c2581461e1a2d46e6f7
    Image:          httpd
    Image ID:       docker.io/library/httpd@sha256:2d1f8839d6127e400ac5f65481d8a0f17ac46a3b91de40b01e649c9a0324dea0
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Tue, 17 May 2022 01:38:38 +0000
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-ff6tf (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  kube-api-access-ff6tf:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  6m22s  default-scheduler  Successfully assigned default/myweb to node-3
  Normal  Pulling    6m21s  kubelet            Pulling image "httpd"
  Normal  Pulled     6m9s   kubelet            Successfully pulled image "httpd" in 12.366300856s
  Normal  Created    6m4s   kubelet            Created container myweb
  Normal  Started    6m3s   kubelet            Started container myweb

event 는 myweb pod 의 라이프 사이클이다.

맨 처음 디폴트 스케줄러에 의해 이벤트가 발생한다. 노드-3 에 파드를 배치했다.

kubelet 이 httpd 이미지를 풀링한다. httpd 폴링이 완료되고 kubelet 이 myweb 컨테이너를 생성하고 실행한다.

파드를 생성했을 때 컨테이너가 제대로 작동하지 않을 경우 kubectl describe pods 로 파드 자체의 로그를 확인하고 그 후에 애플리케이션의 로그를 확인한다.

애플리케이션의 로그를 확인하기 위해서는 kubectl logs <파드_이름> 명령어로 확인 가능하다.

파드 삭제

kubectl delete pods <파드_이름>

YAML 파일로 파드 정의

kubectl explain pods

myweb.yml

apiVersion: v1
kind: Pod
metadata:
  name: myweb
spec:
  containers:
    - name: myweb
      image: httpd
      ports:
      - containerPort: 80
        name: myweb
        protocol: TCP

Workload resources for managing pods

일반적으로 싱글톤(singleton) 파드를 포함하여 파드를 직접 만들 필요가 없다. 대신, 디플로이먼트(Deployment) 또는 잡(Job)과 같은 워크로드 리소스를 사용하여 생성한다. 파드가 상태를 추적해야 한다면, 스테이트풀셋(StatefulSet) 리소스를 고려한다.

쿠버네티스 클러스터의 파드는 두 가지 주요 방식으로 사용된다.

단일 컨테이너를 실행하는 파드. "파드 당 하나의 컨테이너" 모델은 가장 일반적인 쿠버네티스 유스케이스이다. 이 경우, 파드를 단일 컨테이너를 둘러싼 래퍼(wrapper)로 생각할 수 있다. 쿠버네티스는 컨테이너를 직접 관리하는 대신 파드를 관리한다.
함께 작동해야 하는 여러 컨테이너를 실행하는 파드. 파드는 밀접하게 결합되어 있고 리소스를 공유해야 하는 함께 배치된 여러 개의 컨테이너로 구성된 애플리케이션을 캡슐화할 수 있다. 이런 함께 배치된 컨테이너는 하나의 결합된 서비스 단위를 형성한다. 예를 들어, 하나의 컨테이너는 공유 볼륨에 저장된 데이터를 퍼블릭에 제공하는 반면, 별도의 사이드카 컨테이너는 해당 파일을 새로 고치거나 업데이트한다. 파드는 이러한 컨테이너, 스토리지 리소스, 임시 네트워크 ID를 단일 단위로 함께 래핑한다.

하나의 파드에는 반드시 하나의 메인 어플리케이션만 있어야 한다. 파드에 여러 컨테이너가 있을 경우에는 메인 어플리케이션 + 메인 어플리케이션을 서포팅하는 다른 컨테이너여야 한다.

하나의 파드에 메인 애플리케이션이 여러개 띄워지면 안된다. -> 안티 패턴이다.

예를 들어 하나의 파드안에 메인이 되는 웹서버가 있고 해당 웹서버로 코드를 가져오거나 정적인 파일을 가져오는 메인 앱을 서포팅하는 앱과 웹서버에서 보내준 로그를 로그 서버로 보내는 메인 앱을 서포팅하는 앱으로 파드가 구성될 수 있다.

하나의 파드는 하나의 호스트(노드)에 배치된다. 즉, 파드 안여 여러 대의 컨테이너가 있어도 하나의 호스트(노드)에 모두 배치된다.

파드 디자인

사이드카 패턴: https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/

단일 컨테이너: 가장 일반적인 형태, 대부분의 파드는 단일 컨테이너로 이루어져 있다.
멀티 컨테이너: 메인 애플리케이션이 존재하고 메인 애플리케이션 기능을 확장하기 위한 컨테이너를 배치
- sidecar: 기능의 확장
- ambassador: proxy/LB
- adaptor: 출력의 표준

파드는 응집력있는 서비스 단위를 형성하는 여러 협력 프로세스(컨테이너)를 지원하도록 설계되었다. 파드의 컨테이너는 클러스터의 동일한 물리 또는 가상 머신에서 자동으로 같은 위치에 배치되고 함께 스케줄된다. 컨테이너는 리소스와 의존성을 공유하고, 서로 통신하고, 종료 시기와 방법을 조정할 수 있다.

예를 들어, 다음 다이어그램에서와 같이 공유 볼륨의 파일에 대한 웹 서버 역할을 하는 컨테이너와, 원격 소스에서 해당 파일을 업데이트하는 별도의 "사이드카" 컨테이너가 있을 수 있다.

일부 파드에는 앱 컨테이너 뿐만 아니라 초기화 컨테이너를 갖고 있다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다.

파드는 기본적으로 파드에 속한 컨테이너에 네트워킹과 스토리지라는 두 가지 종류의 공유 리소스를 제공한다.

파드는 딱 하나의 IP 주소를 부여 받는다. 즉, 파드 안에 몇 개의 컨테이너가 있든 간에 모두 같은 IP 주소를 사용한다. → 공유 네트워크

파드에 볼륨을 설정해주면 해당하는 볼륨을 파드 안의 모든 컨테이너가 접근할 수 있고 사용할 수 있다. → 공유 스토리지

포트 및 포트 포워딩

테스트 & 디버깅 목적이다.

kubectl port-forward pods/<파드_이름> 8080:80

[kubernetes] Kubernetes Objects

ssunw — Mon, 23 May 2022 12:48:11 +0900

Kubernetes Objects

kubectl api-resources

Label / LabelSelector: 오브젝트와 오브젝트를 연결할 때 사용하는 개념으로 오브젝트와 오브젝트의 관계를 설명할 때 사용한다. AWS 태그같은 개념으로 생각하면 된다.
Workload
- Pod: 제일 핵심, Pod 는 컨테이너라고 볼 수 있다.
- Controller: 파드를 제어하는 컨트롤러
  - ReplicationController: ReplicaSets 가 나온 이후로 사용하지 않는다.
  - ReplicaSets
  - DaemonSets
  - Jobs: 배치 작업
  - CronJobs: 배치 작업
  - Deployments: 배포, stateless 를 관리, 쿠버네티스의 핵심!
  - StatefulSets: stateless 와 상반
  - HorizontalPodAutoscaler(HPA): 파드의 오토 스케일링을 담당
Network
- service: L4 LB
- Endpoints: 로드 밸런서의 백엔드
- Ingress: L7 LB, Add-on 으로 설치해야 한다.
Storage
- PersistentVolume(PV)
- PersistentVolumeClaim(PVC): PV 를 요청
- ConfigMap: 파드에 데이터를 제공하기 위한 Key Value 스토리지
- Secret: 파드에 데이터를 제공하기 위한 Key Value 스토리지
Authentication: ~/.kube/config 파일과 관련된 내용들이다.
- ServiceAccount(SA): 계정에 관련된 개념
- RBAC: 역할 기반의 접근 제어
  - Role
  - ClusterRole
  - RoleBinding: (Binding)계정과 역할을 연결할 때 사용
  - ClusterRoleBinding: (Binding)계정과 역할을 연결할 때 사용
Resource Isolation
- Namespaces: 리소스를 분리하기 위해 사용한다.
Resource Limits: 파드 리소스를 제한
- Limits
- Requests
- ResourceQuota
- LimitRange
Schedulling
- NodeName
- NodeSelector
- Affinity(선호도)
  - Node Affinity
  - Pod Affinity
  - Pod Anti Affinity
- Taints/Tolerations
- Drani/Cordon: Drain → 배출, Cordon → 스케줄링을 하지 않게 막아버린다. Drain 을 할 경우 자동으로 Cordon 이 작동된다.

쿠버네티스 오브젝트 이해하기

아래 명령어로 쿠버네티스 오브젝트를 확인할 수 있다.

kubectl api-resources

공식 문서: https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/

쿠버네티스 api 공식 문서: https://kubernetes.io/ko/docs/reference/

쿠버네티스 오브젝트 는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 오브젝트를 이용한다. 구체적으로 말하자면, 다음같이 기술할 수 있다.

어떤 컨테이너화된 애플리케이션이 동작 중인지 (그리고 어느 노드에서 동작 중인지)
그 애플리케이션이 이용할 수 있는 리소스
그 애플리케이션이 어떻게 재구동 정책, 업그레이드, 그리고 내고장성과 같은 것에 동작해야 하는지에 대한 정책

쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드"이다.

오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다.

오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 의도한 상태가 된다.

생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, 쿠버네티스 API를 이용해야 한다.

예를 들어, kubectl 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 클라이언트 라이브러리 중 하나를 이용하여 내 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.

오브젝트를 YAML 혹은 명령어로 생성할 것인지 정해야 한다.

오브젝트 명세(spec)와 상태(status)

거의 모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는 두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 spec 과 오브젝트 status 이다.

spec을 가진 오브젝트는 오브젝트를 생성할 때 리소스에 원하는 특징(의도한 상태)에 대한 설명을 제공해서 설정한다.

status 는 쿠버네티스 시스템과 컴포넌트에 의해 제공되고 업데이트된 오브젝트의 현재 상태 를 설명한다.

쿠버네티스 컨트롤 플레인은 모든 오브젝트의 실제 상태를 사용자가 의도한 상태와 일치시키기 위해 끊임없이 그리고 능동적으로 관리한다.

사용자는 보통 spec 을 작성한다. 오브젝트의 종류에 따라 spec 이 없는 경우도 있지만 극히 드물다.

아래 예제를 확인해보자.

apiVersion, kind, metadata, spec 은 모든 리소스에 항상 적용된다.

오브젝트에 따라서 지원하는 apiVersion 이 모두 다르다. 즉, apiVersion 은 오브젝트의 종류에 따라 달라진다.

kind 는 오브젝트의 종류를 나타낸다.

kubectl api-resources 명령어를 입력했을 때 맨 오른쪽에 있는 KIND 란에 있는 녀석과 똑같다.

metadata 는 오브젝트를 설명하기 위한 데이터이다.

리소스의 이름(name), 리소스의 라벨(label), 주석(annotation) 키워드 등을 사용한다.

spec 은 kind 에 따라서 달라지게 된다. 즉, 어떤 종류의 오브젝트를 정의하냐에 따라 달라진다는 것이다.

apiVersion - 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지
kind - 어떤 종류의 오브젝트를 생성하고자 하는지
metadata - 이름 문자열, UID, 그리고 선택적인 네임스페이스를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
spec - 오브젝트에 대해 어떤 상태를 의도하는지, 선언형

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

kubectl explain <오브젝트_이름>
# 해당 필드에서 사용할 수 있는 모든 필드들을 확인할 수 있다.
kubectl explain <오브젝트_이름>.<필드명> --recursive 
kubectl explain <오브젝트_이름>.<필드명>.<필드명>.....

kubectl explain pods
kubectl explain pods.spec
kubectl explain pods.spec.containers
kubectl explain pods.spec.containers.ports

오브젝트의 버전

공식 문서: https://kubernetes.io/ko/docs/reference/using-api/#api-그룹

현재 쿠버네티스 버전에서 지원되는 api 버전들을 아래 명령어로 확인할 수 있다.

	kubectl api-versions

Stable
- vX
- v1, v2
- 안정화 된 버전
Beta
- v1betaX, v2betaX
- 충분히 검증, 오류가 거의 없다.
- 버전이 올라가면 기능 변경이 있을 수 있다.
  - downtime 발생할 수도 있다. 즉, 특정 기능을 사용하기 위해 재시작
- Mission Critical
Alpha
- v1alphaX, v2alphaX
- 기본적으로 비활성화
- 개발 중인 API

Dev → Alpha → Beta → Stable

오브젝트 관리 방법

공식 문서: https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/object-management/

명령형 커맨드: kubectl 명령어로만 구성
- kubectl create
- kubctl run
- kubctl expose
명령형 오브젝트 구성: YAML 파일 작성, 명령형==절차형. 오브젝트를 구성해 놓은 YAML 파일 여러개가 있을 때 이 파일을 순서대로 하나씩 실행한다.
- kubectl create -f a.yml
- kubectl apply -f a.yml
- kubectl replace -f a.yml
선언형 오브젝트 구성: YAML 파일 작성, YAML 파일이 있는 디렉토리를 한 번에 실행한다.
- kubectl create -f resources
- kubectl apply -f resoureces

일반적으로 명령형, 선언형 오브젝트 구성을 사용한다.

docker compose

ssunw — Mon, 16 May 2022 20:06:37 +0900

Docker Compose

공식 문서 : https://docs.docker.com/compose/compose-file/compose-file-v3/

쿠버네티스를 사용하게 될 경우 도커 컴포즈를 사용할 일은 거의 없다.

도커 컴포즈는 도커 IaC 라고 보면 된다.

도커 컴포즈의 버전은 도커 엔진에 따라 다르므로 공식 문서를 확인하고 필요한 도커 컴포즈 버전을 사용하면 된다.

docker compose <커맨드> 로 실행한다.

docker-compose.yml 또는 docker-compose.yaml 에 코드를 작성해야 한다.

예제 1

version: '3'

services:
  web:
    image: httpd

version: ‘3’ 은 3의 가장 최신 버전을 사용, service 는 컨테이너이다.

docker compose run 과 up 은 다르다. up 은 도커 컴포즈를 생성할 때 사용하고 run 은 이미 띄워진 녀석을 다시 실행할 때 사용한다.

실행

docker compose up -d

프로젝트 목록 확인

docker compose ls

서비스 목록(컨테이너 목록)

docker compose ps

종료

docker compose down

예제 2

version: '3'

services:
  web:
    image: httpd
    restart: always
    ports:
      - 80:80
    environment:
      MSG: hello world
    volumes:
      - web-contents:/var/www/html
    networks:
      - web-net
  web2:
    image: nginx
    networks:
      - web-net

volumes:
  web-contents:

networks:
  web-net:

서비스 내부에 작성되는 networks 는 네트워크를 만드는 것이 아니라 이 컨테이너의 네트워크를 어디에 연결할 것인지 작성하는 곳이고 가장 바깥에 있는 networks 가 docker compose 가 사용할 네트워크의 이름을 지정하는 곳이다.

$ docker compose up
$ docker compose exec web bash
# apt update; apt install curl
# curl web2

위 방식처럼 web 컨테이너에 접속을 한 후 curl 로 web2 에 바로 접근이 가능하다. 즉, link 를 해줄 필요가 없다.

도커 컴포즈에서는 컨테이너들끼리는 아이피를 알 필요 없이 이름으로 통신이 서로 가능하다.

예제 3

version: '3'

services:  
  myflask:    
    build: ./hello-flask  
  mydjango:    
    build: ./hello-django

hello-flask 와 hello-django 디렉토리에 도커 파일이 있고 build 에 의해 자동으로 도커 파일을 빌드하여 컨테이너를 띄운다.

/Users/csw/tmp/docker/jenkins_home/workspace

주로 예제 2의 방법을 많이 사용하고 현업에서는 도커 컴포즈 방식을 사용하지 않는다.

도커 컴포즈로 워드프레스 띄우기

도커 컴포즈로 컨테이너를 띄울 경우 어떤 녀석이 먼저 생성될지 모르기 때문에 depends_on 키워드를 사용해서 db 컨테이너가 생성된 후에 워드프레스 컨테이너가 생성되도록 했다.

나머지 환경 변수들은 도커 공식 이미지에 나와있는 환경 변수들이다.

version: '3'

services:
   db:
     image: mysql:5.7
     volumes:
       - ./mysql:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: 1234
       MYSQL_DATABASE: wordpress
       MYSQL_USER: admin
       MYSQL_PASSWORD: 1234
   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     ports:
       - "8000:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: admin
       WORDPRESS_DB_PASSWORD: 1234
       WORDPRESS_DB_NAME: wordpress
     volumes:
       - ./html:/var/www/html

ssunw

001. Loki Logging Stack 구성 요소

Loki 개요 (Loki Overview)

Loki Logging Stack 구성 요소

Loki 주요 특징

LinkedIn

쿠버네티스에서 동시성 제어와 리소스의 일관성을 보장하는 방법

resourceVersion 개념

동작

동시에 리소스를 변경하는 케이스

활용

golang http 패키지

http.Servemux & http.HandleFunc

http.HandlerFunc

http.ListenAndServe 와 Interface

Redis Eviction

jvm heap memory

jvm heap memory

자바 힙메모리 사이즈란?

SGP(Security Group for Pod)

SGP

elasticache network exceeded

redis

HikariPoolConnection Error

HikariPoolConnection Error

Elasticache NetworkBytes In/Out

Elasticache Redis

ec2 인스턴스 기반에서 동작하는 java application 502 발생

pods/exec 서브리소스 권한

AWS IAM

Policy

Identity 기반 정책

Resource 기반 정책

Role

SLA/SLO/SLI

SLA/SLO/SLI

KPI(Key Performance Indicator)

Service Level

SLI(Service Level Indicators)

적절한 SLI 설정

What to Measure: Using SLIs

SLI 구현

API and HTTP server availability and latency

Pipeline freshness, coverage, and correctness

척도의 표준화

SLO(Service Level Objectives)

SLA(Service Level Agreements)

SLA/SLO/SLI 란?

SLA/SLO/SLI

KPI(Key Performance Indicator)

Service Level

SLI(Service Level Indicators)

SLO(Service Level Objectives)

SLA(Service Level Agreements)

[Spring Boot] 아파치 카프카

카프카 사용을 위한 스프링 설정

KafkaTemplate 을 사용해서 메시지 전송하기

카프카 리스너 작성

[Spring Boot] Spring Cloud Eureka Server

유레카란?

유레카 구성하기

자체-보존 모드

프로덕션 환경의 스프링 클라우드 서비스

[SpringBoot] Transactional

JDBC 트랜잭션

@Transactional

트랜잭션 경계 설정 전략

트랜잭션 전파

REQUIRED(기본값)

REQUIRES_NEW

MANDATORY

NESTED

NEVER

NOT_SUPPORTED

@Transactionl 주의점

[kubernetes] kubernetes 아키텍쳐

쿠버네티스 클러스터의 핵심

Node(구 명칭 worker, Minions)

Control Plane(구 명칭 Master)

Control Plane 컴포넌트