oneway's history

Imperative Commands 뜻

> "kubectl create", "kubectl delete", "kubectl apply"와 같은 형태
> 이는 선언형 접근 방식(예: YAML 파일을 사용하여 리소스를 정의하고 관리하는 방법)과 대조됨

<1>

대충 명령어로 해결할 수 있는건데, yaml을 써서 해결해야하는 경우도 있다는걸 말해주는 듯

<2>

pod 생성엔 kubectl run 사용

<3>

pod 생성시 label 설정엔 --labels 사용

<4>

service 생성엔 kubectl expose 사용

kubectl expose <리소스명> <리소스이름> --name=<service이름> --port=<포트>

<5>

deployments 생성엔 kubectl create 사용

kubectl create deployment <이름> --image=<> --replicas=<>

그런데 create deployments 하니까 안되네, create deployment 로 해야 맞는거같다.

<6>

<7>

<8>

<9>

service를 생성할땐 kubeclt expose,

주의할점: type 설정에 ClusterIP << 대문자 틀리면 안된다

targetPort 설정엔 --target-port << targetPort 가 아니다

targetPort를 설정해줬다면, port 도 설정해줘야한다.

<1>

<2>

ㅇㅇ

<3>

<4>

<5>

<6>

<7>

deployments 의 줄임말은 deploy 였다.

<8>

<9>

No

<10>

vi 명령어로 파일 수정

이 행위를 통해, webapp-service 라는 이름을 가진 service를 만드는데

타입은 NodePort 이다. NodePort는 특정 포트를 통해 외부로부터 트래픽을 들어올 수 있게 만든다. 

여기선 30080 라는 포트로 들어올 수 있게 했다.

그리고 떠있는 deployment 를 보면 simple-webapp-deployment 가 있는데, 이것의 label이 name=simple-webapp 이다.

방금 만든 service가 selector로 name=simple-webapp 설정해줘서, 서로 똑같으니까 엮이는 것

<11>

pod가 떠있는 node:<port번호> 치면 연결시도 한다.

계속 쳐보니 떠있는 4개의 pod 중 랜덤으로 들어가려 하는게 보인다.

자동으로 트래픽분산 시켜주는 듯 하다.

service 지워봤더니 연결안됨.

<1>

namespace가 엄청 많으면 어떻게 세나 싶어서 solution 봤더니

--no-headers 옵션에 wc -l 넣어서 갯수 세는 방법이 있었다.

<2>

<3>

https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#run

이 곳에  pod 를 간단히 실행시키려면 run 명령어를 쓸 수 있다는 내용이 있다.

<4>

-A 옵션은 모든 namespace를 뒤져서 찾아준다.

<5>

<6>

<7>

서로다른 namespace에 있는 service(clusterIP)와 pod를 엮으려면 

<service-name>.<namespace>.svc.cluster.local

이런식으로 통신해야한다고함.

인터넷 검색으로 알아내었다.. 솔루션 보면 그냥 db-service.dev.svc.cluster.local 저렇게 하라고만 써있다.

<1>

<2>

replicaSets 줄임말 rs 사용

<3>

<4>

<5>

<6>

<7>

<8>

<9>

<10>

<11>

apiVersion 이 안맞다고 하는 것 같다.

kubernetes 공홈 -> replicaSets 검색, 보니까 apiVersion 이 apps/v1 이다

vi replicaset-definition-1.yaml 로 수정

<12>

<13>

<14>

kubectl edit 으로 바꿔줬는데, 갱신이 안돼서 pod 전부 kill 했더니 된다.

<15>

<16>

<1>

<2>

kubernetes 공식홈페이지에 pod 검색

참고, 메모장에 옮겼다가 수정

<3>

<4>

<5>

<6>

<7>

<8>

<9>

<10>

<11>

<12>

<13>

kubectl edit pod <pod명> 사용

linux 에서 vi 로 파일탐색할때 i 누르면 수정모드로 들어간다. 그리고 수정 후 ctrl+c 누르면 되돌아나온다.

:wq! 쳐서 저장+종료+강제 실행

• 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

   • Kubelet
      ○ 클러스터 내의 모든 "노드"에서 실행되는 에이전트임
      ○ Pod 내의 컨테이너들이 실행되는걸 직접적로 관리한다.
      ○ podSpecs 라는 설정을 받아서 그 조건에 맞게 컨테이너를 실행한다
      ○ 실행한 컨테이너가 정상적으로 실행되고 있는지 상태체크를 한다
      ○ 노드안에 컨테이너가 있더라도 쿠버네티스가 만들지 않은 컨테이는 관리X

   • Kubectl
      ○ 쿠버네티스 API를 사용하여 컨트롤 플레인과 통신하기 위한 커맨드라인임.
      ○ 쿠버네티스 자원들의 CRUD
      ○ 생성된 자원들의 모니터링 및 트러블슈팅
      ○ 트래픽 운영상황에서 클러스터 관리 가능

   • Ingress
      ○ 클러스터 내의 서비스에 대한 외부 접근 관리하는 API 오브젝트
      ○ 일반적으로 HTTP를 관리하지만, SSL 인증서 넣으면 HTTPS 도 관리 가능
      ○ 로드 밸런스, 명칭 기반의 가상 호스팅 제공 가능
      ○ 클러스터 외부에서 내부로 HTTP/HTTPS 경로를 노출,
      ○ 트래픽 라우팅 규칙에 의해 서비스로 보냄
      ○ Ingress 를 정의할 땐 필드명 apiVersion, kind ,metadata, spec 의 명시되어야 함

※ 틀린 정보 존재 가능!!

    • VM
        ○ 컴퓨터라고 보면됨. 각각 VM마다 OS 가 있음.
        ○ 그 OS를 돌리는데에 자원이 필요함.
        ○ 로컬 컴퓨터 안에 가상컴퓨터 깔면 그 안에 Windows가 될 수도 있고 linux도 되고, 그래서 컴퓨터 안에서 컴퓨터를 조작하고 갖고놀 수 있는데 그런거 해봤으면 이해가 빠름
        ○ OS위에 여러 어플리케이션 집합시켜서 서비스 돌릴 수 있음.
            § 단점:
            § VM이 여러개면 각각마다 OS가 있어서 그 자원을 잡아먹는게 아까움.
            § 라이브러리 버전을 바꿔야 한다 하면 각각VM마다 다 업글해주고 그래야함 - 번거로움
            § 하나의 시스템 안에 여러개의 어플리케이션이 있어서 그 VM가 보안에 뚫리면 그 안 어플리케이션 전체가 보안에 취약해짐

    • 노드(VM라 봐도 됨)
        ○ 얘도 컴퓨터임. OS도 있음
        ○ VM은 하나의 VM이 여러개의 어플을 갖고 돌린다면, 노드는 개별 앱을 갖고 돌림. (꼭 안그래도 되는데 그래야 가벼워지고, 확장성이 좋아지며 MSA를 만드는데 의미가 있음)
        ○ 각각 노드는 독립적이어서 네트워크도 달라버림. 그래서 하나가 뚫려도 하나만 뚫리지 나머진 안전함

    • 클러스터
        ○ 노드가 모이면 클러스터가 됨

    • 컨테이너
        ○ 뭔가 어떤 어플을 돌리기 위한 여러가지 요소들을 합쳐놓은 패키지임.
        ○ Docker가 컨테이너 그 자체임. 도커라이즈 한다는거 자체가 이미지를 만드는건데 그 이미지 안에 여러가지 짬뽕 앱들이 섞여서 어떤 시스템을 만들 수 있음.
        ○ 컨테이너는 그 자체로 존재할 수 있음. OS없어도 컨테이너 런타임(도커같은거)만 사용하면 시스템이 돌아감.

    • 그래서,
        ○ MSA는 어떻게 구성되냐
            § 적절히 커다란 하드웨어 리소스가 있음
            § 그 리소스를 어느정도 써서 클러스터를 띄움
            § 클러스터 안에는 노드들을 띄움.
            § 클러스터는 노드들을 Orchestration 함 (지휘 함)
                □ 지휘 한다는게 뭐냐면 여러 노드들에게 자원을 분배할 수도 있고, 노드가 뻑나면 죽였다 살리기도 하고, 노드를 하나 더 만들고 싶으면 만들고, 모니터링을 하겠다 하면 하고 그런거
            § 노드 안에는 pod들이 뜸.
            § pod는 가장 최소화된 단위임. 그것들이 서로 API 통신을 하든 뭘 하든 어깨동무하면서 시스템을 하나 만들어서 서비스가 돌아갈 수 있게 함

        ○ 그런 행위를 하면 뭐가좋냐
            § 첫째 - 유연해짐.
                □ 만약 VM 배포를 하는 시절이었으면, 내가 뭐 버전업을 해야함. 그럼 각각VM에 전부 그 버전으로 올려야댐
                □ VM 안에 앱 하나가 고장나버렸어, 그럼 VM안에 같이있던 다른 앱들까지 손해를 오지게봄
                □ MSA 구성을 하면 라이브러리 참조를 하는 컨테이너만 삭 업글 해주면 나머지가 그걸 보고 알아서 업글 가능
                □ 앱이 몇개 고장나도 미리 2~3개 복제해서 띄워놨다면 다른 서비스에 손해가 가지 않음
            § 둘째 - 인간이 편해짐
                □ 개발자/운영자가 해야할 일이 줄어듬 왜냐면 저 시스템이 알아서 해주니까.
                □ 뭘 알아서 해준다고? 자원분배, 고장나면 죽였다 살리기도 하고, 오버헤드가 쌓이면 수평적으로 오토스케일링도 해주고, 그런게 되는게 개꿀임.

    • 네임스페이스
        ○ 근데 하나의 클러스터 안에 여러개의 컨테이너가 뜬다했잖아
        ○ 너무 많이 떠버려서 막 혼잡해 그럼 불편하잖아
        ○ 그래서 좀 시스템별로 분리해서 띄우고싶으면 사용하는게 Namespace
        ○ 그 종류는 다음과 같음
            § 마운트mnt, 프로세스ID(pid) , 네트워크net, 네트워크 간 통신ipc, UTS(Unix timestamp??, 사용자 ID(user)

    • Docker
        ○ 한마디로, 모든걸 짬뽕시킬 수 있는 간편한 포터블 패키지 툴
        ○ OS가 달라도 Docker을 사용하면 뭘 패키징 했는지 내부 확인 가능
        ○ 왜냐면 앱을 실행하기 위한 환경 자체까지 패키징 할 수 있어서.

    • 도커 기반 컨테이너와 VM 이미지의 차이
        ○ 도커는 컨테이너 이미지가 여러 레이어로 구성되어 있음
        ○ 레이어들은 여러 이미지에서 재사용 가능함
        ○ 동일한 레이어를 포함한 컨테이너 이미지를 실행할 때는 이전에 다운로드 된 것을 제외하고 다운해서 빠름.

    • Docker의 주요 개념
        ○ 이미지
            § 애플리케이션과 환경을 패키지로 묶는 것.
        ○ 레지스트리
            § 도커 이미지를 저장, 사람들간에 이미지를 공유할 수 있는 스토리지임
        ○ 컨테이너
            § 도커 기반 컨테이너는 곧 리눅스 컨테이너임
            § 실행중인 컨테이너끼리는 완전히 독립적.

    • 근데 계속 독립적이라고 하는데, 어떻게 독립적인 녀석들끼리 동일한 파일 공유 가능?
        ○ 이미지 레이어 때문임
        ○ 여러 컨테이너는 같은 이미지를 사용하면 그걸 베이스 이미지로 공유해서 씀
        ○ 그런데 만약 여러 컨테이너 중 한 놈이 그 이미지를 갈아끼워버리면, 갈아끼운 놈은 베이스 이미지가 바뀌어서 예전걸 볼 수 없음 (나머진 여전히 공유함)
        ○ 이것은 컨테이너 이미지 레이어가 읽기 전용이기 때문에 동작함

    • 컨테이너가 자체 커널을 두기 때문에 발생할 수 있는 일
        ○ 몇몇 앱이 특정 커널 버전을 요구하면 그 앱은 돌아가지 않음.
        ○ 또한, 하드웨어 아키텍처가 달라도 안됨
            § 예를들면 x86 아키텍처, 또는 ARM 기반 시스템

    • rkt
        ○ 도커와 같은 컨테이너 실행 플랫폼임. 리눅스 컨테이너 엔진임.
        ○ OCI => 컨테이너 형식 및 런타임에 대한 개방된 업계 표준
        ○ rkt 는 OCI를 따름. 도커도 OCI 의 일부. 따라서, 도커 컨테이너 이미지를 rkt도 실행 가능.

    • 쿠버네티스
        ○ 간략한 역사
            § 구글이 만듬
            § 얘낸 수십만 대의 서버를 운영, 엄청난 규모의 배포관리를 처리해야 했을 것, 그래서 수천 개의 소프트웨어 구성 요소를 개발하고 배포할 때 효율적이고 비용적게 들게 관리할 수 있는 솔루션을 만듬
            § 2014년 나옴
        ○ 작동법?
            § 리눅스 컨테이너 기능을 사용
            § 마스터 노드가 있고, 여러개의 워커노드로 구성됨.
                □ 마스터 노드에 어플리케이션 manifest 를 제출하면 걔가 워커노드 클러스터에 삭 배포쎄림.
        ○ 쿠버네티스가 유용한 이유
            § 특정 인프라 관런 서비스를 애플리케이션에 구현하지 않아도 됨
            § 쿠버네티스가 다 해주기 때문.
            § 뭘 해주냐고? - 서비스 검색, 확장, 로드 밸런싱, 자가 치유, 리더 선출.
            § 그래서 개발자는 개발만 하면 된다.

        ○ 아키텍쳐
            § 마스터 노드 -> 워커 노드
            § 마스터 노드
                □ 컨트롤 플레인 이라 부르는듯
                □ 사용자와 컨트롤 플레인과 통신하는 쿠버네티스 API서버
                □ 스케쥴러 역할
                □ 구성 요소 복제, 워커 노드 추적, 노드 장애 처리 등 클러스터 수준 기능을 수행하는 컨트롤러 매니저임
                □ etcd는 일종의 저장소인데 키-값 형태를 띰. 얘는 클러스터 구성을 지속적으로 저장함.
            § 노드
                □ 노드는 마스터노드와 kubelet 이라는 API통신을 통해 구성 설정을 공유함
                □ 애플리케이션 구성 요소 간에 네트워크 트래픽을 분산하기 위해 kube-proxy 를 씀.
        ○ 실행중인 컨테이너 유지
            § 사용자가 딱 5개의 pod만 뜨게 설정했다
            § 그럼 5개가 뜬다. 그런데 이상하게 1개가 뻑나서 안뜨고있다?
            § 그럼 자동으로 얘 죽이고 다시 하나 새로 띄운다. 그런식으로 사용자가 지정한 설정대로 유지하려고 함.
            § 노드도 마찬가지.
            § 노드의 상태가 메롱이야. 그럼 노드 안에 실행되고 있는 컨테이너들을 다른 노드에 싹 옮겨서 살려낼라고 함.

        ○ pod 수 확장 가능
            § 복사본 만들어서 늘리기, 줄이기 다됨.
            § 적절한 갯수를 쿠버야 너가 알아서 해줘 하면서 맡기기도 가능
            § CPU, MEM, 초당 쿼리 이런 것들도 설정 가능

        ○ 분산되어있는 컨테이너들이 서로 어떻게 연결하는지
            § 노드상태가 메롱이거나 하면 pod들이 다른 노드로 옮길수도 있고 클러스터를 옮길 수도 있고 그런데, 그러는순간 연동이 끊기는거 아닌가 싶으나
            § 미리 동일한 서비스를 제공하는 컨테이너의 정보와 모든 고정 IP 주소를 공개하고 그걸 클러스터 내에 노출시키면 pod들이 알잘딱으로 통신 한다
            § 이런 방법은 환경 변수를 통해 만들어내고,
            § 또다른 방법으로는 DNS를 통해 서비스IP를 조회할 수도 있씀

        ○ 앱 배포 단순화의 실현
            § 쿠버네티스가 모든 서버에 배포되어있음
            § 클러스터 다 떠있고, 리소스 할당 잘 받았음.
            § 개발자가 이제 할 건 어플리케이션 배포만 잘 하면 됨
            § 사실 배포도 딱히 할거없음. 버튼1회 누르면 자동으로 빌드, 도커라이즈, 배포 다 해줘서 인스턴스 뜰때까지 그냥 보고만 있으면 됨
            § 클러스터 구성 서버가 뭔지, 알바가 아님. 그걸 관리하는 사람은 따로 있으면 됨
            § 그니까 개발자가 원래 개발/운영/배포 다하는 devops 성향을 갖는 시기가 있었는데 그게 너무 할일도 많아지고 번거로왔는데, 이제 개발자는 개발에 몰두할 수 있게 됐다는게 핵심

        ○ 하드웨어 활용이 높아짐
            § 왜냐면 어플 배포할 때 어느정도 리소스를 먹으면서 올라갈텐데
            § 클러스터 내 여러 노드가 떠있을 때 가장 적절히 리소스가 여유로운 쪽에 어플을 올려다놓음.
            § 그래서 어느 한 쪽이 부하가 일어나지 않고 잘 배분함.
            § 이런게 솔직히 인간이 하기엔 번거롭고 쉽지않음. 언제 그거일일히 다 보고있음.. 노드가 적은것도 아니고 막 수십개면 불가능한것임.

        ○ 상태를 자기스스로 파악하고 지혼자 치유함
            § 위에도 썼던거 같은데 노드가 상태가 메롱이야. 또는 pod가 말을 안듣고 장애가 나버렸음
            § pod를 즉시 kill 때리고 다시 띄움. 잘 돌때까지. (처음 잘 떴다면, 그 다음 죽는 경우는 보통 어떤 예외상황 때문이며 kill 당하고 새로 살아났는데 또 kill 당하는 무한반복이 일어난다면 그건 개발자가 실설정실수했을 확률높음 그건 배포하고 모니터링 후 바로 조치 해야됨)
            § 노드 상태가 이상하다 하면 그 안에 떠있는 컨테이너들을 빨랑 다른 가용한 노드로 옮겨서 살려냄.
            § 그럼 일단 서비스는 살아있는 상태가 되는거.
            § 그 사이에 고장난 노드에 대한 점검을 개발자가 하든지 하면 됨.
            § 특히 그런 노드 장애가 새벽에 발생했다고 해보면 노드내 컨테이너를 일단 살려내 놨으니 그 즉시 장애를 치유할 것이 아닌 아침에 출근해서 확인해도 되는 부분인 것.
            § 즉, 쿠버네티스가 삶의 질을 높여준다는 것.

        ○ 오토스케일
            § 어떤 서비스에 갑자기 사용자가 엄청 몰려서 부하가 씨게 일어났음
            § 리소스량이 막 한계를 초과해서 터질라함
            § 오토스케일을 설정했다면 문제없다. 어느 정도의 부하가 발생하는 것이 캐치되면 pod 수를 자동으로 늘려서 부하를 분산시키는 작업을 알아서 해줌.
            § 부하가 줄어들고 어느정도 시간이 지나면 다시 pod 수를 낮춰서 정상으로 돌려놓는다.
            § 오토스케일이 없었으면 이미 서비스 뻑나서 503 장애발생했을건데 그걸 막아준다. 최고다.