쿠버네티스

쿠네 클러스터가 15000대 클러스팅 된 환경을 운영했다고 기록세운적이 있다.
서비스도 내부적으로 보면 어떤객체일거같아요? 서비스 자체도 파드인거에요 . 로드밸ㄹ런싱 역할을 하는 서비스역할까지 한다.
서비스같은 경우에 타입이 로드밸런서,클러스터ip, 어쩌구 세개
별도로 지정하지않으면 클러스터ip가 디폴트타입이다. 외부에 노출을 해야하는 경우는 노드포트 혹은 노드밸런서를 해야지만 클러스터 외부에서 접근을 할 수 있다.

서비스라는거 자체도 사실을 파드의 하나이다. -> 기억

서비스를 만들어서 사용하기도 한다. -> 이런걸 인그래스라고 함
실제 쿠네를 해보면 하면 할수록 더 해야되는게 많구나 라는 생각이 들게 될거다.
정말 계속 더 추가적으로 공부를 해야하는 굉장히 내용이 방대한 주제이다.



- 쿠네에서의 접근 제어
일반사용자 : iam에서 관리
서비스계정 : 쿠네에서 관리

- 쿠네 객체의 두 가지 요소
쿠네에 존재하는 모든 내용은 객체로 존재
쿠네는 끊임없이 모니터링하고 사용자가 원하는 스펙으로 맞추기 위해서 노력한다.
컨트롤러 매니저에 의해서 확인이 되고 실제로 파드를 배포를 할때는 xx을 통해서 파드 디플로이먼트가 배포가 된다?

- api서버는 여러 방식으로 인증을 수행
쿠네는 api 서버 마스터에 있는 api 서버에 의해서만 명령을 받음
실제 이 명령어는 실행을 하게되면 api서버를 통해서만 명령어가 전달이 된다.
그리고 실제 클라우드에 쿠네클러스터를 사용하게 되면 마스터 컨트롤 플레이는 보여주지 않는다.
쿠네 자체에는 인증프로바이더가 존재하지 않는다. 허가된 사용자만 쿠네를 쓸 수 있게 만들어야하는데
정적 암호르 사용을 하거나 x509인증서를 사용하거나
최근에 쿠네는 기본적으로 인증서와 정적암호는 사용중지, open id연결 토큰을 사용

사용자한테도 권한 줄 수 있고, 서비스어카운트를 통해 서비스한테도 권한을 줄 수 있다.
서비스든 사용자든 토큰만 갖고있으면 인증과 권한제어를 할 수 있다. 
인증과 제어를 하기위해서 클라우드가 제공하는 서비스는 IAM
해당 리소스에 대한 적절한 권한이 있어야지만 작업 가능

- 쿠네 RBAC
누가 어떤 자원에 어떤 작업을 할 수 있도록 허용할것이냐?
롤 바인딩 : 사용자한테 역할을 부여하는 것

최소단위 : 파드
'관련잇는 컨테이너들의 묶음 : 파드

https는 어떤 스토리지? : 운영체제가 사용하는건 블록레벨 스토리지라고 하고 , file storage , object storage
s3같은건 object storage

애플리케이션을 배포할때 디플로이먼트만 배보한다고 끝이 아님. 디플로이먼트에 배포를 할 수 있도록 로드밸런스 역할을 하는 서비스도 같이 배포가 되어야한다.나중에 어플리케이션이 복잡해지면 서비스도 여러개배포되어야하낟.
이거를 한번에 패키징 시켜서 배포하는게 가능하다.

객체를 패키지로 구성해서 배포하는 것 - helm
인그레스 : 각각의 서비스에 트래픽이 분산되도록 만드는거. /app /sales . 서비스의 서비스를 인그래스라고 한다. 

요즘은 하둡을 레거시라고 함
요즘은 스파크같은거 씀 
스케줄링은 하둡이하는거고 실제 일을 하는 건 스파크가 많이 함

 

 

 

 

---------------------------------------------------------------

 

ㅇdeployment
service객체 생성
종속성, 컨테이너 런타임
어느 파드에 접속을 해얄하는가 
파드 앞에서 부하분산을 해주는게 서비스
앞단에 로드밸런서가 있고
아마 프론트앤드있고 또 다시 실제 비지니스로직이 동작을 하는 백엔드가 있겠죠
마찬가지
로드밸런서 역할을 해주는게 마찬가지로 필요하다
그 파드들은 항상 사라짌 수 있는 자원이다
컨테이너는 언제든지 사라질 수 있는 자원이다
필요하다면 애플리케이션 생명주기와 수명주기
디비도 컨테이너로 띄어도 상관ㅇ ㅣ없다
사용자들의 데이터는 영구히 남아있어야하는 존재이므로
보통 컨테이너화를 시키지 않고 대부분은  클러스터 같은 것들을 만들어서 구성을 함
실제로 여러분들이 azure나 aws나 아니면 gcp나 이쪽에서 클라우드에서 제공해주는 dㅠgkrh
이전에 존재하던 db는 같은 db라 생각하면 안된다.
이전db는 시대에 뒤쳐지는 디비라는 생각ㅇ르 해야하고
분명히 뒤쪽에서는 db를 동작을 시키는데 클러스터로 동작을 한다.
여러 노드를 묶어서 하나처럼 쓰는게 클러스터이다.
나중에 클라우드에 있는 db랑 다른 rdb를 비교를 해보면
얘와 얘들은 천지차이이구나 라는 것을 생각해야한다.

디비들 직접 경험을 해보면 좋지않을까 생각을 합니다.

겉껍데기는 기존에 있던 알맹이
기존에 있던 디비랑 샤드를?하더라도 이런 관릴르 해야ㅈ

a-f는 어느디비에
g-m까지는 또 다른 디비에
n-z까지는 또 다른 디비에
이렇게 나누는게 샤딩
디비를  나눠서 저장을 하면 확장성있게 좋다..?
앞단에서 디비를 분배해주는게 필요하다. 
 rdb는 썩 좋지않다. 왜냐하면 rdb만든 목적은 한쪽으로 중앙집중적으로 몰아서 관리하려고.
그래서 분산구조로 rdb가 분산으로 가는 것은 어렵다.

실제로 샤딩은 원시적인것이다.

솦웨적으로 저렇게 다 나눠주는 것은 '클러스터'이다.
요즘에 나와있는 디비는 noSQl은 저렇게 다 나눠준다.

그래서 기본적인 애플맇케이션이 동작을 하게되면
프엔, 백, 디비 이렇게되어있고
앞단에서 로드밸런스를 해주는 서비스
그리고 하나로 패키지화해서 배포, 

ㅇ뤈래 정확하게는 하드에 대한 네트웤에 대한 추상화해주는 걸 서비스
쉽게 접근하자면 파드가 여러개일때 어느 파드로 분배해서 접근할건지 마치 로드밸런서 역할을 해주는 객체를 서비스라고 한다. 라고 기억하면 쉽게 접근할 수 있음

쿠네는 스펙만 정의해두면 쿠네가 동작하도록 되어있다. 
즉 선언적인 구조로 동작을 한다.
실제 클러스터가 구성이되어있다하면 어느 노드에서건 파드가 세개가 똑같은게 세개가 동작할 수 있다.
하나의 노드에 세개가 떠있는 것이ㅏㄷ.

사용자는 야믈파일에 파드가 3개가 필요하다고 정의해놨고
쿠네는 사용자가 원하는 스펙에 맞추기 위해 노력을 해놨음
실제로 이렇게 맞춰주는 쿠네객체를 디플로이먼트 컨트롤러

컨트롤러매니저에 의해 관리되는 객체중에 하나가 디플로이먼트 컨트롤러

디플로이먼트와 파드세개 사이에 replicaSet
replicaSetController

파드가 세개가 똑같은거 세개가 동작을 하고 있는거고
그럼 사용자는 접속을 할 때 셋 중 하나 어디든 접속하면 되는것이다.
셋 중하나로 부하분산해줄 로드밸런서가 있어야한다.

그래서 야믈 파일에 객체에 대한 스펙ㅇ르 정의를 했고
실제 실행할 때는 ㅇㅇㅇ옹ㅇ


사용자가 kubectl로 명령을 실행하게 되면
실제 쿠네가 뜨는게 쿠버네티스
각 노드마다 컨테이더container-d같은 컨테이너 런타임이 구성되어있어야한다.
이미지가 실행되려면 이미지는 실행이 되어야하는 각 노드에 있어야한다.
그러면 레지스트리에서 container-d에 접근제어에대한게 되어있다
마지막에는 레지스트리에 대한 접근제어가 되어잇다?


매니페스트에 대한걸 정의하고
객체를 배포를 합니다.
이때 ㅍ배포를 할 때 kubectl apply -f 스펙이 정의되어있는 파일(즉 매니페스트 파일) 

GitOps = 쿠네처럼 설정파일을 만들어두면 알아서 설정해주는거; 코드로 자원들을 관리하는 것
직접 gui에서 클릭ㅎ클릭해서 하는게 아니라

파드 집합을 네트워크 상에서 안정적으로 추상화 시키는게 서비스이다.

똑같은 백엔드 파드게 새개가 있으니까 프엔은 어디에 접근하면 되죠? 프론트는 누구한테 접근하면 되는거죠?사실
얘들의 주소를 하나씩 알고있으면 되는건데 그렇게하면 관리가 어려우니까
결론은 프엔은 서비스만 찾아 들어가면 된다.

실제 파드라고 하는 것은 공유스토리지 및 네트워킹ㅇ ㅣ포함된 컨테이너 그룹

파드가 고유한 ip를 할당받아야한다.
하나의 노드에서 마치 가상의 노드인데 포트가 다르면 여러 애플리케이션이 뜰 수 있어요? 네네 
하나는 엔지넥트 80포트를 쓰고 있고 하나는 레거시애플인데 8000을 쓰고있다. 여러분의 pcㅔㅇ서 쓰는 엑셀 이런건 , 외부에서 포트를 통해서 애플리케이션에 접근할 수 있다.

파드도 여러분이 생성을 하게되면 파드가 고유한 아이피를 할당받는다. 
그러면 이제 뭘 고민을 해야되나면
하나의 노드에서 두개의 파드가 잇을 때

파드는 연관된 컨테이너들의 묶음
파드는 파드마다 고유한 아이피를 가짐
파드를 두개를 띄었을 때....
두개의 아이피가 서로 다르다.





클라우드에서 쿠네를 직접 구성해서 쓰는건 바람직하지 않다.
클러스터를 설치할 때 cni가 설치가 되어야한다. 
알칼리고라던지 플래코라던지

1. 파드안에서 파드안에 있는 컨테이너와 컨테이너 간의 통신이 이루어질 필요가 있다.
2. 같은 노드인데 파드가 2개뜨고 그 파드간에 통신이 이루어져야 한다.
(노드와 다른 노드간의 통신)
3.서로 다른 노드에 있는 파드간에도 통신이 이루어져야한다. 
쿠네에서 배포되는 작은 단위는 pod이다.

ip는 우리가 기억하기에 좋지않은 정보입니다.
그래서 여러분은 대부분 어떤 서비스를 사용합니까? dns 를 사용함
쿠네도 ip가 있지만 ip를 가지고 언제든 떴다 죽었다 할 수 있는애 즉 ip가 수시로 바뀔 수 있음. 그래서 ip base로 동작을 하면 x , 그래서 얘도 dns기반을 동작해야함
파드들의 추상화 해주는 객체를 서비스 라고 한다.

etcd : 키 밸류로 저장
landscape.cncf.io

cni !
언니한테 캡쳐해서 보낸거


외부에서 접근하려면
1. NodePort : 노드마다 포트가 열려야함. 사용자가 노드에 대한 ip를 알고있어야함, 노드에대한걸 외부 사용자한테 공개를 안함... 외부에선느 직접적으로 ip를 찾아서 포트 치고 들어오는 케이스가 거이 없다. 결국에서 외부에서 사용자가 들얼오려면 익스터널 로드밸런스가 동작을 해야함 바로 2번
2. LoadBalancer  : 사용자는 로드밸런서를 통해서 부하분산 되면서 외부pod로 접근 가능하다.
결국 이제 애플리케이션 구조를 보게되면 
앞단에 로드밸런서가 필요하다! 이거 해주는 서비스를 "서비스"라고 한다.
서비스 유형요약에서 
첫번째 그림은 클러스터 내부에서
두번째 클러스터 외부에서 접근할 때

로드밸런서 역할을 하는게 서비스
파드가 더 많다. 왜냐하면

이전환경으로 가던 트래픽을 새로운 환경으로 가도록 할 수 있게 하는 건 : 셀렉터
파드들이 클러스터에 되게 많이 떠있겠죠 
라벨이 app:external되어있는 곳에 트래픽을 보내겠다. seleteor !
초반에는 v1으로 보내다가 새로운 애플ㄹ리케이션이 나오니까 얘를 바꿔치기 해주면 되겠죵
되게 손쉽게 이전환경으로 가던 트래픽을 v2로 손쉽게 트래픽을 바꿀 수 있다.
기본적으로 파드들 중에 어느 파드로 가야하는지 식별해서 갈 수 있도록 하는게
파드에 라벨이 설정되어있어야하고 서비스에는 selector로 찾고자하는 트래픽을로 갈 수 있게 해주는 매커니즘 이해

kubectl apply -f my-app-v2.yaml


카나리아는 실환경에서 테스트하는ㄱ서고
블루그린은 이전환경-이후환경 만들어놓고 테스트해서 문제가 없으면 새환경 만들어놓고 아예 새걸로 바꾸는 것

파드를 추상화 시켜주도록 하는게 서비스라고 한다.


카나리아 : 일부환경을 10퍼테스트해보고싶으면 이전버전 9개 신규버전 1개

무중단 배포 3가지
1. 블루그린
2. 카나리
3. 롤링업데이트
근데 1,2가 중요

오늘 한거 내용
새로운 버전으로 카나리아 -> 중단없이

클러스터IP는 클러스터 내부에서만 써서 외부에서 접근 불가능함.
외부에서 접근ㄹ하려면 노드포트라든지 노드밸런서 타입을 써야만 외부에서 접근할 수 있다.