쿠버네티스 정리

노요셉·2021년 7월 19일

쿠버네티스 소개

https://bcho.tistory.com/1255?category=731548

파드와 노드 보기

https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/

파드는 언제나 노드 상에서 동작한다.

Namespace

출처: 쿠버네티스 - 완벽한 IT 인프라 구축의 자동화를 위한

Resource: Namespace
리소스가 속한 공간
Rosource: ServiceAccount
포드와 쿠버네티스의 인증을 위한 계정

쿠버네티스에서는 리소스를 모아서 가상적으로 분리하는 네임스페이스라는 기능이 있습니다. 이를 사용하면 하나의 쿠버네티스 클러스터를 여러 프로젝트에서 이용할 수 있습니다. 여러 리소스를 모아서 넣는 폴더와 같은 것이라고 이해하면 좋을 것입니다.
이 네임스페이스에는 롤베이스 권한을 설정할 수 있습니다. 네임스페이스별로 필요한 액세스 권한을 설정하여 이용할 수 있는 사용자를 제한하면 보안성을 높일 수 있습니다.

쿠버네티스에서 동일한 네임스페이스 안에서는 리소스명을 고유하게 해야합니다. 다른 네임스페이스의 경우는 같은 이름의 리소스를 붙일 수 있습니다.

클러스터 안의 네임스페이스 목록을 확인
kubectl get namespace

kubectl 명령에서 --namespace 옵션을 설정하면 지정한 네임스페이스로 관리되는 쿠버네티스 리소스를 확인할 수 있음.
kubectl get pod --namespace kube-system

namespace 옵션을 사용하여 명시적으로 지정하지 않을때는 'default' 네임스페이스에 포함되는 리소스를 조작하게 됩니다.

매니페스트 파일

출처: 쿠버네티스 - 완벽한 IT 인프라 구축의 자동화를 위한

쿠버네티스에서는 선언적 설정을 할때 매니페스트 파일을 사용합니다.
쿠버네티스에서는 클러스터 안에서 움직이는 컨테이너 애플리케이션이나 네트워크 설정, 배치 실행을 하는 잡 등과 같은 리소스를 작성합니다.

이와 같은 리소스의 구체적인 설정 정보는 파일로 관리하는데, 이것이 매니페스트 파일(manifest file)입니다.
Nginx가 움직이는 컨테이너 이미지를 바탕으로 하는 웹 프론트 서버를 클러스터안에서 10개 실행시켜 두고 싶은 설정'을 manifest file에 적어둡니다.

apiVersion: apps/vl
kind: ReplicaSet
metadata:
	name : Webserver
spec:
	replicas: 10
	selector:
		matchLabels:
			app: webfront
	template:
		metadata:
			labels:
				app: webfront
		spec:
			containers:
			- image: nginx
				name: webfront-container
				ports:
					- containerPort: 80

매니페스트 파일을 클러스터에 등록하려면 kubectl 명령을 실행합니다.
$kubectl apply -f webserver.yaml

api-server에게 이 내용을 송신한다.라는 의미입니다.

쿠버네티스 마스터의 API Service는 파일의 내용을 클러스터의 구성 정보인 etcd에 저장합니다. 쿠버네티스는 이 etcd에 기록된 정보를 바탕으로 리소스를 관리합니다.

방금 클러스터에 생성한 리소스들을 삭제하려면 이렇게 하면됩니다.
$kubectl delete -f webserver.yaml

네트워크

포드 안에 컨테이너는 네트워크와 스토리지를 공유한다.
동일한 구성으로 된 포드를 여러 개 작성 - Replica

✍️ 메인 컨테이너에 대해 보조하는 서브 컨테이너를 '사이드카'라고 부른 경우도 있음.

스토리지

ConfigMap

Object

환경변수부터, config파일까지 다 configmap으로 관리할 수 있음.

파일을 통째로 configmap을 만든 다음, 컨테이너에서 사용하는 방법을 알아봄.

ConfigMap 생성

kubectl create cm my-config --from-file=config.file.yaml

ConfigMap 조회

kubectl get cm

ConfingMap 내용 상세 조회

kubectl describe cm/my-config

env 파일로 만들기

key=value 형식에 데이터가 저장된 파일 config-env.yml
kubectl create cm env-config --from-env-file=config.env.yml

env-config 조회

kubectl describe cm/env-config

yaml 선언하기

기존 configmap 삭제
kubectl delete cm/my-config

yml 파일은 configmap 생성하려면 그냥 apply -f를 해버리면 됌.
kubectl apply -f config-map.yml

ConfigMap을 환경변수로 사용하기

ConfigMap에 저장된 내용

...
data:
  hello: world
  ...

apline-env.yaml

apiVersion: v1
kind: Pod
metadata:
  name: apline-env
spec:
  containers:
    - name: alpine
      image: alpine
      command: ["sleep"]
      args: ["100000"]
      env:
        - name: hello
          valueFrom:
            configMapKeyRef:
              name: my-config
              key: hello

Secret

쿠버네티스에서 비밀번호, ssh 인증, tls secret과 같은 보안 정보를 관리하는 방법을 알아봅니다.

쿠버네티스는 ConfigMap과 유사하지만, 보안 정보를 관리하기 위해 Secret을 별도로 제공합니다. ConfigMap과 차이점은 데이터가 base64로 저장된다는 점 말고는 없습니다.

Secret은 암호화되지 않음
"쿠버네티스 아키텍쳐를 보면 모든 상태가 etcd에 저장된다" etcd에 평문으로 저장되기 때문에 누가 마음만 먹으면 유출될 수 있음.
secret를 그냥 사용하지 않고 HashiCorp Vault를 이용한다는가
https://www.44bits.io/ko/keyword/hashicorp
별도의 암호화 모듈을 같이 사용하길 권장

secret생성

kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
generic: secret 종류
secretname: db-user-pass

secret 조회

kubectl get secret

secret 상세조회

kubectl describe secret/db-user-pass

-o yaml 로 상세조회

kubectl get secret/db-user-pass -o yaml

저장된 데이터 base64 decode (복호화)

echo base64encodedstring | base64 --decode

secret을 환경변수로 사용하기

apline-env.yaml

apiVersion: v1
kind: Pod
metadata:
  name: apline-env
spec:
  containers:
    - name: alpine
      image: alpine
      command: ["sleep"]
      args: ["100000"]
      env:
        - name: hello
          valueFrom:
            secretKeyRef:
              name: db-user-pass
              key: username.txt

vault: https://www.vaultproject.io/

kubernetes 쉽게 관리하기

k9s
https://teamsmiley.github.io/2020/06/23/k9s/

초보를 위한 쿠버네티스 안내 서 정리

쿠버네티스 시작하기

컨테이너 오케스트레이션 (1)

쿠버네티스가 무엇인지?
컨테이너부터 컨테이너 오케스트레이션까지 모두 설명 필요.

많은 컨테이너 오케스트레이션 중 왜 쿠버네티스인가?

서버 관리한다는 것 -> 서버의 상태를 관리하기 위한 노력 ( 서버가 죽지 않도록 -> 어떠한 이유로 인해 요청에 대한 응답, 요청에 대한 처리를 하지 못하는 상태로 있는것 )

문서화를 잘해봅시다. -> 문서업데이트나 환경의 차이로 동작하지 않는 경우 허다
Chef, Puppet, ansible 같은 서버 관리 도구 사용
( 도구가 대신해서 서버 관리하기 위한 명령어를 입력하는 방식, 개발자는 설정만 해두면 도구가 대신 일하는 방식 ) -> 도구 자체 사용법 공부, 서버가 늘어나고 인프라 구조가 복잡해지면 도구 사용 난이도 상승
가상머신, 가상머신 하나에 하나의 프로그램만 올리면 충돌날 일도 없고, 필요하면 가상머신 자체를 묶어서 파일로 불러다 쓸 수도 있음. 느리지만 관리도 직관적이지 않지만 좋음.
클라우드 환경에 안맞는 부분과 특정 벤더의 의존성 높아짐

컨테이너 오케스트레이션 (2) ( 도커의 등장 )

도커 등장 -> 모든 실행환경을 컨테이너로! 어디서든 동작하고 쉽고 효율적임, 사용법 쉽고, 빠르기까지

컨테이너 특징

가상머신과 비교하여 컨테이너 생성 쉽고
컨테이너 이미지를 이용한 배포와 롤백이 간단
언어나 프레임워크에 상관없이 애플리케이션을 동일한 방식으로 관리
개발, 테스팅, 운영 환경은 물론 로컬 PC, 클라우드까지 동일한 환경 구축
특정 클라우드 벤더에 종속적이지 않음 ( AWS에서 쓰던 설정을 GCP나 AZURE에서 사용가능 )

모든걸 컨테이너로 사용하게 됌.
기존에는 local pc에서 설치해서 사용했던 도구,라이브러리 등 머신에 설치했던 모든 것들을 컨테이너 내부에 설치

프로그램을 컨테이너화해서 사용하는것 : containerization

mysql, redis, rabbitmq, jenkins, wordpress...

개발, 배포하는 과정이 정형화됌.

개발 -> 빌드(도커 이미지 만들기) -> ship(원격 스토리지에 이미지 저장) -> 실행 (도커이미지를 컨테이너로 실행)

모든걸 컨테이너로 만들기 시작.
컨테이너 개수가 수십개에서 수천개까지 되면.. 관리가능?

컨테이너 오케스트레이션 (3)

컨테이너 기술은 좋음. 어떻게 배포하는게 좋을까?

docker container 3개.
각각 서버에 ssh 접속해서 docker stop app && docker run...

어느 서버에 docker를 실행할지도 직접 관리 ( 모니터링 도구를 만들거나, 누가 만든걸 사용해서 관리 )

그리고 v1으로 배포된 서비스에 새로운 기능이 추가되서 v2로 배포하게 된다면? 하나하나 접속해서 배포하게 됌.
배포된 v2에 문제가 생겨서 v1로 롤백을 하게 된다면? 하나하나 접속해서 배포하게 됌.

중앙에서 모든 컨테이너를 관리하고싶다!

서비스 검색은 어떻게함?
서비스 검색은? 예를 들어,
proxy 서버와 web 서버가 있다고 치자.
web 서버에 부하가 많아서 하나 더 생성하게 됌.
그러면 어떻게 해야함? 단순하게 생각해보면
중간에 loadBalancer를 설치해서 loadBalancer에게 web 서버의 ip를 알려줘서 부하를 분산시킴

로드밸런서 설치
서버 생성
ip 업데이트
이런 작업들이 "서비스 검색"

참고: 프록시 서버의 사용목적 - https://liveyourit.tistory.com/251

그러면 서비스 노출(Gateway)은 어떻게 할까? 가장 쉽게
public 영역의 nginx같은 프록시 서버를 하나 두고 요청 host에 따라 내부 비공개 망의 컨테이너를 연결해줄 수 있습니다.

내부 방에 도메인 등록해서 컨테이너 연결해주세요 하면 nginx 설정을 바꾸면 되는데... 귀찮음
자동으로 안됌?

서비스 이상, 부하 모니터링은 어떻게 함?
서비스 이상이 생겨서 서버가 죽거나 그러면 일일이 vm에 ssh접속해서 로그를 보고 다시 컨테이너를 띄움

서비스에 부하가 많아서 컨테이너 개수를 늘려줘야하면 직접 vm 생성하거나 비어있는 vm에 컨테이너 올려서 loadbalancer 등록하고 ...

자동화안될까요?
이렇게 복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구! - 컨테이너 오케스트레이션

컨테이너 오케스트레이션 (4)

서버관리자를 대신해줄 프로그램을 만든것!

컨테이너 오케스트레이션의 특징

cluster
- Node1,2,3 이 있다고 가정합시다. 서로다른 cpu, memory 등 리소스를 갖고있는.. VM ( VM에 NODE가 여러개일수도..)이라고 가정합시다. 개발자가 리소스들까지 다 관리
- Node의 개수가 10개를 넘어가면 관리가 어려우니 컨테이너 오케스트레이션에서는 cluster단위로 추상화해서 관리합니다.
- cluster에 Node들에 ssh로 직접 접근해서 관리하기가 어렵기 때문에 Master Server를 두고 관리자는 마스터 서버 명령을 하면 Master server가 알아서 node에 명령을 보냄
- cluster 내에 Node들끼리는 네트워크 통신이 잘 되야합니다.
- cluster 내에 Node의 개수가 수만개가 되도 잘 돌아야합니다.

마스터와 워커노드
여태껏 얘기했던 노드가 워커노드입니다.

출처: https://www.comworld.co.kr/news/articleView.html?idxno=49737

노드가 일반적으로 클라우드 컴퓨팅 엔진,VM인가요?
출처 : https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/

state (상태관리)
쿠버네티스는 설정한 상태를 유지해서 애플리케이션을 구성해줍니다.

{
  image: "app1",
  replicas: 2
}

이러면 app1 이미지의 컨테이너가 2개 생성됩니다.

{
  image: "app1",
  replicas: 3
}

이러면 app1 이미지의 컨테이너가 3개 생성됩니다.

컨테이너가 3개인데, 하나가 문제가 생겨요. 다시 띄워주는거까지 상태관리 ( 모든일이 서버관리자가 했어야할일, 모니터링하고, 다시 띄워주고..)

Schedule (배포관리)
컨테이너를 배포하고 싶은데, 어떤 노드에 얼만큼 여유가 있어서 띄우려는 컨테이너를 해당 노드에 배포하거나, 새로운 노드를 생성해서 배포할지도 쿠버네티스가 합니다.
rollout, rollback
배포 버전관리
{ version: "v1.0.0"}
Rollout
{ version: "v1.1.0"}
Rollback
{ version: "v1.0.0"}

이러한 동작을 했을때 서버관리자가 일일이 해야하는 일을 쿠버네티스가 합니다.

service discovery ( 서비스 등록 및 조회 )
프록시 서버가 보통 있겠죠. 프록시서버에 서비스 등록하고 ( 설정변경) 프로세스 재시작 등
쿠버네티스가 설정파일에 맞게 노드를 관찰하고 컨테이너 추가 삭제시 알아서 프록시서버에 설정을 바꿔주고 합니다.
volume 스토리지 기능
node 1,2,3이 있으면 각 노드에 서로다른 파일시스템을 마운트 할 수 있어요. 이런 상황이 있을 수 있는데, 일일이 할 수 있으나 설정파일로 추상적으로 관리하면 더 좋겠죠. 이것도 컨테이너 오케스트레이션의 역할입니다.

컨테이너 오케스트레이션은 개념! concept!
이 개념을 자유롭게 구현가능

deis, rancher, hashicorp nomad, mesos, docker swarm...

왜 쿠버네티스인가?

쿠버네티스 쉽고 빠르게 배포/확장하고 관리를 자동화해주는 오픈소스 플랫폼
구글에서 만들었고요.
1주일에 20억개의 컨테이너를 생성하는 google이 컨테이너 배포시스템으로 사용하던 Borg를 기반으로 만든 오픈소스 v1.0 release(2015)

CLOUD NATIVE라는 오픈소스 단체로 소스 이관 -> 완전히 오픈소스

production-grade container orchestration
planet scale
never outgrow? 다양한 요구사항을 만족시킬 유연함?
run anywhere

오픈소스!, 커뮤니티!, 인기!, 무한한 확장성!
사실상 표준 (de facto)
클라우드 3사에서 지원..

쿠버네티스 사용에 도움이 되는 url:
쿠버네티스 공식문서 - https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/
쿠버네티스 시작하기 - Kubernetes란 무엇인가? SERIES 1/2

https://subicura.com/2019/05/19/kubernetes-basic-1.html
조대협 블로그 - https://bcho.tistory.com/1255

노요셉

서로 아는 것들을 공유해요~

이전 포스트

tty

다음 포스트