• Production-Grade Container Orchestration
• 오픈소스이며 배포와 확장 그리고 컨테이너들을 관리하는 자동화시스템
• 구글이 만들었으며 업계 표준 컨테이너 기술

그리스어로 '조타수' 라는 뜻이며 여러 컨테이너들을 운전하며 관리하겠다는 의미.

쿠버네티스를 k(ubernete)s에서 k와 s사이에 8개가 있어서 k8s라고 읽기도 하며, 컨테이너 오케스트레이션 툴이라고도 한다.

도커

한개 서버위에서 한개 컨테이너를 어떻게 잘 실행시킬수 있는지에 집중한 것

도커 컴포즈

한개 서버위에서 여러개 컨테이너를 어떻게 잘 실행시킬수 있는지에 집중한 것

도커 오케스트레이션

여러개 서버위에서 여러개 컨테이너를 어떻게 잘 실행시킬수 있는지에 집중한 것 쿠버네티스가 여기에 해당된다.

• Clustering - 여러개의 서버를 클러스터링화해서 사용해서 기능을 제공함
• Auto-placement - 어느 서버를 실행시킬지 자체적으로 정함
• Auto-restart - 실행중인 컨테이너가 어떤이유에서 종료되면 알아서 살려서 재실행시킴
• 무중단 배포 - 어플리케이션을 버전업하는 과정에서 사용자가 서비스를 중단받지 않음

쿠버네티스의 개념

모든것이 다 리소스로 표현

• Pod - 가장 기본이 되는 리소스(도커 컨테이너와 유사)
• Node - 하나의 서버
• Service - 네크워크를 담당

앱 정의서

리소스를 YAML형식으로 표현 - 정의된 리소스에 따라 쿠버네티스가 동작

선언형 커맨드 declarative command

대표적인 예로 HTML 그리고 YAML파일

명령형 커맨드 imperative command

대표적인 예로 SQL

쿠버네티스의 동작원리로 두개의 상태를 저장

• 현재상태 - current state
• 바라는상태 - desired state

쿠버네티스는 항상 현재상태와 바라는상태의 싱크를 맞추려고함. 사용자가 새로운 리소스를 생성하기 위해 새로운 파일을 바라는상태에 전달하게되면 변경된 바라는상태와 현재상태와의 싱크를 맞추기 위해 새로운 파일이 현재상태에도 전달되어 새로운 리소스가 생성됨.

새로운 리소스 -> 바라는 상태(변경됨) 바라는 상태 = 현재상태(싱크맞춤) 새로운 리소스 -> 현재 상태(변경됨)

현재상태에서 리소스가 삭제되는 경우 쿠버네티스가 이를 인식하고 바라는상태를 통해서 현재상태가 다시 변경된다.

라벨 & 셀렉터 (라벨링 시스템)

• 각 리소스에 다양한 라벨을 붙일수 있음
• 셀렉터를 통해서 자기가 원하는 라벨을 셀렉팅할 수 있음
• 느슨한 커플링관계를 통해서 확장성 있고 서로간의 관계성을 부여할 수 있음

아키텍쳐

쿠버네티스의 두뇌역할을 하는 Master Node

kube-api-server

• 쿠버네티스 컴포넌트에 있어서 가장 중요한 역할을 함 쿠버네티스의 모든 컴포넌트의 리퀘스트를 받고 응답을 해줌 마스터노드 뿐만아니라 워커노드 또한 정보를 주고받음

etcd

• api-server로부터 들어오는 모든 정보의 데이터를 저장하며 필요에 따라서 제공함 고효율성과 고가용을 위해서 Key-Value의 데이터 형태를 가지고 있음 쿠버네티스안에 모든 메타정보를 저장하고 있는 컴포넌트

kube-scheduler

• 워커노드에 적절하게 컨테이너를 배치하며 어떤 노드에 리소스가 가용하는지를 확인 (스케줄링 역할)

kube-controller manager

• 현재상태와 바라는상태의 싱크맞추기를 수행하는 컴포넌트 현재상태와 바라는상태를 바라보면서 서로 어긋난 경우에 새로운 리소스를 kube-scheduler를 통해 새로 스케줄링을 함 loop를 통하여 이러한 상태를 지속적으로 확인하여 새로운 리소스를 생성또는 삭제함

cloud-controller manager

• 쿠버네티스는 온프레미스 서버에서도 동작하지만 퍼블릭 클라우드에서도 동작하는 경우도 있음 예를들어 트래픽을 받아내는 로드밸런서, 데이터를 저장하는 스토리지가 있는경우는 클라우드에서 제공하는 리소스들을 사용하는데 cloud-controller manager와 cloud를 통신하면서 필요한 리소스를 제공받음

컨테이너들을 실행하는 Worker Node

kubelet

• master node 로부터 특정 컨테이너를 실행하라는 명령을 전달받아 컨테이너를 실행하는 역할을 하며 worker node 자체의 상태정보를 또다시 master node로 전달하는 worker node의 중심이 되는 컴포넌트

kube-proxy

• worker node간 컨테이너의 네트워크 혹은 같은 네트워크 내부의 서로간 컨테이너의 네트워크이며 이런 전반적인 컨테이너간의 네트워크를 담당

쿠버네티스의 장점

• 컨테이너 스케줄링이 편리해짐
• 확장성이 좋아짐
• 모니터링이 쉬워짐
• 장애에 견고해짐
• 하이브리드 / 멀티 클라우드 구현
• 배포방식이 획기적으로 간편해짐
• MicroService를 개발하는점이 편리해짐
• 머신러닝 플랫폼으로서 활용 - kubeflow (쿠버네티스와 텐서플로우를 합친 오픈소스)

Build Context

1. widget tree 에서 현재 widget의 위치를 알 수 있는 정보.

2. BuildContext는 stateless widget이나 state build method에 의해서 return된 widget의 부모가 된다.

Flutter에서 모든 Widget은 build method를 가지고 있다.

이를 통해서 계층 구조를 만들어 나간다.

Widget tree 구글링 이미지 참조

class MyPage extends StatelessWidget { 
    @override
    Widget build(BuildContext context) {
        return Scaffold();
    }
}

Scaffold라는 widget을 return하는데, widget tree 상에서 어디에 위치 하는지에 대한

정보를 가지고 있는 context 라는것을 넣어서 return해준다.

Scaffold widget은 부모인 MyPage에 context를 그대로 물려받게 된다는 의미.

widget tree상에서 Scaffold widget의 위치가 필요하여

현재 Scaffold widget의 context를 참조하면 아래처럼 에러가 나는 경우가 있다.

"Scaffold.of() called with a context that does not contain a Scaffold"

현재 Scaffold widget이 widget tree상에서

어디에 위치하고 있는지 알기 위해서 Scaffold widget이 가지고 있는 context를

참조하려는데 Scaffold widget에 context는 widget tree내에서

Scaffold가 어디에 위치하고 있는지 알수가 없기 때문이다.

build method에 의해서 return된 Scaffold widget은

그 부모의 BuildContext 타입의 context를 그대로

물려받는다고 했으니 Scaffold widget 밑에서

build method로 무언가 widget을 return하면 그 widget은

부모인 Scaffold widget에 진짜 context를 물려받을수 있을 것이다.

youtube 코딩셰프 영상 참조 https://www.youtube.com/watch?v=o-HpnWhI70U