Kubernetes 28

K8s Cluster Tier 분류

이 페이지는 Production Kubernetes에서 발췌한 내용을 번역, 요약한 내용입니다. Cluster Tier Kubernetes Cluster는 그 목적과 SLO/SLA 수준에 따라 보통 아래와 같이 4개의 Tier로 구분할 수 있다. 시스템을 낮은 티어에서부터 많이 사용해볼 수록 Production 환경에서 문제를 일으킬 가능성이 낮아진다. Testing 일시적(ephemeral); 1주 이내의 TTL을 가지며 자동 제거됨 Single-tenant; 단일 개발팀 로컬 환경의 클러스터(ex: minikube)에서 테스트하기 힘들 때 Application의 최초 컨테이너화 및 테스트 수행시 SLO, SLA 존재하지 않음 최신 또는 pre-alpha 버전의 Kubernetes 사용 Developm..

Kubernetes 2022.07.22

Kubernetes v1.24 릴리즈

2022년 5월 4일, Kubernetes v1.24가 정식 릴리즈되었다. EKS, AKS와 같은 Managed K8s 서비스는 v1.22나 v1.23이 대부분이기 때문에 당장은 영향이 없겠지만, 어떤 점이 바뀌었는지를 파악하고 준비할 필요가 있다. k8s v1.24 변경점 마이너 버전업이지만 생각보다 많은 기능의 추가, 변경 및 삭제가 이루어졌는데 그 중에서 눈여겨볼 만한 변화는 다음과 같다. Dockershim 삭제 아마 이번 업데이트의 가장 큰 변화가 아닐까 생각된다. 기존 Docker의 CRI(Container Runtime Interface) 호환을 위해 존재했던 dockershim이 마침내 kubelet에서 제거되었다. 이미 작년부터 dockershim이 deprecation될 예정이라고 선언..

Kubernetes 2022.05.06

Kubernetes: The Documentary

Youtube에서 Kubernetes 관련 흥미로운 영상을 발견하여, 스크랩 및 정보 공유차 블로그에 올린다. 2022년 1월에 'Kubernetes: The Documentary'라는 제목으로 공개된 다큐멘터리로, K8s를 개발한 사람들이 직접 인터뷰를 하면서 어떻게 만들었는지부터 그 과정에서 있었던 비하인드 스토리를 이야기해 주는 형식이다. Part 1, 2 합쳐서 전체 50분 정도 되는 영상인데 지루할틈 없이 한번에 모두 봤을만큼 재밌는 내용이 많았다. 특히 Kubernetes라는 이름을 어떻게 지었는지 알려주는데, 약간은 허무하면서도 인상깊었다고 해야할까 ㅎㅎ 참고로 DockerCon 2014에서 K8s를 공개한 시점 이전과 이후를 기준으로 Part 1과 Part 2가 나뉘어져 있다. Part 1..

Kubernetes 2022.02.04

PodDisruptionBudget을 활용한 Application 보호

K8s의 고가용성 보장 K8s엔 서비스의 고가용성(HA; High Availability)을 보장하기 위해 다양한 Workload(ex: Deployment, Statefulset, Daemonset 등)이 존재한다. Replica 중 Pod 하나가 죽더라도, 다른 Pod이 살아있다면 계속해서 서비스를 제공할 수 있다. 또한 부족해진 replica 갯수는 K8s Controller를 통해 자동으로 다시 채워지며 이를 Reconciliation이라 한다. 하지만 특정 Usecase의 경우, 무결성 등의 이유로 반드시 정해진 갯수 이상의 Pod이 반드시 Running 상태로 존재해야 할 필요가 있다. 예를 들어 etcd, zookeeper와 같이 여러개 Instance가 클러스터를 구성하여 Stateful ..

Kubernetes 2021.09.22

Kubernetes Custom Resource와 Controller

시작하며... Kubernetes는 기본로 제공하는 Built-in Object(ex: Deployment, Service) 외에 따로 정의한 Custom Resource를 통해 클러스터의 기능을 확장시킬 수 있다. 예를 들어 Istio의 VirtualService나 DestinationRule, ArgoCD의 Project, Application 등을 예로 들 수 있다. 물론 Custom Resource만을 정의한다고 해서 새로운 기능을 추가할 수는 없으며, 'Custom Controller' 또는 'Operator'를 통해 built-in object와 custom resource에 대한 동작을 구현해야 한다. 참고로 k8s는 Custom Controller의 쉬운 구현을 위해 client-go 라이..

ETCD Backup&Restore

ETCD는 K8s 클러스터의 모든 데이터가 위치한 저장소로, 주기적으로 백업하여 혹시 모를 재난에 대비할 수 있어야 한다. 다행히 자체적으로 스냅샷과 복원 기능을 제공하기 때문에 어렵지 않게 사용할 수 있다. K8s Master node에서 아래와 같은 작업을 진행한다. etcdctl CLI에서 etcd를 관리할 수 있는 툴이다. Ubuntu의 경우, etcd-client 패키지를 설치하면 바로 사용할 수 있다. apt update -y && apt install -y etcd-client Snapshot 생성 다음 명령어로 현재 etcd 클러스터의 snapshot을 현재 위치에 'etcd-snapshot.db' 파일로 저장할 수 있다. ETCDCTL_API=3 etcdctl --cacert=/etc/k..

Kubernetes 2021.05.29

[CKS] 취득 후기

첫 시도 5/15에 CKS 시험을 치뤘으며, 결과만 먼저 얘기하자면 66%로 커트라인인 67%를 넘기지 못하여 불합격 처리되었다. 전체 15문제 중 배점이 높은 ImagePolicyWebhook을 제대로 설정하지 못했고, 몇몇 문제에 말려서 시간을 허비하는 바람에 답안을 충분히 검토할 시간이 부족했다. 다 풀고 나니 5분 밖에 남지 않은 상황이라 아무 것도 할 수가 없었다. 아마 Manifest 파일 정의까지만 해놓은 상태에서 깜빡하고 적용을 하지 않은 답안들이 꽤 있었을 것이다. 게다가 시험 환경에서 제공하는 Notepad가 있는줄 모르고, 계속 vim을 들락날락 하면서 복사/붙여넣기 하느라 불필요한 시간을 낭비했다. CKA나 CKAD와는 달리, 대부분의 문제가 단순히 리소스 하나만 정의하는데서 끝나지..

[CKS] Supply Chain Security

Image Footprint 다음과 같은 Dockerfile이 있다고 가정한다. FROM ubuntu ARG DEBIAN_FRONTEND=noninteractive RUN apt-get update && apt-get install -y golang-go COPY app.go . RUN CGO_ENABLED=0 go build app.go CMD ["./app"] 'app.go' 파일은 아래와 같다. 1초마다 현재 사용자의 이름과 UID를 출력하며, 만약 위와 같이 따로 User를 특정하지 않는다면 root를 사용할 것이다. package main import ( "fmt" "time" "os/user" ) func main () { user, err := user.Current() if err != n..

[CKS] Runtime Security

Behavioral Analytics strace strace는 Debugging 목적으로 프로세스의 system call 호출을 intercept하여 로그를 남기는 Linux 명령어이다. 다음은 'ls' 에서 어떤 system call을 사용하는지 strace로 확인한 내용이다. 비교적 간단한 프로세스임에도 불구하고 fstat, mmap 등수많은 system call을 사용하고 있음을 알 수 있다. '-cw' 옵션을 추가하면 다음과 같이 해당 프로세스의 system call 사용 현황을 요약하여 볼 수 있다. 현재 실행중인 ETCD 컨테이너 안의 etcd 프로세스의 PID를 확인해보자. ps aux | grep etcd command를 확인하면, etcd의 PID가 3623인 것을 알 수 있다. str..

Open Policy Agent

Request Workflow 관리자나 Pod이 Kubernetes 클러스터에 접근시, API 서버 내부적으로 다음과 같은 순서를 통해 Request를 처리한다. 모든 Workflow를 통과해야만, 정상적으로 작업이 이루어진다. 1. Authentication 클라이언트에서 전달한 TLS Certificate의 Common Name 필드를 조회하여, 유효한 사용자인지 검증한다. 간단히 말하면 현재 클라이언트가 누구인지 확인하는 과정이다. 2. Authorization 해당 사용자에 대한 RBAC(Role, RoleBinding, etc.)을 확인하여 Request에서 요구하는 작업을 수행할 권한이 있는지 체크한다. 3. Admission Control Authentication 및 Authorizatio..

Kubernetes 2021.05.05