Kubernetes Master node 안에는 무엇이 있는것이냐?

• Master node 구성요소
    ○ etcd
        § etcd 의 어원
            □ 유닉스의 /etc 폴더 + distributed 를 합친 것.
            □ /etc 폴더는 단일 시스템의 구성 데이터를 저장하는 폴더였으며, 그것을 분산한다 하여 분산시스템 이라는 개념 완성
        § 대충 CAP 라는것을 먼저 알아야한다.
            □ 이 세 가지는 분산 시스템에서 나오는 개념이며, 특정 상황에서 셋 중 두 가지만 보장할 수 있다는 개념.
            □ Consistency (일관성)
                ® 모든 노드가 동일한 데이터를 받는 것을 보장한다. - 사용자가 시스템의 어떤 노드에 쿼리를 실행해도 가장 최근의 데이터를 받는다.
                ® 데이터의 변경이 이루어지면 모든 노드에 즉.시. 반영이 이루어져야 한다.
            □ Availbility (가용성)
                ® 모든 요청에 대해 성공 또는, 실패의 응답을 보장한다. - 시스템에 문제가 생기더라도 요청에 대한 응답을 반드시 반환한다.
                ® 가용성이 보장되면 일관성이 희생될 수 있다.
            □ Partition Tolerance (분할 허용성)
                ® 네트워크 분할이 발생했을 때, 시스템이 계속 작동하고 응답할 수 있는 능력
                ® 네트워크의 장애가 발생해도 시스템이 계속 동작하고 사용 가능한 상태를 유지할 수 있어야 하는 능력
            □ 그런데, 분산 시스템에서 네트워크는 신뢰할 수 없다는 것을 가정한다. - 실제로 네트워크가 언제나 완벽하게 돌아간다는건 상상에 가깝잖아?
            □ 따라서 P 는 꼭 챙겨간다고 할 때, 나머지 둘 중 하나를 가져가서 CP, AP 이렇게 나눌 수 있다는게 CAP 이론.
                ® CA - RDBMS
                ® CP - MongoDB, HBase, Redis
                ® AP - CouchDB, Cassandra, DynamoDB, Riak
        § PACELC
            □ CAP 은 네트워크를 못믿는다 라는 가정하에 P를 항상 들고갔으나, 그것의 반대 케이스도 넣어서 이론을 보완한 PACELC 라는 이론이 등장한다.
            □ Partition 을 챙기면 P, 안챙기면 E (Else)
                ® P를 챙겼다. (P)
                    ◊ A 를 챙긴다 => AP
                    ◊ C 를 챙긴다 => CP
                ® P를 안챙겼다. (E)
                    ◊ Latency L을 챙긴다 => EL
                    ◊ C 를 챙긴다 => EC
            □ 그 중 etcd 는 CP/EC 에 속하여, 가용성을 크게 챙기는 데이터베이스라고 볼 수 있다.
        § Raft 알고리즘...
        § 아무튼 그래서 key-value 로 된 저장소임. 

    ○ kube-apiserver
        § 쿠버네티스 클러스터의 API 를 사용할 수 있게 해주는 프로세스이다.
        § 클러스터로 요청이 들어왔을 때, 그 요청이 유효한지 판단함
        § 쿠버네티스로 들어오는 모든 요청은 apiserver을 먼저 거치고, 다른곳으로 전달된다.
        § 대충 api를 통해 할 수 있는 것
            □ 어떤 기능을 admin 할지, deny 할 지 정하기
            □ apiserver 에 접근하기 위한 ip주소 나열
            □ 컨테이너를 privliged 모드로 실행하기
            □ 클러스터 내 실행되는 apiserver 갯수 출력
            □ CORS를 허용하는 목록 나열
            □ TLS 인증서들이 있는 경로 출력
            □ 토큰인증에 대한 설정을 갖고있는 파일 출력
            □ 등...

    ○ kube-scheduler
        § 새로운 pod가 생성될 때, 현재 클러스터 내에서 자원할당이 가능한 노드들 중 알맞은 노드를 선택하는 작업을 함
        § pod가 처음 실행될 때, 여러가지 조건을 지정해서 실행하는데, 이 스케쥴러가 그 조건에 맞는 노드를 찾아준다.
            □ 이 때 조건에 맞는 노드를 feasible node (피지블 노드) 라고 부른다고 함
        § 특별한 스케쥴링을 원한다면 커스텀 스케쥴러를 만들 수도 있다.
        § 조건에 맞는 노드를 찾기위해 하는 일:
            □ 리소스 요구사항 확인 (Filtering 과정)
                ® CPU, 메모리, 스토리지와 같은 리소스 요구사항을 충족하는 노드를 선택
                ® 이 과정이 Filtering 과정.
                ® 이 때, request / limit resource 에 대한 개념이 나옴.
            □ 필터링 된 노드 중 pod 가 실행될 최적의 노드를 찾는 (Scoring 과정)
                ® NodeSelector
                    ◊ Node 에 Label 을 부여하고, Pod 에서 nodeSelector로 Node를 지정할 수 있다.
                ® Node affinity
                    ◊ 설정 시, affinity 값에
                    ◊ requiredDuringSchedulingIgnoredCuringExecution 하면 스케줄링 간에 만족하는 노드가 없으면 스케줄링 안해버림
                    ◊ preferredDuringSchedulingIgnoredDuringExecution 하면 만족하는 노드가 없어도 어딘가 뜸
                ® Anti affinity
                    ◊ pod 설정에 replica 2개로 해놓고 anti-affinity를 설정하면 두 pod가 서로 다른 node 에 뜬다고 함
                ® Taint / Toleration
                    ◊ 노드 안에 taint effect 설정해놓으면, 그 노드엔 pod 가 안뜬다. 
                        } 정확히는 NoSchedule => 안뜨게
                        } NoExecute => 뜨지만 eviction (제거/종료)
                        } PreferNoSchedule => 되도록이면 안뜨게
                    ◊ 그런데 pod 의 설정에 toleration 설정해놓으면 taint effect 해놓은 노드에도 pod 가 뜬다.
            □ 네트워크 토폴로지 ?
                ® 네트워크 토폴로지를 고려해서 컨테이터를 배치하고, 대역폭 및 지연시간을 최적화 한다고 함
                ® 동일한 서브넷에 속한 노드에 컨테이너를 배치하여 네트워크 트래픽을 최소화하기
            □ 안정성 및 가용성 고려
                ® 그리하여 장애 발생 시 서비스의 영향을 최소화
                ® 예를들어, 동일한 물리적 위치에 있는 노드들에 컨테이너를 분산하여 단일 장애 지점을 피한다

    ○ kube-controller-manager
        § kube 안에는 controller 가 참 많다.
            □ node-controller : node 를 모니터링(health check)하는 애
            □ replication controller : kube-apiserver 에서 노드의 상태를 받아오고 언제나 후보선수로 나갈 수 있는 노드를 준비시키는 역할을 함
            □ 이를 포함하여 여러가지 많다.
                ® Deployment-controller
                ® Namespace-controller
                ® Endpoint-controller
                ® CronJob
                ® Service-Account-Controller
                ® Node-controller
                ® Job-Controller
                ® Stateful-Set
                ® PV-Binder-Controller
                ® PV-Protection-Controller
                ® ReplicaSet
                ® Replication-Controller
            □ 이것들을 관리하는게 kube-controller-manager 이다.
            □ kubectl 을 통해서 controller manager option 등을 알 수 있다.
            □ 각 컨트롤러들은 논리적으로 개별 프로세스이지만, 복잡도를 줄이기 위해 하나의 바이너리 파일로 컴파일 되어있고, 하나의 단일 프로세스로 실행됩니다.
            □ 클러스터 내에서 새로운 컨트롤러가 사용될 때는, 그 컨트롤러에 해당하는 구조체가 만들어진 뒤 그것을 kube-controller-manager 의 queue에 넣어서 실행하는 방식이다.

    ○ cloud-controller-manager
        § 클라우드 서비스를 제공하는 곳들에서 쿠버네티스의 컨트롤러들을 자신의 서비스와 연계하기 위해 있는 것
        § 관련된 코드는 각 클라우드 서비스 제공사에서 직접 관리하도록 되어있다고함
            □ node controller
                ® 클라우드 서비스에서 노드를 관리
            □ route controller
                ® 클라우드 인프라 내에서 네트워크 라우팅을 관리
            □ service controller
                ® 클라우스 서비스에서 제공하는 로드밸런서를 생성/갱신/삭제
            □ volume controller
                ® 클라우드 서비스에서 볼륨을 생성해서 노드에 붙이고 마운트해서 볼륨을 관리

https://arisu1000.tistory.com/27828 쿠버네티스 구성요소

https://smileostrich.tistory.com/entry/etcd Inside Etcd