Logo SugnwooKim's place
Logo Inverted Logo
  • Posts
  • Books
  • CKA
  • Think
Hero Image
2-10 Replicasets

Replication controller 만약 우리가 pod 하나를 운영하고 있다고 가정해보자. 만약 해당 pod가 죽어서 접근이 불가능해지면 어떻게 될까? 사용자들이 접근을 하지 못하게 될 것이고 다른 pod가 실행 되어야할 것이다. 이렇게 다른

July 14, 2021 Read
Hero Image
2-9 Pods With Yaml

Kubernetes yaml 형식 apiVersion: kind: metadata: spec: 일반적인 yaml형식은 위와같다. apiVersion: 사용하려는 오브젝트에 따라 다르게 기술된다. 대표적인 예시는 다음과 같다. kind Version Pod v1 Service v1 ReplicaSet apps/v1 Deployment apps/v1 kind: 생성할 오브젝트의 타입을 지정한다. 여기에서는 pod를 만들거기에 pod라 기술한다. 위 표에서 왼쪽 필드에 있는 오브젝트들이 여기에 해당한다. metadata: 위에서 소개된 2가지와는 다르게 string 타입이 아닌 dictionary타입이 기술된다.

June 24, 2021 Read
Hero Image
2-8 Pod

Pod 쿠버네티스는 컨테이너를 노드에서 바로 배포하지않는다. 컨테이너들은 pod라고 알려진 단위로 캡슐화되어 배포한다. 이 pod는 쿠버네티스에서 가장 작은 단위를 의미한다. Pod가 인스턴스가 되어 생성될 때, 같은 컨테이너를 더 배포하고 싶다면 어떻게 할까? pod안에 공간을 늘리는게 아닌 새로은 pod를 생성한다. 그래서 이 pod들을 생성할 수도 있고, 제거할 수도 있다. 보통 pod는 한개의 컨테이너와 관계를 맺는다. 하지만 사실 pod는 여러 컨테이너를 가지는 단위가 될 수도 있다. 만약 컨테이너를 배포할 때 helper conatiner라고 불리는 앱 배포를 위한 다른 컨테이너가 필요할 때, multi-container pod라 불리는 해당 방법을 사용하기도 한다.

June 24, 2021 Read
Hero Image
2-7 Kube Proxy

Kube proxy 클러스터 내부에서 pod는 다른 pod들과 통신을 할 수 있다. 클러스터 내부의 가상 네트워크를 사용해서 pod들끼리 통신이 가능하다. 만약 웹서비스를 배포하였을 때, 한쪽에는 서비스를 다른 한쪽에는 DB를 배포했다고 하자. 이 때, 서비스는 DB를 사용하기 위해 접속을 시도할텐데 DB의 접속 정보가 언제나 똑같다는 보장이 없다. 그래서 우리는 DB를 사용하기 Service를 생성한다. 서비스는 pod를 사용하기 위해 ip나 이름을 통해 접근할 것이다. 그럼 서비스는 어떻게 pod에 접근하고 사용하는 것일까? 서비스는 실제로 pod가 속한 네트워크에 접속하지는 못한다.

June 24, 2021 Read
Hero Image
2-6 Kubelet

Kubelet Kubelet은 선박들의 함장과 같은 역할을한다. 마스터 노드의 스케쥴러와 통신하며 어떻게 컨테이너들을 실을지 결정하고 배의 상태(Pod들의 상태)를 주기적으로 알려준다. Kube-scheduler에게서 Node 등록에 관한 명령을 받게되면 kubelet은 POD를 생성하고 Conatainer engine(보통 Docker)에 이미지를 실행하고 인스턴스를 생성한다. 그리고 Kubelet은 컨테이너의 상태를 모니터링하고 그에 관한 내용을 kube-api로 보내준다.

June 24, 2021 Read
Hero Image
Modern_java_in_action_part_2

동적 파라미터화 코드 전달하기 동적 파라미터화(Behavior parameterization)을 이용하면 자주 바뀌는 요구사항에 효과적으로 대응할 수 있다. 동적 파라미터란 아직은 어떻게 실핼할 것인지 결정하지 않은 코드 블록을 의미한다. 이 코드 블록은 나중에 프로그램에서 호출한다. 즉, 코드 블록의 실행은 나중으로 미뤄진다. 결과적으로 코드 블록에 따라 메서드의 동작이 파라미터화된다. 변화하는 요구사항에 대응하기 여기에서는 예제를 바탕으로 유연한 코드를 만드는 과정을 보여준다. 해당 예제들을 통해 유연한 코드를 어떻게 작성하였는지 직관적으로 확인할 수 있다. 첫 번째 시도: 녹색 사과 필터링

June 22, 2021 Read
Hero Image
Modern_java_in_action_part_1

Java 8, 9, 10, 11 : 무슨 일이 일어나고 있는가? Java는 객체지향 모델의 언어와 JVM이라는 특성을 살려 빠르게 시장을 장악해 나갔다. 하지만, 프로그래밍 언어 생태계에 변화의 바람이 불기 시작했다. 프로그래머는 테라바이트 이상의 데이터셋에 직면하면서 멀티코어 컴퓨터나 컴퓨팅 클러스터를 이용해서 효과적으로 처리할 필요성이 커졌다. 그외에도 큰 시스템의 설계 방식도 변화의 한 요소로 꼽힌다. 이와 관련해서 Java 8의 밑바탕을 이루는 세 가지 프로그래밍 기법을 소개한다. 스트림 처리 스트림이란 한 번에 한 개씩 만들어지는 연속적인 데이터 항목들의 모임이다.

June 21, 2021 Read
Hero Image
2-5 Kube Scheduler

Kube Secheduler 앞서 이야기했듯이 Kuber scheduler는 노드에 pod에 스케쥴링하는 작업을 담당한다. 여기서 명심해야 할 것은 scheduler는 pod가 어느 노드로 갈지만 결정한다. pod를 생성하는 것과 같은 역할은 kubelet이 담당한다. 좀 더 자세히 말하자면, 다양한 컨테이너들이 노드위에 적재될 때, 각각 다른 사이즈가 존재할 것이다. 사용자는 당연히 좀 더 효율적인 분배를 원할 것이고 이러한 역할을 scheduler가 담당한다. 만약 일정양이 필요한 작업이 있고 노드가 여러개 존재한다면 scheduler는 2가지 작업으로 해당 컨테이너를 적절한 노드에 배치한다.

June 11, 2021 Read
Hero Image
2-4 Kube Controller Manager

Kube controller manager 쿠버네티스에는 사무실이나 부서 역할을 담당하는 다양한 컨트롤러들이 존재한다. 컨트롤러는 종류에 따라 배들을 모니터링 하기도하고 컨테이너를 확인하고 돌보기도한다. 이러한 컨트롤러들은 역시나 모두 **kube api server**를 통해 통신한다. Namespace controller, Deployment Controller, Endpoint controller 등 다양한 컨트롤러들이 있는데 이러한 컨트롤러들을 모두 관리하는 것이 kube controller manager이다. Kube controller manager는 직접 다운로드 받아 배포할 수도 잇지만, kubeadm을 통해 쿠버네티스를 설정하면 kube-system 네임스페이스에 kube-controller-manager-master 이라는 이름으로 배포된다.

June 11, 2021 Read
Hero Image
2-3 Kube Api Server

Kube-api server 앞쪽에서 설명했듯이 Kube api server는 쿠버네티스의 컴포넌트들을 관리하는 역할을 한다. 사용자가 kubectl을 통해 CLI 명령어를 입력하면 kube api server가 해당 명령어를 받게된다. 받은 다음 먼저, 해당 명령어가 권한이 있는지 그리고 유효한 명령인지를 확인한다. 그리고 유효하다면 ETCD 클러스터에서 해당 데이터를 가져오고 사용자가에게 응답해준다. 다른 예제를 통해 알아보자. 사용자가 pod를 생성하는 작업을 실행하면 아래의 순서대로 동작한다. Authenticate User Validate Request Retrieve data Update ETCD Scheduler Kubelet

June 8, 2021 Read
Hero Image
2-2 ETCD

ETCD란? 해당 강의에서는 ETCD is distributed reliable key-value store that is Simple, Secure&Fast. 라고 소개되었다. 현재 ETCD 홈페이지에는 A distributed, reliable key-value store for the most critical data of a distributed system 라고 소개되었다. Key-value Store Key-value Store는 key 와 value 형태로 저장되는 데이터 베이스이다. 키의 중복은 허용되지 않으며 일반적인 상황의 데이터베이스로는 적합하지않다. 대신 Configuraion과 같은 데이터의 일부를 저장하기에는 적합하다. 왜냐하면 쓰기와 읽기 속도가 빠르기 때문이다.

June 6, 2021 Read
Hero Image
2-1 Cluster Architecture

쿠버네티스의 클러스터 구조 시작하기에 앞서 해당 챕터에서는 쿠버네티스의 아키텍쳐를 고수준부터 설명을 하고 앞으로의 강의에서 좀 더 구체적으로 내려가며 각각의 컴포넌트들에 대해서 알아볼 것이다. 먼저, 각 클러스터의 각 컴포넌트들의 기능과 역할에 대해 알아본다. 쿠버네티스의 아키텍쳐를 선박들에 비유하며 설명할 예정이다. Kuberntes 라는 명칭의 유래는 Helmsman(조타수)를 의미하는 그리스어에서 유래했다. 또한, Kubernetes는 Container Orchestration 이기 때문에 내부 클러스터들의 동작이 선박들이 움직이는 모습에 비유를 많이한다. 쿠버네티스에는 두가지의 선박들로 비유를 할 수 있다. 하나는 직접 바디를 건너 컨테이너를 옮기고 컨트롤 하는 Cargo ship(화물선), 다른 하나는 이러한 화물선들을 지켜보고 관리하는 Control ship이다.

June 6, 2021 Read
  • ««
  • «
  • 1
  • 2
  • »
  • »»
Navigation
  • About
  • Skills
  • Experiences
  • Education
Contact me:
  • Email: sungwoo.dev@gmail.com

Toha Theme Logo Toha
© 2021 Copyright.
Powered by Hugo Logo