본문 바로가기

공부기록/42 Seoul

[ft_services] 쿠버네티스 알아보기 및 구현 시작

https://subicura.com/k8s/

 

쿠버네티스 안내서

쿠버네티스 안내서 - 실습편

subicura.com

👆 저번 포스팅에서 쿠버네티스 개념을 잡을 때 봤던 포스팅이이랑 같은 작성자분이 만든 실습인데, kubectl 기본 명령어와 각종 오브젝트(Pod, ReplicaSet, Deployment, Service, ...)의 사용법을 알 수 있다. 개념버전에 이어 실습버전도 역시나 정주행할 가치가 있다.


 

과제에서 쓰일만한 부분만 살짝 정리

kubectl 명령어

apply

kubectl apply -f [파일명 또는 URL]

 

  • 원하는 리소스의 상태를 YAML로 작성하고 apply 명령어로 적용한다.
  • docker로 만든 컨테이너를 apply 하면 쿠버네티스가 그 컨테이너를 감시할 수 있게 된다.
  • -f 옵션은 filename을 의미
  • 아래와 같이 URL 형태와 파일 경로를 모두 사용할 수 있다.
    •  kubectl apply -f https://subicura.com/k8s/code/guide/index/wordpress-k8s.yml 
    • 또는  kubectl apply -f wordpress-k8s.yml 

 

yaml 설정파일 구성

👇 참고사이트. 이 시리즈도 정말 좋음. 시리즈가 길어서 다 보진 않았는데 아래 포스팅은 yaml 파일의 각 항목이 어떤 역할을 하는지 이해하기 쉽게 설명되어 있다.

 

쿠버네티스 #2 - 개념 이해 (1/2)

쿠버네티스 #2 개념 이해 (1/2) 조대협 (http://bcho.tistory.com) 쿠버네티스를 공부하면서 가장 헷갈리는 부분이 용어와 컨셉이다. 이 컨셉만 잘 이해하면 쿠버네티스를 쉽게 이해하고 사용할 수 있지

bcho.tistory.com

  • 쿠버네티스는 리소스를 관리할 때 name과 label을 기준으로 리소스들을 식별한다.
  • 필수 요소(아래 4개는 꼭 포함되어야 할 항목)
    • version : 오브젝트 버전 (ex. v1, app/v1, ...)
    • kind: 리소스 타입 (ex. Pod, Development, Service, ...)
    • metadata: name, label, annotation으로 구성
    • spec: 상세명세. 리소스 종류마다 다름


리소스 타입에 대하여

Deployment

Service

  • 공식홈페이지 문서링크
  • Pod에서 실행중인 어플리케이션을 네트워크에 노출시키는 오브젝트이다. 쿠버네티스는 Pod에게 고유한 IP 주소와 단일 DNS 명을 부여하고, 그것들 간에 로드밸런스를 수행할 수 있다. 쉽게 말해, Service를 정의해주지 않으면 브라우저에서 ip주소를 이용해 접근할 수가 없다.
  • Service는 노출 범위에 따라 ClusterIP, NodePort, LoadBalancer 타입으로 나뉜다.
  • 우리 과제의 경우 FTPS, Grafana, Wordpress, phpMyAdmin, nignx는 LoadBalancer타입이고, Influx DB와 MySQL은 ClusterIP 타입이다.
    • ClusterIP : 클러스터 내부에 새로운 IP를 할당하고 여러 개의 Pod을 바라보는 로드밸런서 기능을 제공한다. 그리고 서비스 이름을 내부 도메인 서버에 등록해 Pod 간에 서비스 이름으로 통신할 수 있다. 단, ClusterIP 타입은 클러스터 내부에서만 접근할 수 있다.
    • NodePort : 우리 과제에선 사용이 금지 된 타입이다. NodePort 서비스는 클러스터 외부에서 접근할 수 있게 해준다. 노드가 사라졌을 때 자동으로 다른 노드를 통해 접근하는 것이 불가능하다는 단점이 있다고 한다.
    • LoadBalancer : 노드가 사라졌을 때 자동으로 다른 노드에 접근할 수 있도록 모든 노드를 바라보고 있다. 브라우저는 서비스에 직접 요청을 보내는 것이 아니라 Load Balancer에 요청하고, Load Balancer가 알아서 살아있는 노드에 접근하는 방식이다.

Secret

  • 공식홈페이지 문서링크
  • Secret을 사용하면 비밀번호, OAuth 토큰, ssh 키와 같은 민감한 정보를 저장하고 관리할 수 ​​있다. 기밀 정보를 시크릿에 저장하는 것이 Pod 정의나 컨테이너 이미지 내에 그대로 두는 것보다 안전하고 유연하다.

ConfigMap

  • 공식홈페이지 문서링크
  • ConfigMap은 키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트이다. Pod는 볼륨에서 환경 변수, 커맨드-라인 인수 또는 구성 파일로 컨피그맵을 사용할 수 있다. ConfigMap을 사용하면 컨테이너 이미지에서 환경별 구성을 분리하여, 애플리케이션을 쉽게 이식할 수 있다.
  • 우리 과제에선 LoadBalancer로 metalLB 를 사용하는데, metalLB를 설정해줄 때 configMap을 사용한다.

 

설명을 읽는 것만으로는 잘 이해가 안 됐는데, github에 있는 yaml 파일들을 참고하면서 보니 어느정도 이해가 됐다. 
그리고 여기까지 공부하고 subject PDF 를 다시 읽었더니 처음보다 훨씬 많은 부분들이 이해됐다.
이제 metalLB 부터 설정해보면서 본격적인 구현을 시작하면 될 것 같다.

시작!

 

minikube start --driver=virtualbox

 

👇 아래 명령어를 실행해줘야 minikube 내에 있는 docker daemon을 사용할 수 있다.

eval $(minikube -p minikube docker-env)

위 명령어의 의미는?

eval

: 재귀적인 명령어 실행에 사용. eval을 사용하면 쉘은 명령어의 해석을 다시한번 실행한다.

minikube docker-env

: minikube의 docker daemon을 활용하기 위한 환경을 설정

minikube -p

-p 옵션: 사용되는 minikube VM 의 이름. 여러개의 minikube 인스턴스를 독립적으로 실행할 수 있게 하기 위해 허용될 수 있다. (default "minikube")

👆 무슨 뜻이지;;?

 

뭔말이냐면, 그림을 먼저 보자.

 

출처: Docker 공식홈페이지

여기서 docker daemon은 우리의 맥북 내에서 돌아가고 있다. 그냥 로컬에서 도커를 사용할때, 우리는 docker cli로 맥북 내에 위치한 docker daemon과 소통한다.

하지만 우리는, minikube 내에서 docker를 사용해야한다. 그래서 docker cli가 맥북 내부의 docker daemon이 아닌, minikube 안에 있는 docker daemon과 소통할 수 있게 연결해줘야한다. 방법은, 단순히 환경변수를 몇개 설정해주면 되는데...

$ minikube docker-env

 

아래는 위 명령의 실행결과이다. 다음과 같이 환경변수가 자동으로 셋팅된다. 주석에서 현재 쉘을 minikube의 도커데몬과 연결하고 싶으면 eval 명령어를 쓰라고 알려주고있다.

export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.100:2376"
export DOCKER_CERT_PATH="/Users/hysimok/.minikube/certs"
export MINIKUBE_ACTIVE_DOCKERD="minikube"

# To point your shell to minikube's docker-daemon, run:
# eval $(minikube -p minikube docker-env)

 

 

로컬에서 그냥 docker ps 명쳥어를 쳐보면 아무것도 없지만, 위 eval 명령어를 써서 minikube 도커데몬에 진입한 후 docker ps 해보면 minikube 내에서 많은 컨테이너들이 실행중인 것을 확인할 수 있다.

 

참고: https://codingbee.net/tutorials/kubernetes/using-docker-with-minikube

 

Using Docker with Minikube

The kubecluster running inside the minikube vm actually uses Docker to run all the containers. So when you create kubernetes objects, e.g. pods, then you can use the docker cli to view the underlying containers that have been created. You might want to do

codingbee.net