'MASTER'에 해당하는 글 6건

Kubernetes Architecture

Tool/Kubernetes 2019. 4. 23. 21:58



Master


위 그림은 쿠버네티스 클러스터의 아키텍처이다. 좌측의 마스터 컴포넌트는 클러스터의 제어영역(control plane) 을 제공하여, 클러스터에 관한 전반적인 결정을 수행하고 클러스터 이벤트를 감지하고 반응한다. 마스터 컴포넌트는 클러스터 내에 어떤 노드에서든 동작할 수 있지만, 일반적으로 클러스터와 동일한 노드 상에서 구동시킨다. 아래는 마스터 내에서 동작하는 바이너리 컴포넌트들이며 쿠버네티스 초기화시 자동 설치된다.


kube-apiserver

쿠버네티스 API 로, 외부/내부에서 관리자의 원격 명령을 받을 수 있는 컴포넌트이다.


etcd

모든 클러스터 데이터를 저장하는 고가용성 키-값 저장소로, etcd 데이터에 대한 백업 계획은 필수이다.


kube-scheduler

생성된 파드를 노드에 할당해 주는 컴포넌트이다. 이것을 스케줄링이라 하며, 리소스/하드웨어/소프트웨어/정책/워크로드 등을 모두 참고하여 가장 최적화된 노드에 파드를 배치하게 될 것이다.


kube-controller-manager

아래의 컨트롤러들을 구동하는 컴포넌트이다.

- Node Controller : 노드가 다운되었을 때 알림와 대응에 관한 역할을 한다.

- Replication Controller : 지정된 수의 파드들을 유지시켜 주는 역할을 한다.

- Endpoints Controller: 서비스와 파드를 연결시켜 엔드포인트 오브젝트를 만든다.

- Service Account & Token Controllers: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.



Node


우측 하단의 노드 컴포넌트(Minions) 는 마스터 컴포넌트에 의해 관리되며 VM 이나 물리 장치가 될 수 있다. 동작중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공한다. 아래는 노드 내에서 동작하는 바이너리 컴포넌트들이며 노드 오브젝트 생성시 자동 설치된다.


kubelet

클러스터의 각 노드에서 실행되는 에이전트로, 컨테이너들이 파드에서 실행 중인지, 이상이 없는지 확인한다.


kube-proxy

호스트 상의 네트워크 규칙으로 커넥션 포워딩을 수행함으로서 쿠버네티스 Service 가 가능하도록 한다.


Container Runtime

컨테이너 런타임은 컨테이너의 동작을 책임지며, 쿠버네티스에서 지원하는 컨테이너 런타임은 다음과 같다. 

Docker, containerd, cri-o, rktlet, Kubernetes CRI (Container Runtime Interface) 구현체.



저작자표시 비영리 변경금지
WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.
,

minikube start

Tool/Kubernetes 2019. 3. 26. 00:20

빠르게(?) 쿠버네티스를 접해 볼 수 있는 minikube 를 간단(?)하게 설치하고 시작해 봤다. minikube 의 시작은 minikube start 였다. 이 minikube start 명령이 한 일은 바로 쿠버네티스 클러스터 생성과 마스터 구성 인데, 그 과정에서 얼마나 많은 일들을 사용자 대신 해줬는지 로그를 보며 살펴보자. 


# minikube start --vm-driver=none

o   minikube v0.35.0 on linux (amd64)

>   Configuring local host environment ...


           ... 생략 ...


i   This can also be done automatically by setting the env var CHANGE_MINIKUBE_NONE_USER=true

>   Creating none VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...

-   "minikube" IP address is 10.0.1.111

-   Configuring Docker as the container runtime ...

-   Preparing Kubernetes environment ...

@   Downloading kubeadm v1.13.4

@   Downloading kubelet v1.13.4

-   Pulling images required by Kubernetes v1.13.4 ...

-   Launching Kubernetes v1.13.4 using kubeadm ...

:   Waiting for pods: apiserver proxy etcd scheduler controller addon-manager dns

-   Configuring cluster permissions ...

-   Verifying component health .....

+   kubectl is now configured to use "minikube"

i   For best results, install kubectl: https://kubernetes.io/docs/tasks/tools/install-kubectl/

=   Done! Thank you for using minikube!



  1. VM 이든 none VM 이든 2CPU, 2GB 메모리, 20GB 디스크의 가상 node 생성.
  2. 컨텍스트(minikube) 를 생성하여 ip 를 할당하고, 컨테이너 런타임으로 docker 구성.
  3. docker 에서 쿠버네티스 이미지를 받고, Master node 측 도구인 kubeadm, kubelet 을 다운받아 kubeadm 으로 클러스터를 생성.
  4. Master 및 각종 pod 컨테이너 구성 : apiserver, proxy, etcd, scheduler, controller, addon-manager, dns
  5. 컴포넌트 상태 체크.
  6. 클러스터과 사용자가 통신할 수 있도록 kubectl 를 구성. (no VM 환경에서는 직접 다운로드)





클러스터를 하나 생성하는데 이렇게 많은 작업들이 필요하다. minikube 로 인해 대부분 자동으로 세팅이 되었지만 나중에 쿠버네티스를 사용할 때는 노드스펙, 네트워크, 디스크, 각종도구 설치, 클러스터 생성 등을 모두 직접 설정해야 한다. 이제 정말 서론은 끝났다. 다음은 진짜 쿠버네티스를 경험할 차례!



WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.
,

쿠버네티스의 생김새

Tool/Kubernetes 2019. 3. 19. 21:55

쿠버네티스는 어디부터 시작해야 할까? 쿠버네티스 이론과 플러스로 특정 클라우드 서비스의 이론, 오픈 소스인데 무료로는 쉽게 접할 수 없을 것 같은 무시무시함, 그 시작점도 여러가지, 솔루션도 여러가지라 시작하는 것부터가 고민이다. 일단 쿠버네티스를 접할 수 있는 방법은 다음과 같이 무궁무진하다.


1. 로컬 장치 솔루션 : PC 나 노트북 등에 쿠버네티스 경량 버전을 설치하고 스피드하게 쿠버네티스 접해보기.(무료!)

2. 호스티드 솔루션 : 쿠버네티스를 설치 없이 즉시 사용할 수 있는 클라우드 솔루션.(gke, eks)

3. 턴키 클라우드 솔루션 : gce 나 ec2 같은 클라우드 컴퓨터에서 클러스터 관리 등 편리한 쿠버네티스 운영을 위한 솔루션.

4. 그 외 클라우드 공급자와 베어메탈 환경, 많은 운영체제에서의 특수조합 솔루션과 사용자 정의 솔루션.


일일이 나열하지는 않았지만 보자마자 꺼버리고 싶을 정도로 다양한 솔루션들. 난 단지 쿠버네티스를 설치하고 테스트 해보고 싶을 뿐인데, 뭐라뭐라~~~ 간단하지는 않겠지만 하고자 한다면 원하는 플랫폼에서 원하는 수준으로 쿠버네티스 솔루션 사용이 가능하다. 특정 클라우드나/서버/OS 에 따라 설치방법이과 설정이 조금씩 다르나, 클러스터 생성 - 앱 배포 - 스케일링 - 업데이트 등의 쿠버네티스의 흐름은 모두 동일하다. 부담없는 무료버전을 빠르게 설치해서 쿠버네티스 명령과 동작 좀 익히고, 중간에 시간 좀 남으면 서버에 직접 설치도 해보고, 그러다가 호스티드 솔루션으로 자연스럽게 넘어가서 운영을 할 수 있을 정도가 되어보려 한다.


시작부터 난관에 빠지긴 했지만... 설치전에 쿠버네티스가 어떻게 생겼는지를 먼저 보는게 좋겠다.



요롷게 생겼다. 어떤 솔루션이든 쿠버네티스가 설치되어 있다면, 가장 먼저 클러스터라는 공간을 생성해 주어야 하며, 그 안에는 마스터 노드(Master) 와 워커 노드(Node) 를 생성할 수 있다. 마스터는 클러스터 내에 발생하는 모든 요청들을 담당하는 중추적인 역할을 하며 하나의 클러스터에 한 개만 있으면 된다. 노드는 클러스터에 따라 물리적인 컴퓨터나 가상머신(VM) 등의 장치가 된다. 앱이 구동될 공간이며, 하나의 클러스터에 여러 개를 생성할 수 있다. 모든 준비를 마친 후 앱을 배포하도록 Master 에 지시하면 적당한 Node 에서 앱을 구동하게 될 것이다. 겉보기는 저게 다다. 이렇게 보니까 되게 쉬워 보인다. 자신감+1.


다음은 로컬 장치 솔루션 사용해 보기!



저작자표시
WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.
,

pull scenario

Tool/Git 2013. 3. 28. 01:37

원격 저장소의 작업물을 로컬 저장소로 복제하기 위해 clone 을 사용했지만,
이 후 원격 저장소의 변경된 작업물을 가져오기 위해서는 pull 이나 fetch 명령을 사용해야 합니다.
fetch 명령은 원격 저장소의 변경된 작업물(obj, ref, tag)만을 가져옵니다.
pull 명령은 fetch + merge 를 실행하는 것과 동일한 결과를 보여 줍니다.

 

만약 로컬의 master 와 원격의 master(origin/master) 가 각각 다른 commit을 진행중일 때,
merge를 원한다면 pull 명령을, 단지 origin/master 만 update 하길 원한다면 fetch 를 사용하면 되겠습니다.

 

우선 clone 으로 동기화한 후의 fetch 명령은 이미 remote branch 세팅이 끝난 상태이므로 패스하고,
초기화(init)된 상태에서 fetch 와 merge, origin/master 추적을 사용해 보겠습니다.

 

 

 

git fetch <repo> <refspec>

 

$ git init
$ git remote add origin git@github.com:ggamzzak/test.git
$ git fetch origin
From github.com:ggamzzak/test
 * [new branch]      b2         -> origin/b2
 * [new branch]      master     -> origin/master

 

remote branch 가 생성되었습니다.
이제 merge를 사용하여 로컬 origin/master 에 master HEAD 를 놓습니다.

 

$ git merge origin/master

 

* refspec 이란 것은 간략하게 <src branch>:<dest branch> 라고 보면 되겠습니다.

 

 

 

git pull <repo> <refspec>

 

$ git init
$ git remote add origin git@github.com:ggamzzak/test.git
$ git pull origin
Enter passphrase for key '/home/oops4u/.ssh/id_rsa':
From github.com:ggamzzak/test
 * [new branch]      b2         -> origin/b2
 * [new branch]      master     -> origin/master
You asked to pull from the remote 'origin', but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line.
$ git checkout -B master origin/master
Branch master set up to track remote branch master from origin.
Reset branch 'master'
$ git pull origin
Already up-to-date.

 

fetch와 merge를 사용한 결과는 pull 명령을 사용한 것과 동일합니다.
동일하다고는 하였지만, 원격 저장소 주소만 추가한 상태에서 branch 를 명시하지 않으면,
merge할 branch를 지정하라는 메시지를 출력합니다.
이 때 master 를 reset 하여 origin/master 를 추적하도록 합니다.
그리고 나면 pull 명령에 branch 를 생략해도 master->master 로 가져오게 됩니다.

저작자표시
WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.
,

git commit

Tool/Git 2013. 3. 22. 01:09

4. commit 후의 status

 

상태(status) 확인 후 원하는 작업물이 Staged 상태가 되었는지 확인이 되었으면,
commit 명령을 사용하여 작업물을 Staged -> HEAD 상태로 놓습니다.
-m(message) 옵션을 사용하여 인라인 메시지를 작성할 수 있습니다.

 

$ git commit -m 'first file added'
[master (root-commit) 28713ce] first file added
 1 file changed, 1 insertion(+)
 create mode 100644 file1.txt
$ git branch
* master
$ git status
# On branch master
nothing to commit, working directory clean

 

master branch에 커밋이 되었고 작업 현황을 보여줍니다.
그리고 현재의 branch가 master로 출력되었습니다. 첫번째 커밋과 동시에 master branch가 생성이 되었습니다.
commit 후에 status를 확인해 보니, commit 할 것이 아무것도 없다는 메시지가 출력됩니다.

 

 

 

5. tracked file 수정

 

commit 할 것이 없는 상태에서 다시 파일을 생성하던지, 기존 파일을 수정하면 다시 상태가 바뀌게 됩니다.
파일 생성은 실행해 보았으니 tracked(버전 관리 대상)된 기존 파일을 수정해 보겠습니다.

 

$ cat >> file1.txt
test
$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   file1.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

 

수정할 파일을 HEAD 단계에 놓으려면 처음처럼 add 명령으로 Staged 상태에 놓은 후 commit 하면 됩니다.
수정한 파일을 add 명령으로 Staged 상태에 놓은 뒤 커밋 전에 다시 그 파일을 수정하면 어떻게 될까요?
그 상태로 commit을 한다면 Staged 상태였던 파일의 내용이 그대로 HEAD로 올라가고,
두 번째 수정한 내용은 아무 곳에도 반영되지 않습니다.
add 후에 파일을 다시 수정했다면 add 명령을 다시 실행하여 Stage area에 반영해야 합니다.
tracked 파일에 한해서 commit -a 옵션을 사용하면 git add, git commit 을 한 번에 실행해 줍니다.

 

 

지금까지는 모두 로컬 저장소(Local Repository) 안에서의 작업이었습니다.
아직 원격 저장소(Remote Repository)는 변한게 없다는 사실...

저작자표시
WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.
,