By oneself

1. 공홈에서 제공하는 docker install 사용

docker run --detach \

    --hostname gitlab.example.com \

    --publish 443:443 --publish 80:80 --publish 22:22 \

    --name gitlab \

    --restart always \

    --volume $GITLAB_HOME/config:/etc/gitlab:Z \

    --volume $GITLAB_HOME/logs:/var/log/gitlab:Z \

    --volume $GITLAB_HOME/data:/var/opt/gitlab:Z \

    gitlab/gitlab-ee:latest

2. 해당 포트로 접속

3. runner를 설치해야 gitlab ci를 사용할 수 있음. (다음시간에)

* runner는 VM에 설치할 수도 있고, 쿠버네티스에 pod로 기동시킬수도 있으며, 쉐어해서 사용이 가능하다, gitlab-ci.yml을 통해 사용가능.

1. 공홈에서 제공하는 docker 명령어 사용

docker run -it --name teamcity-server-instance \
-v <path to data directory>:/data/teamcity_server/datadir \
-v <path to logs directory>:/opt/teamcity/logs \
-p <port on host>:8111 \
jetbrains/teamcity-server

2. 몇가지 동의를 하면 아래와 같이 로그인 페이지가 뜬다.

3. 가입이 필요해서 패스함

< jenkins docker 설치 >

1. docker run -d --restart=always --name jenkins -p 8080:8080 -v $PWD/jenkins:/var/jenkins_home jenkins/jenkins

2. 해당 포트로 웹 접속 후 cat /var/jenkins_home/secrets/initialAdminPassword 경로에 있는 Password값 입력

3. 아래와 같이 추천플러그인 or 선택플러그인 설치하면 셋팅중인 화면을 볼 수 있음

4. jenkins main화면 

5. jenkins 관리화면

6. jira, confluence, keycloak 등 1,800개 이상의 플러그인 제공

https://leedongju.tistory.com/category/Devops

글에 대해서 좀 더 쉽게 풀어써보려고 한다.

마스터노드에는 4가지 큰 역할이 있다고 했다.

1. 스케줄러

한마디로 하면 애플리케이션을 적절한 곳에 디플로이하는 장치를 스케쥴링이라고 한다.

컨트롤 플레인에 위치한다. 워커 노드에 디플로이!

만약 적합한 노드가 없으면 스케줄러가 배치할 수 있을 때까지 pod가 스케줄되지 않은 상태로 유지한다.

요구사항들은 매니페스트 파일로 정의한다. 

쿠버네티스 문서에 의하면 kube-scheduler는 2단계 작업으로 pod를 어떤 노드에 생성할지 선택한다.

1. Filtering

2. Scoring

Filtering step에서는 PodFitsResources 필터는 노드들에 리소스가 충분한지를 필터링한다. 

Scoring  step에서는 각 노드들에 순위를 매긴다. 같은 순위인 경우 임의로 하나를 선택한다.

2. API Server

쿠버네티스의 리소스 정보를 관리하기 위한 프론트엔드 REST API이다 .

각 컴포넌트들로부터 받은 리소스정보들을 etcd에 저장한다. 이렇게 저장된 데이터들을 다른 컴포넌트들이 API Server를 통해 액세스한다.

인증,인가의 기능들도 가지고 있다.

3.Controller Manager

앞에서 설명한거와 같이 클러스터들의 상태를 감시하고 원래 되어야 할 상태를 유지하는 백엔드 컴포넌트이다.

4. etcd

분산 key-value-store이다 ( KVS) 

어떤 pod를 어떻게 배치할지와 같은 정보들을 가지고 있어 API Server가 참조한다. 

또한 마스터 노드에서 분리시킬수도 있다.

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/principles.md

에 의하면

1. api server만이 etcd/store와 통신해야하고 다른 컴포넌트 ( 스케줄러, kubelet 등)와는 통신하면 안된다.

2. 단일노드가 손상되어도 클러스터 자체를 손상시키면 안된다.

3. 컴포넌트는 최신 지시를 잃어버려도 가장 최근 지시를 바탕으로 내용을 계속 수행해야 한다.

4. 모든 컴포넌트들은 항상 모든 관련 상태들을 메모리에 유지해야한다. 

5. API server에 폴링하는 방법이 아니라 각 컴포넌드틀이 watch해야한다

라는 설계 지침들이 있으니 보는것도 좋다.

이번 주말에 직접 서버에 쿠버를 설치하고 명령어까지 이미지로 업데이트 할 계획이다,

* 해당 내용들은 https://kubernetes.io/ 및 구글링을 통해 정리한 내용입니다.

쿠버네티스를 배포하면 클러스터를 얻으며, 컨테이너화 된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합니다. 모든 클러스터는 한개 이상의 워커 노드를 가지게 된다.

노드는 관리역할을 하는 master plane 과 실질적인 작업들을 하는 Worker nodes로 나누어 진다.

위를 보면 마스터가 있고, 여러 worker node들이 있다. 마스터는 여러개가 될 수도 있다.

쿠버네티스 master와 kubelet 프로세스와 같은 쿠버네티스 control plane의 다양한 구성 요소는 쿠버네티스가 클러스터와 통신하는 방식을 관장한다. control plane은 시스템 내 모든 쿠버네티스 오브젝트의 레코드를 유지하면서, 오브젝트의 상태를 관리하는 제어 루프를 지속적으로 구동시킨다. 

- Kubernetes Master 

응용프로그램 예약, 상태 유지, 확장 및 업데이트와 같은 클러스터의 모든 활동을 조정한다.

kubelctl 커맨트라인 인터페이스와 같은 것을 사용해서 쿠버네티스로 상호 작용할 때에는 쿠버네티스 마스터와 통신하고 있는 것이다. 가용성과 중복을 위해 복제될 수도 있다

리눅스 os만 가능하다.

  > API Server : 클러스터와의 모든 상호작용은 Kubernetes API 호출을 통해 수행된다. HTTP를 통해 또는 Kubectl 및 Kubernetes UI의                          명령을 통해 실행될 수 있다.

                       사용자 > kubectl명령어 > API Server > cAdvisor > Kubelet > container Engine 

  > Scheduler : pod를 배치할 노드를 선택한다.

  > Controller : 

      1) 노드 컨트롤러 : 노드 장애시에 대해서 반응 및 대응을 한다.

      2) 레플리케이션 컨트롤러 : 올바른 개수의 pod를 유지하고 관리한다.

      3) 엔드포인트 컨트롤러 : 서비스 및 pod를 연결하는 엔드포인트 오브젝트를 채운다.

      4) 서비스 컨트롤러 : 클라우드 제공 사업자의 로드밸런서를 생성, 업데이트, 삭제를 한다.

  > etcd : 모든 클러스터 데이터를 담는 저장소역할을 하며 일관성, 고가용성을 위해 key -Value형태이다. 

               AWS에서 kubernetes 를 사용하는 경우 EBS볼륨의 스냅샷을 만들어 etcd를 백업 할 수도 있다.

               go 언어로 만들어 졌으며 Raft합의 알고리즘을 사용하여 고가용성 복제 로그를 관리한다.

- Workder Node

 클러스터 내 노드는 애플리케이션과 클라우드 워크플로우를 구동시키는 머신이다. 또한 worker node끼리 통신할 일이 많지가 않다. 

 리눅스,윈도우 os가 가능하다.

  > kubelet : 클러스터의 각 노드에서 실행되는 에이전트로, pod에서 컨테이너가 확실하게 동작하도록 관리한다.

                 PodSpec의 집합을 받아서 컨테이너가 해당 pod spec에 따라 건강하게 동작하는지를 관장한다.

                 쿠버네티스를 통해 생성되지 않은 컨테이너는 관리하지 않는다.

                 즉, pod들과 Node들의 상태를 클러스터에 보고하는 역할을 한다.또한 Master와 통신한다.

  > kube-proxy : 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 서비스 개념의 구현부이다.

                      즉, 서비스로 향하는 트래픽( 클러스터 IP or Node port를 통해)을 올바른 백엔드 pod로 로드밸런싱한다.                                                   userspace,iptables, IPCS로 구현 된 세가지 모드 중 하나에서 실행될 수 있다.  

     추가적인 설명: https://www.tigera.io/blog/comparing-kube-proxy-modes-iptables-or-ipvs/ 

  > container runtime : 컨테이너 실행을 담당하는 소프트웨어이다.