"네가 지금까지 번민했던 일은 문제가 해결되고 나니 정말 어리석고 시시한 일처럼 느껴지는구나."친구는 너무나도 행복해 보이는 다카시와 병 속 캡슐들의 해후에 질투가 이는 것처럼 말했다."무릇 모든 번민이라는 게 일단 해결되고 나면 어리석고 시시하게 느껴지는 것 아닌가요? 형이 일부러 귀국해서 요양소에 들어가는 일만 해도 형 머릿속에서 헝클어진 매듭이 풀리고 나면 그저 어리석고 시시한 짓으로 기억되고 끝나지 않겠어요?"다카시가 반발하듯 말했다."풀리기만 한다면야······. 하지만 풀리지 않는다면 그 어리석고 시시한 일이 내 인생의

1. 컨피그맵만으로 다루기 어려운 민감 정보 애플리케이션이 다루는 설정값 중에는 SSH 키, 비밀번호, 인증 토큰처럼 외부에 노출되어서는 안 되는 값들이 있다. 컨피그맵도 문자열 값을 담아 환경 변수나 볼륨 파일로 파드에 전달할 수 있지만, 컨피그맵은 애초에 노출되어도 문제없는 일반 설정을 다루기 위한 오브젝트다. 쿠버네티스는 이런 민감 정보를 별도로 다루기 위해 시크릿(Secret)이라는 오브젝트를 둔다. 시크릿은 컨피그맵과 마찬가지로 네임스페이스에 속하고, 파드에 값을 전달하는 방식도 환경 변수와 볼륨 파일 두 가지로 동일하다.

서른 살 청년 이회영이 물었다. "한 번의 젊은 나이를 어찌할 것인가." 눈을 감는 순간 예순여섯 노인 이회영이 답했다. 예순여섯의 '일생'으로 답했다. 나도 벌써 서른이라니... 나이를 하나씩 먹어갈수록 더 그렇게 느끼지만 세월이 참 빠른 것 같다. 역사 속 인물들처럼 대단한 삶은 아닐지 몰라도 스스로에게 부끄럽지 않은 삶을 살아야겠다는 생각이 들었다. "진실로 너희들에게 바라노니, 항상 심기를 화평하게 가져 중요한 자리에 있는 사람들과 다름없이 하라. 하늘의 이치는 돌고 도는 것이라서, 한번 쓰러졌다 하여 결코 일어나지 못하는

설정값을 애플리케이션에 전달하는 문제 애플리케이션은 대부분 설정값을 가진다. 로그 레벨처럼 단순한 키-값 부터 nginx.conf처럼 완결된 설정 파일 하나까지 그 형태는 다양하다. 이런 설정을 애플리케이션에 전달하는 가장 확실한 방법은 도커 이미지 안에 설정값이나 설정 파일을 정적으로 넣어 두고 함께 빌드하는 것이다. 그러나 도커 이미지는 한번 빌드되면 불변(immutable)이다. 이미지 안에 박아 둔 설정값은 상황에 따라 유연하게 바꿀 수 없고, 값 하나를 바꾸려 해도 이미지를 다시 빌드해야 한다. 그래서 흔히 쓰는 대안이 설

1. 네임스페이스(Namespace) 도커나 도커 스웜 모드에는 컨테이너를 논리적으로 나눠 관리하는 개념이 없다. docker ps를 실행하면 호스트에 떠 있는 모든 컨테이너가 한 목록에 뒤섞여 나온다. 컨테이너 수가 늘어날수록 어떤 것이 어떤 애플리케이션에 속하는지 구분하기가 어려워진다. 쿠버네티스는 이 문제를 네임스페이스(Namespace)라는 오브젝트로 해결한다. 네임스페이스는 파드, 레플리카셋, 디플로이먼트, 서비스 같은 리소스들이 묶여 있는 하나의 가상 공간이다. 리소스를 용도별로 묶어 두면, 서로 다른 목적의 리소스가 한

— 태성쌤 친필 사인 —올해 초 우연히 보게 된 영화를 계기로 세웠던 목표가 있다. 바로 한국사 시험에 합격하고 경주로 여행을 간다는 목표인데, 시험에 합격했다는 사실보다 역사 속 인물들을 공부하면서 가르침을 얻고, 내 삶을 대하는 태도가 또 조금은 바뀌게 된 것 같아서 기분이 좋다. 사실 최근 갑작스럽게 새로운 프로젝트에 투입되면서 경주 여행은 힘들겠구나 생각하고 있었는데, 마침 울산으로 출장을 가게 되어 겸사겸사 하루 먼저 여행을 왔다. 자취 시작한지 한달도 안돼서 멀리 떠나게 된 게 슬프지만, 피할 수 없다면 즐겨야지...—

어리석고 천박한 정신을 가진 사람에게는 이것이 아주 사소한 일로 보일지 모른다.하지만 매사를 깊이 사고하려는 현명한 사람에게 이런 이야기야말로 자신의 사고와 상상력을 깊고 풍부하게 만드는데 도움을 줄 뿐 아니라, 개인이나 사회인으로 생활하는 데 있어서도 많은 도움을 줄 것이라 믿기 때문이다.바로 이것이 내가 이 여행을 비롯한 여러 여행기를 세상에 내보내는 이유다.어렸을 때 동화로만 접했던 작품이었는데, 성인이 되어 다시 읽어 보니 생각보다 훨씬 충격적인 소설이라는 느낌을 받았다. 지금 읽어도 불편하게 느껴지는 내용이 많은데, 당시의

1. 파드 IP만으로 통신할 때의 한계 쿠버네티스에서 파드에 직접 접근하려면 kubectl describe로 파드 IP를 확인한 뒤 그 IP로 접속하면 된다. 이 방식은 클러스터 내부에서 동작 여부를 빠르게 확인할 때만 사용이 가능하다. 파드 IP는 영속적이지 않다. 파드가 재시작되거나 다른 노드로 재스케줄링되는 순간 새 IP를 할당받으므로, 한 번 확인한 IP가 무효가 될 수 있다. 또한 여러 디플로이먼트를 하나의 애플리케이션으로 엮을 때 서로의 파드 IP를 미리 알 방법이 없다. 예를 들어 프론트 파드에서 백엔드 파드를 호출하려

디플로이먼트: 레플리카셋의 상위 오브젝트 실제 운영 환경에서 레플리카셋을 YAML로 직접 정의하는 경우는 거의 없다. 대신 디플로이먼트를 YAML에 정의하고, 디플로이먼트가 레플리카셋을 생성, 교체, 삭제한다. 디플로이먼트는 레플리카셋의 상위 오브젝트로, 하나의 디플로이먼트는 시점에 따라 여러 개의 레플리카셋을 가질 수 있다. 디플로이먼트가 필요한 이유는 새 버전으로의 전환과 이전 버전으로의 복귀를 레플리카셋 단독으로는 처리할 수 없기 때문이다. 레플리카셋과 파드 레플리카셋과 디플로이먼트의 YAML은 거의 동일하다. kind만 Re

1. 레플리카셋이 필요한 이유 마이크로서비스 환경에서는 같은 역할을 하는 파드를 여러 개 동시에 운영해야 한다. 트래픽을 나눠 받기 위해서이기도 하고, 일부 인스턴스가 실패해도 나머지가 요청을 계속 처리하도록 가용성을 확보하기 위해서이기도 하다. 따라서 쿠버네티스에서 실제로 다루는 단위는 단일 파드가 아니라 동일한 스펙의 파드 N개가 된다. 이를 직접 정의하기 위해 YAML 매니페스트 안에서 ---를 구분자로 두어 동일한 파드 여러 개를 한 번의 kubectl apply로 생성할 수도 있지만, 이는 비효율적인 방법이다. 또한 파드가