쿠버네티스

파드 내에 초기화만을 담당하는 컨테이너를 설정할 수도 있다. 그러면 초기화만을 수행하는 컨테이너와 요청을 처리하는 컨테이너를 별도로 개발하여 각각 재사용할 수 있다. 예를 들어 스토리지를 마운트할 때 '스토리지 안에 새로운 디럭터리를 만들고, 소유자를 변경한 후 데이터를 저장'하는 것과 같은 초기화 처리를 전담할 수 있다. Init-sample.yml apiVersion: v1 kind: Pod metadata: name: init-sample spec: containers: - name: main # 메인 컨테이너 image: ubuntu command: ["/bin/sh"] args: ["-c", "tail -f /dev/null"] volumeMounts: - mountPath: /docs # 마운..

이번엔 MacOS 환경에서 쿠버네티스를 설치해보겠다. Docker가 설치 안되신 분들은 Docker 홈페이지에 가서 다운로드 받아야 한다. Docker를 설치 후 로그인까지 한다. Homebrew 사용해서 쿠버네티스를 설치하려고 한다. 설치가 안되어 있으신분들은 Homebrew 홈페이지에 가서 설치법을 보고 설치하면 된다. brew install kubectl 또는 brew install kubernetes-cli를 실행해 kubectl을 설치한다. 설치한 버전이 맞는지 확인한다. kubectl cluster-info로 클러스터의 상태를 확인할 수 있다. The connection to the server was refused - did you specify the right host or port? 와..

컨트롤러에 의한 파드 실행 kubectl run에 옵션을 지정하면 파드를 디플로이먼트 컨트롤러의 제어하에 실행하는하려면 옵션 --restart=Always을 주면된다.(기본값 Always) 파드만 독립적으로 실행하고 싶을 때는 --restart=Never 옵션을 주면된다. 파드가 정지되었을 때 재기동 시킬 필요가 있는지에 따라 옵션을 정하면 되겠다. 디플로이먼트 컨트롤러에 의해 파드가 기동될때는 백그라운드로 실행되기 때문에 -it 옵션은 무시된다. kubectl run 서브 커맨드의 기능이 지나치게 방대해지는 것을 막기 위해 파드 자체를 만들때만 run을 사용하는 것이 추천되고 있다. 디플로이먼트를 먼들 때는 kubectl create deployment --image hello-world hello-w..

윈도우를 사용한다면 전 블로그글을 확인하고 실행 환경을 구축해야한다. 파드 실행 kubectl run 명령어를 입력하고 결과가 표시될 때까지의 흐름은 다음과 같으며 도커 명령어와 비슷하다. kubectl이 쿠버네티스에게 명령을 전달한다. 노드에 이미지가 없으면 원격 리포지터리(Docker Hub)에서 다운로드 한다. 노드의 containerd가 컨테이너를 실행한다. kubectl이 터미널에 메시지를 표시한다. 쿠버네티스의 특징 중 하나는 개인의 PC, 퍼플릭 클라우드, 온프레미스의 모든 환경에서 동인할 kubectl 명령어로 조작할 수 있다는 점이다. 따라서, 미니쿠베를 잘 익혀두면 5,000대 규모의 클러스터(버전 1.11 기준)도 다룰 수 있다. 파드는 쿠버네티스에서 컨테이너를 실행하는 최소 단위이다..

쿠버네티스를 윈도우 환경에서 하나하나 정리하며 설치해보겠다. MacOS 환경에서 설치는 블로그글에서 확인할 수 있다. 아래 블로그 글에서 도커 툴박스를 설치한다. [Docker] 윈도우에서 도커 설치하기 (툴박스 vs 데스크탑) 0. 왜 툴박스를 사용해야 할까? 도커 데스크탑 애플리케이션은 윈도우 professional, enterprise, education 버전에서 사용이 가능하다. 윈도우 홈 버전은 Hyper-V를 지원하지 않아서 도커 툴박스를 사용해야 jinyes-tistory.tistory.com Docker Quickstart Terminal을 실행하면 E_FAIL (0x80004005) 에러가 날 수 있는데 그럴땐 CMD를 관리자로 열어 bcdedit /set hypervisorlauncht..

퍼시스턴스 볼륨 API 구현 예시 컨테이너를 지워도 데이터를 잃지 않기 위해서는 퍼시스턴트 볼륨을 사용해야 한다. 앞에 작성한 환경 변수 API 구현 예시에서 만든 my_daemon을 수정해서 퍼시스턴스 볼륨 API 예시를 구현해보자 외부 저장소를 마운트한 디렉터리에 데이터를 쓰도록 바꾸었다. 다시 이미지를 생성하고 컨테이너를 실행해보자 호스트상에 퍼시스턴트 볼륨으로 마운트할 디렉터리를 만든다. -v 호스트절대경로:컨테이너내경로로 볼륨의 path를 설정한다. 다른 터미널에서 컨테이너를 중지하고 다시 재기동 한다. COUNT가 이어서 출력되는것을 확인할 수 있다. 그럼 아예 컨테이너를 삭제 후 다시 컨테이너를 실행해보겠다. 삭제 후 컨테이너를 다시 생성해 시작해도 COUNT가 이어서 출력되는것을 확인 할 ..

환경 변수 API 구현 예시 이번에는 d5라고 하는 디렉터리를 만들고 Dockerfile과 my_daemon이라고 하는 2개 파일을 바탕으로 컨테이너를 개발할 것이다. FROM을 사용해 베이스 이미지로 apline을 지정했다. RUN에서는 apk add bash로 bash 셸을 추가했다. ADD로는 셸 스크립트 my_daemon을 루트 경로에 배치하고 CMD로 컨테이너가 기동할 떄 실행하게 했다. my_daemon은 컨테이너가 기동되면 실행되는 셸 스크립트다. 보통 자바나 파이썬으로 작성한 코드를 컨테이너로 만드는 경우가 많은데 이번에는 간단한 예를 위해 셸 스크립트를 사용했다. 환경 변수 INTERVAL이 없는 경우에는 3초 단위로 현재 시간과 카운트를 표준 출력(STDOUT)에 출력한다. 환경 변수 ..

컨테이너 API의 종류와 개요 컨테이너 API란 컨테이너를 블랙박스처럼 다룰 수 있게 해주는 인터페이스이다. 소프트웨어에서는 서로 다른 팀이 개발한 프로그램들을 연결하기 위해 서로 지켜야 하는 규격을 인터페이스라 한다. 따라서 API는 대상이 되는 프로그램을 블랙박스로 취급하여 다른 프로그램에서 호출할 수 있게 해준다. 이는 쿠버네티스 환경에서도 사용된다. 컨테이너 API는 몇 가지 종류가 있으며, 각각의 목적과 사용법이 다르다. 모든 API를 필수적으로 알고 구현해야 되는 것은 아니다. 애플리케이션의 특성에 맞게 적절한 API를 선택하여 구현하면 된다. 컨테이너 기동 컨테이너 내의 애플리케이션은 기동 시에 환경 변수나 실행 인자를 읽어서 그에 맞게 동작하게 만들 수 있다. 헬스 체크(쿠버네티스 환경) ..

Dockerfile 작성 모범 사례 컨테이너의 설계 철학에 맞게 이미지를 만들어야 생산성이 높아지고 운영 중 겪게 될 문제를 사전에 예방할 수 있다. 종래의 오케스트레이션 도구인 Ansible이나 Chef 등은 서버들의 목표로 하는 상태로 만든다는 사고 방식으로 동작한다. 그리고 그 동작 방식은 멱등성(Idempotence)에 기초하여 몇 번을 배포해도 한결같이 목표로 하는 상태로 만들어 준다. 이들 도구들은 서버의 기동이나 설정에 오랜시간 걸리는 것을 고려하여 만들어졌다. 도커의 경우는 Dockerfile에 운영체제와 의존 패키지를 기술하여 이미지를 만들면 굉장히 짧은 시간에 컨테이너를 기동/교체/종료할 수 있다. 그리고 이미지에는 운영체제와 패키지가 이미 모두 포함되어 있으므로 배포 시 추가적인 시간..

여러 터미널에서 조작하기 2개 이상의 터미널에서 하나의 컨테이너에 접속하여 작업을 수행하는 것도 가능하다. 이처럼 같은 컨테이너에 여러 터미널이 접속하여 작업하는 것이 가능하다. 인증 과정도 없기 때문에 가상 서버보다 더 편리하게 사용할 수 있다. 이때 보안을 위해 호스트 외부에서 접속은 막혀 있다. 또한 컨테이너 내에는 외부에서 로그인하기 위한 sshd를 기동시키지 말아야 한다는 의견도 있다. 로그인을 관리하지 않는 컨테이너 리눅스 서버에서는 w 명령어로 동시에 로그인한 다른 유저의 정보를 얻을 수 있다. 하지만 아무것도 출력되지 않는다. 이유는 컨테이너에 로그인을 통한 유저 인증 기능도 없고, 유저 자체를 관리하지 않기 때문이다. 리눅스는 기본적으로 멀티 유저용으로 개발되었지만 컨테이너는 싱글 유저용..