Hae-Riri
commented
3 years ago 쿠버네티스 용어들 헷갈려서 내가 보려고 써 두는 구조...ㅎㅎ
쿠버네티스 overview
쿠버네티스는 서버 한 대를 master로 쓰고 여기에 Node 라고 하는 여러 서버들이 연결된다. 이렇게 연결이 되면 하나의 쿠버네티스 클러스터 가 된다.
- master
- 쿠버네티스의 기능을 전반적으로 컨트롤하는 역할
- Node
- 자원을 제공하는 역할.
- 만약 내가 클러스터 전체의 리소스를 늘리고 싶으면 노드를 늘리면 된다.
- 쿠버네티스 클러스터 안에는 두 개의 namespace 가 있는데 이게 쿠버네티스 오브젝트들을 독립된 공간으로 분리되게 만들어준다.
- 네임스페이스에는 쿠버네티스 최소 배포 단위인 파드(Pod)들이 있고 이 파드들에게 외부로부터 연결이 가능하도록 ip를 할당해주는 서비스가 있어서 [서비스 - 파드들]을 연결할 수 있는데, 서로 다른 네임스페이스에 있는 파드와는 연결할 수 없다.
- 파드 안에는 여러 개의 컨테이너가 들어감.
- 컨테이너 하나 당 하나의 앱이 동작하기 때문에 결국 파드에는 여러 앱이 돌아갈 수 있다.
- 근데 파드에 문제가 생겨서 재생성이 되면 그 안에 있는 데이터가 날라간다.
- 그래서 볼륨을 만들어서 파드에 연결하면 데이터는 이곳에 별도에 저장할 수 있으니까 파드가 재생성되면서 데이터가 날아가는 문제를 해결할 수 있다.
- 네임스페이스에 resourceQuata / LimitRange를 달아서 한 네임스페이스에 들어갈 수 있는 리소스의 양을 한정할 수 있다. 파드의 개수를 제한하거나 cpu 나 메모리를 제한하기도 하고.
- 파드 생성 시에 컨테이너 안에 환경변수 값을 넣어준다거나 파일을 마운팅해줄 수 있는데 configMap / Secret 을 통해 세팅할 수 있다.
- 컨트롤러가 파드들을 관리하는 역할을 하는데 이 컨트롤러의 종류가 좀 많음. 각각 용도가 있음.
- Replication Controller, ReplicaSet : 파드가 죽으면 다시 살려준다든지 파드의 개수를 늘렸다가 줄이는 scale in out 가능
- Deployment는 배포 후에 파드들을 새 버전으로 업그레이드 해줌. 업그레이드 하다가 문제 생기면 롤백을 쉽게 하도록 도와줌.
- DaemonSet은 한 노드에 파드가 하나씩만 유지되게 해줌. 이렇게 사용해야 하는 노드가 있음. 나중에 나올거임!
- Job은 특정 작업만 하는 종료시켜야 할 때, 파드가 그렇게 동작하게 함. 이런 job들을 주기적으로 동작시켜야 할 때는 CronJob을 사용한다.
컨테이너
node.js 기반의 프로그램을 실행시키려 할때 일반 로컬에서 한다면 node.js 설치해서 동작시키면 됨. 근데 이걸 컨테이너에서 만들고 싶다면?!
# cat > Dockerfile
FROM node:12
COPY app.js/app.js
ENTRY POINT ["node", "app.js"]node:12라고 태그 버전을 만들고, 미리 만든 app.js 소스코드를 안에 복사하면 아래와 같은 컨테이너가 됨.
미리 node:12라는 환경을 만든 다음에 거기에 app.js를 넣은 구조임.
근데 이걸 그냥 두면 안되고 누군가가 컨테이너를 실행하면 이게 자동으로 실행되게 만들어야겠지? 그 부분이 ENTRYPOINT ["node", "app.js"]임.
컨테이너 이미지
이제 이렇게 만들어진 컨테이너를 어떻게 동작시킬 수 있을까. 그걸 동작시킬 플랫폼이 필요한데 그 중 많이 쓰이는 게 도커임. rocket이라는 것도 있음.
도커에 컨테이너 빌드
- 허브
- 컨테이너를 저장하는 창고. hub.docker.com도 있고 사내에서 private 하게 운영하기도 함.
- 어쨌든 우리는 컨테이너를 빌드해서 허브에 push할거임.
- 앞에 있던 docker file과 app.js 파일을 빌드하자. 컨테이너 이름으로
docker build -t smlinux/nodeinfo:v1 //빌드 docker push smlinux/nodeinfo:v1 // push docker images
이제 허브에 push 됐음. 허브에 저장된 수많은 컨테이너를 써보자.
허브에 저장된 컨테이너를 어떻게 쓸까
- 인터넷으로 허브와 연결이 가능한 리눅스 운영체제가 있음.
- 여기에 도커 플랫폼을 둠.
- 도커 커맨드를 실행해서 우리가 만들어놓은 컨테이너를 다운 받음.
$docker pull smlinux/nodeinfo:v1 - 다운 받은 컨테이너를 실행시켜주면 도커 플랫폼에 컨테이너가 동작됨.
$ docker create --nae app -p 80:8080 smlinx/nodeinfo:v1 $ docker start app
이제 8080 포트를 열고 클라이언트 커넥션을 listen하게 됨.
근데 여기서 -p를 통해 외부 80으로 들어오면 8080으로 연결해주었으므로 클라이언트 사용자가 10.100.0.104:80으로 접속하면 여기서 컨테이너의 호스트네임을 받게 됨.
가상머신과 컨테이너의 차이는 아니까 넘어감
쿠버네티스의 등장
도커로 세 개의 웹서버를 운영하고 있었는데 시스템 전체가 다운되면 어떻게 할까? 큰일나지?
그래서 멀티 호스트 도커 플랫폼을 만들게 됨.
시스템 하나에 도커를 운영하는게 불안하니까 되도록 분산해서.
컨테이너 오케스트레이션
이걸 근데 어느 도커에 어떤 컨테이너를 놓을지 누가 배치할까? 개발자가 하기엔 너무 번거롭다. 마치 오케스트라에서 지휘자가 이 음악에 잘 맞게 소리를 배치하는 것처럼, 컨테이너 오케스트레이션을 하자.
웹서버, 파이썬, node.js 등의 어플리케이션들을 아래 예시처럼 워커 노드 2개에 배치할거야. 누가? 지휘자가!
여기서의 지휘자는 control plane 이다. 한쪽 도커가 다운되면 거기에 있던 어플리케이션을 옮기기도 하고 적당히 배치하기도 하고.
컨테이너 계층 구조
이런 지휘를 쿠버네티스가 해줌.
Mono (reactor publisher), fromFuture? webClient (armeria client) .execute, .aggregate, awaitSingle(coroutine)
braveClient( armeria.client.brave) ClientOption(armeria), factory ClientFactory(armeria) contentUtf8 jacksonObjectMapper(kotlin)
zipkinTracingDecorator
grpc interceptor kotlin(apply, as, let, ...) armeria(webClient) coroutine