색션 13. Kubernetes로 데이터 & 볼륨 관리하기 211. Kubernetes 볼륨 : 이론 & Docker 와의 비교 당연한 말이지만 Pod의 일부로 시작되는 컨테이너에 볼륨을 탑재 하며, 탑재해야하는 내용에 대해 Pod Template 에 추가할 수 있다. 이러한 점에서 쿠버네티스는 다양한 형태와 드라이버를 제공하고 기본적으로 큰 기준으로는 과 정도로 나눌 수 있다. 여기서 핵심은 볼륨의 라이프타임, 생명주기가 Pod의 생명주기에 의존한 단 부분일 것이다. 즉, 볼륨도 쿠버네티스에 의해 시작되고, Pod와 함께하는, Pod의 일부다. 그렇다는 말은 Pod에 따라 볼륨은 달라지고, 대게 문제는 없으나, 때론 이 과정에서 문제가 발생하니 이를 이해하고, 잠재적인 문제 해결 방안을 아는게 핵심이라고 볼 수 있다. 볼륨의 수명 볼륨의 수명은 Pod 와 함게 한다고 보면 된다. 따라서 내부의 컨테이너의 수명과는 관련이 없어서, 컨테이너를 다시 시작하고, 제거해도 살아남는다…

색션 13. Kubernetes로 데이터 & 볼륨 관리하기 208. 모듈 소개 우리는 쿠버네티스를 활용하여 컨테이너를 배포하는 기능들을 실습했고, 이를 minikube 위에서 진행했다. minikube 는 하나의 호스트 머신이자 로컬 호스트의 가상 머신이기도 하다. 하지만 이것으로 끝이 아니라 쿠버네티스는 궁극적으로 애플리케이션을 다중 시스템, 다중 노드 클러스터에 배포한다는 목표까지 나아가야 한다. 이러한 점에서 우리는 도커를 배울 때와 비슷한 문제를 직면하게 되는데, 즉, 데이터를 저장하고 관리하는 방법에 대한 명확한 길이 제시 되어야한다. 왜냐하면, 컨테이너가 종료되거나, 쿠버네티스가 관리 과정에서 Pod의 제거, 확장, 노드 간의 이동 등으로 데이터를 적절하게 유지되도록 보장하게 만들 수 있는가가 매우 중요하기 때문이다. 따라서 이번 챕터는 볼륨에 대해 도커에서의 개념을 다시 한 번 살펴보고, 쿠버네티스의 볼륨의 작동, 유지 방법에 대해 알아볼 것이다. 일반볼륨, 영구 볼…

색션 12. 실전 Kubernetes - 핵심 개념 자세히 알아보기 203. Label & Selector selector 에 대해 다시 이야기를 해보고자 한다. 이는 다른 리소스를 리소스에 연결하는데 사용하는 용도라는 중요한 기능을 가지고 있기 때문이다. selector 는 기본적으로 서비스나, deployment를 모니터링하고 연결시키는 역할을 한다. 최근의 현대적 selector는 이라는 것이 있고, 거기서 더 나아가서 이라는 개념을 사용한다. 이는 좀더 다양한 기능들을 지원한다. 기본적으로 -(하이픈)을 통해 구성이 되며, 중괄호 내의 키와 값으로 구성되어 있다. 추가로 Operator 가 들어갈 수 있다는 점이 차이점이다. In이란 값을 가지면, 각 키의 값들에 포함되면 감지가 되는 구조라고 보면 된다. 더 많은 자원 제어와, 유연성이 필요하면 가 적절하다 그러나 기본적인 경우에는 어지간하면 쓰지 않아도 충분하다. 더불어 하나 알아둘 것이 metadata는 키값=쌍의 구…

색션 12. 실전 Kubernetes - 핵심 개념 자세히 알아보기 200. 선언적으로 service 만들기 service.yaml 이렇게 구동한 다음 서비스에 접근하게 되면 어플리케이션에 접근이 가능해진다. 여기까지를 통해 어플리케이션을 선언적 방식을 통해 띄우는 것 까지 가능했다. 이를 통해 우리는 에러, 명령적으로 매번 쳐줘야할 번거로움을 해결했다. 201. 리소스 업데이트 & 삭제 어떻게 바꾸면 되는가? YAML 파일에 변경할 내용을 수정한 뒤 간단하게 apply 를 하면 된다. 즉, YAML 에서 설정 가능한 부분은 수정하고 적용하면 쉽게 구성을 바꿀 수 있는 것이다. 어떻게 삭제하면 되는가? 기존에 방식으로 명령어를 통해 하는 것도 가능하다. 하지만 -f 옵션과 함께 해당 config 파일을 지목해주면, 이 역시 동일하게 지정한 것들을 삭제하는 것이 가능해진다. 202. 다중 vs 단일 config 파일 master-deployment.yaml 개발자가 원하면 ya…

색션 12. 실전 Kubernetes - 핵심 개념 자세히 알아보기 198. Pod와 컨테이너 사양(Spec) 추가 Spec 추가 template는 항상 Pod 를 대변하는 객체이다. 따라서 최초에 를 통해 deployment 를 설정한 것과는 다르게 설정되는 것이다. 더불어 이렇게 설정하는 것은 전체 Pod에 대한 설정이라고 생각하면 된다. Pod 설정하기 - 개체 -f 는 파일을 인식시키기 위한 옵션 값, 여러 개를 인식 시킬 때는 이 옵션을 여러번 사용하면 된다. 우선 이렇게 해보면 에러메시지로 가 필요하다고 이야기 한다. selector란 어떻게 하는 것인가. deployment 는 쿠버네티스 속에서 동적인 객체다. Pod의 확장 명령이 떨어지면 deployment 가 지속적으로 감시하며 살핀다. 이때 제어야 할 필요가 있을 때 가 필요해진다. Pod에 대한 라벨링, 티어 설정 등은 자유롭게 할 수 있고, 그걸 지정한 뒤 selector가 이걸 가리킴으로써 deploy…

색션 12. 실전 Kubernetes - 핵심 개념 자세히 알아보기 196. 명령적 접근방식 vs 선언적 접근방식 명령적 접근방식에서 선언적인 방식으로 여러가지 명령어를 통해 쿠버네티스를 구동하는 것을 배웠다. 그러나 이러한 방식의 단점은? 어렵진 않으나 명령어를 외워야 한다. 매번 작업에 적용해야 한다. 이러한 점들은 docker 때와 비슷하게 불편할 수 있고, docker compose를 배운 뒤 훨씬 편해졌고, 이러한 내용이 kubectl에도 적용될 수 있다. A Resource Definition 위에서 언급한 것처럼 파일 내의 구성을 기반으로 deployment 를 생성할 수 있고, 이를 쿠버네티스는 지원한다. YAML 파일 형태를 지원한다. 예시파일 비교 명령적 접근방식 선언적 수행방식 개별 명령어를 쳐서 접근하고 실행시킨다 파일 기반으로 상태가 적용되고 수정된다. docker run과 유사 docker compose 와 유사 197. 배포 구성 파일 생성하기(선언…

색션 12. 실전 Kubernetes - 핵심 개념 자세히 알아보기 195. Deployment 롤백 & 히스토리 rollout undo image를 잘못 설정 하는 등의 문제가 발생할 수 있다. 이렇게 된 상태에서 상태를 보기 위해서는 rollout 커맨드를 활용할 수 있다. 이렇게 되면 문제가 발생하고 이때 상태를 보고자 커맨드를 활용하면 대화용 세션으로 들어가게 된다. 실제로 이렇게 되면 대시보드에서도 pod에 문제가 발생하게 된다. 오래된 복제본이 종료가 발생하지 않으며, 신규 pod은 계속 pending 상태를 유지하는 것이다. 이렇게 되는 이유는 kubernetes에서는 정책상 신규 pod 가 정상 실행 전 까지는 이전 이미지를 담은 구버전 pod 가 종료되지 않으며, 이를 통해 서비스가 계속 유지 되도록 만드는 것이다. 이러한 에러가 발생해서 다시 정상적인 버전으로 이미지를 돌려야 한다. 이렇게 하고 나니 pod 의 문제가 해결되고 기존 버전으로 돌아오게 된다. r…

색션 12. 실전 Kubernetes - 핵심 개념 자세히 알아보기 192. 컨테이너 재 시작 실습에서 /error 이라는 라우팅과 함께 Node 예제를 종료 시키는 코드를 갖고 있었다. 해당 URL 에 접근하게 되면, process 가 종료하게 되면서 에러가 발생하게 된다 . 이때 이렇게 되는 것은 pod와 pod의 컨테이너 상태를 모니터링 되고 있고, 모닌터링 과정에서 실패가 발생하면 다른 걸로 교체가 되거나 하는게 아닌, 일단은 해당 pod와 pod 내의 컨테이너를 다시 시작한다. 또한 이 내용은 kubernetes dashboard에서도 볼 수 있는 것이다. 또한 해당 pod로 들어가면 세부적으로 그러한 행동이 나타났다는 로그 등도 함께 확인이 가능하다. 193. 실제 스케일링 재시작과 관련한 유용한 명령이 하나 더 있다. 오토 스케일링 기능이 없다고 생각하면 kubectl 은 자동으로 pod의 숫자를 늘리거나 줄이지 않는다. 이럴 때 트래픽이 더 많이 유입될 것이라고 …

색션 12. 실전 Kubernetes - 핵심 개념 자세히 알아보기 188. 첫 번째 Deployment - 명령적 접근 방식 사용 쿠버네티스를 배우면서 생기는 가장 기본적인 망각 중에 하나가, 바로 도커를 결국 사용은 한다는 점이다. 반대로 도커를 자체적으로 컨테이너를 실행하지 않는 다는 것이다. 필요한 프로그램, 도커 파일이 준비되어 있다면 docker 이미지를 준비한다. 이미지가 빌드 되고 나면 이미지를 이제 쿠버네티스 클러스터로 보내면 된다. (Pod) Pod 가 이를 실행하고 관리할 것이다 deployment 올릴 쿠버네티스에 상태를 파악해야 하므로 minikube status 로 상태를 파악한다. 이때 동작하는 minikube가 정상이 아니라면, 다시 minikube를 재시작 하면 된다. kubectl 을 기억하자. : 지난 시간에 이 툴을 설치했음. 해당 툴은 항상 로컬 기준으로 존재하고, 로컬 시스템에서 실행하는 명령이다. 마스터 노드와 해당 클러스터의 컨트롤러라고 …

색션 12. 실전 Kubernetes - 핵심 개념 자세히 알아보기 183. Kuberntes: 요구 설정 & 설치 단계 로컬 머신에서 쿠버네티스를 다루기 위해 설치해야 할 구성요소는 다음과 같다: 클러스터: 쿠버네티스 클러스터는 마스터 노드와 하나 이상의 워커 노드로 구성되며, 이 클러스터는 실제 머신이나 가상 인스턴스에 분산되어 운영될 수 있다. 마스터 노드 소프트웨어: 마스터 노드에는 쿠버네티스의 핵심 구성 요소인 API 서버, 스케줄러 등이 설치되어야 한다. 워커 노드 소프트웨어: 워커 노드에는 Docker와 같은 컨테이너 런타임과 kubelet이 설치되어야 한다. kubectl: 쿠버네티스 클러스터와 통신하기 위한 커맨드 라인 인터페이스 도구로, 개발자와 관리자는 이를 사용하여 클러스터에 명령을 보낼 수 있다. 로컬에서 쿠버네티스를 실험하기 위해서는 다음 도구도 필요하다: minikube: 로컬 머신에서 쿠버네티스 클러스터를 쉽게 생성하고 관리할 수 있는 도구로, 가상 머…

색션 12. 실전 Kubernetes - 핵심 개념 자세히 알아보기 181. 모듈 소개 본 모듈에서 진행할 학습 내용은 총 3단계 Kubernetes, 테스팅 환경 구축해보기 Kubernetes 객체들과 작업 진행해보기 실제로 예제를 통해 배포를 진행해보기(local 환경으로) 182. Kubernetes 는 인프라를 관리하지 않습니다. 쿠버네티스가 해주는 작업과 아닌 작업을 구분을 명확하게 하는 것이 해당 도구를 효과적으로 사용하는 가장 핵심 중에 핵심이다. 쿠버네티스가 할 수 없는 것은 머신의 구체적인 가상 인스턴스나 컴퓨터에 대해 전혀 모르며 쿠버네티스 API 서버, Kublet 및 다양한 서비스는 매뉴얼하게 스스로 설정해줘야 한다. 인스턴스나 시스템을 업데이트 하고, 운영체제 업데이트를 유지하며, 전체 네트워크 보안 그룹 항목의 관리 등은 결국 개발자의 몫이다. 쿠버네티스가 관심 가지는 영역은 실패한 컨테이너에 대해선 관심을 가진다. 포드를 생성, 포드에서 컨테이너를 실행…

kubernetes 가 정확히 무엇인가? 쿠버네티스는 기존 강의에서 언급한 수동으로 배포 및 웹 프로바이더들에 제약이 되는 등의 문제를 개선하는, 어떤 웹 클라우드 서비스에서도 독립적으로 구축이 가능한 오픈소스 시스템이다. 컨테이너 배포 관리, 컨테이너 오케스트레이션 가능, 자동 배포, 스케일링, 로드 밸런싱, 배포나 관리 등을 전반적으로 도와준다. 특히, 컨테이너를 모니터링하다, 다운이 되면 자동으로 교체하는 등에서 도움이 된다. kubernetes configuration 만 작성하면 쉽게 구성이 가능하다. 더불어 특정 도구로 클라우드나 어떤 머신이든 해당 속성으로 자동으로 배포 및 설정을 가능케 해준다.(즉 표준일 뿐 아니라 도커-컴포즈에서 좀더 확장되어 서버 전체를 설정, 관리 정책을 담은 일종의 통합 도구인 셈이다.) 여기에 더 나아가서 혹여 특수한 클라우드 프로바이더들 사이에 옵션을 추가하면, 해당 클라우드 프로바이더에 특화도 가능하며, 반대로 다른 클라우드에서 사용시 …

색션 11. Kubernetes 시작하기 모듈 소개 도커 컨테이너 배포 섹션에서 도커 컨테이너를 배포하는 방법은 배웠음 쿠버네티스란 실제로는 도구라기 보단 프레임워크, 개념 모음, 표준 이라고 할 수 있다. 모듈 컨텐츠 컨테이너 배포를 할 때 생기는 문제 이해하기 쿠버네티스가 무엇이며 왜 써야 하는가? 쿠버네티스의 개념과 컴포넌트들 수동 배포의 더 많은 문제점들 쿠버네티스 공식 사이트를 찾아보면 쿠버네티스에 대하여 “Kuberneetes is an open-source system for automating deployment, scaling, and management of containerized applications” 라고 부른다. 이를 통해 알 수 있는 것은 쿠버네티스가 단일 소프트웨어가 아닌 시스템이란 점이다. 컨테이너 배포에 도움이 되는 일체를 갖고 있다는 것을 알 수 있다. 우리는 아마도 문제 상황에 직면하게 된다. 컨테이너를 수동으로 배포하는 것에 대해 생각해보자.…

Next Peer 를 위한 고민 : 시작 피어 웹 서비스의 구현의 목적은 총 3단계로 구성되어 있다. 기획의 핵심은 순환이다. 프로젝트, 스터디의 핵심은 결국 계속해서 타인과 타인 사이에서도 남아야 하며, 만드는 사람들은 목적을 쉽게 달성하며, 동시에 쉽게 자기나 자신의 결과물을 잘 보이는게 핵심이다. 그걸 위해 시작하는 모집글 작성에서 시작하여 협업을 위한 허브 역할의 팀 페이지와 게시판, 쪽지, 그리고 최종적으로 쇼케이스나 피어로그와 같은 것들이 협업의 과정에서의 순환과 결과물의 공유와 강조 등을 포함한다. 그런 전체 목표 중에 다음 주 중에 공개될 피어 웹 어플리케이션은 대략 2.3~4 단계정도의 진행 정도를 보여준다. 핵심적인 기획은 아직 적용이 안되어 있으며, 특히나 프론트의 딜레이와 버기한 상황들은 앞으로 해당 내용의 확장, 혹은 진화에 조금 더 시간이 걸릴 것으로 보인다. 어쨌든 프론트의 딜레이와 보안을 하려고 하다보니 시간이 남게 되었고, 덕분에 조금 더 백엔드 구…