ip address안쓴다 라벨을 쓴다
컨트롤러 desired state작성하는게 인간의 몫
쿠버네티스 안에 잇는 컨트롤러들이 처리한다
pod이란? 하나의 단지 안에 담겨서 움직이는 컨테이너들과 storage 등
라벨 - yaml파일도 label이다 key와 value
spec: 내가 실행시킬 pod의 spec
pod의 이름은 = metadata
쿠버네티스의 pod은 c++의 클래스와 굉장히 비슷함
pod으로 만들어지는것들을 object라고 한다. kind = class
kind: pod 클래스가 pod이다
spec은 pod안에 뭐가 돌아갈거냐
apiVersion은 쿠버네티스가 서버끼리 호출해가면서 작업하기 때문에 api버전이 있다.
라벨: 내가 특정 컨테이너나 pod을 묶어서 용도 등 지정
특정 노드들을 묶어서 어떤 용도로 쓸지
운영을하는거다 실제 쿠버네티스에서 운영하려면 장애가 발생하고 죽고 살고 한다
프로그램 실행되면 끝나니까 mortal하다고 할수도 있지만 그거외에도 장애발생해서 죽는다 어디서 돌아가는지도 모르고 물리적인 정보를 가지고 pod을 구분하면 안됨 그래서 label을 쓴다. 살아있을수도 있고 죽을수도 있는거고 새로 실행해도 같은 pod이 아니다.
앞에있는 서비스가 뒤에있는 pod을 식별하기 위해서 label을 쓴다
동일한 yaml파일에서 만들어진거다 service는 요청왔을때 누구에게 줘야하지? label로 식별한다. ip는 죽고 살고하면서 바뀌니까. 3개에 로드밸런싱으로 준다
ReplicaSet
desired state에 의해 요청된 pod의 복제를 유지한다. replicaset controller
우리는 실행해야하는 pod의 명세서를 주고 개수를 주고 어떻게 부를지에 대해 명시
만들어진 pod가지고 replicase:3 3개 만들어라
apiVersion apps/v1
kind: ReplicaSet
my-little-pod에서 spec의 내용들이 동일하게 들어있음
중간에 있는 개수와 matchLabel
밑에있는 spec을 하나의 묶음으로 봐서 3개 실행
replica Controller가 보고 만들 걸 준다
ip address는 쓰지 않는다
enviroment in production,qa 개발환경이 production인 경우에만 지정
프로그램같이 명세서에 적을 수 있다
다양한 환경, 운영체제, cpu 등 구분하면서 하나하나 실행할수 있다
replication controller app:nginx로 식별
pod이 3개일때 앞쪽에 있는 애는 ip주소에 관심없고 label로 식별되면 그냥 걔들한테 던지는거.
replication controller가 3개를 띄우고 죽으면 다시 새로운거 만들어서 대체하는 역할.
죽어있는 애를 다시 하나 더 만들어서 숫자를 채우는 작업도 하지만
사용자의 요구가 service로 오고있고 3개의 pod을 띄웟꼬 서비스가 되고잇는데
회색으로 되어있는 컨테이너를 업그레이드했다. 그럼 replicat cotnroller에게 적어서 업데이트하도록 요구할 수 있다 새롭게 만든녹색으로 업그레이드해달라고
그런데 사용중인 중에 업데이트하려면 죽는데?
녹색으로 3개가 떠있는걸로 원한다고 하면 replica controller는 내가 원하는거 인지하고 녹색 하나 만들고 회색 하나 죽이고 녹색 하나 더 만들고 회색 죽이고 이런식으로 작업한다. 3개인 상태를 유지하면서 기존의 컨테이너를 하나하나 교체한다 rolling update. 해줄수 있는건 이미지 교체고 컨테이너 안에 있는 것과 상관없을것까지만 rolling update해주는거고 컨테이너 안에있는것까지는 스무스하게 못해줌
신규로 오는 traffic은 옛날 pod에 주지말라고 하고 모니터링하다가 기존에 있는 pod의 연결이 끊어지면 죽이고 따른애를 킨다.
엄청난 대규모 서버를 업데이트하는 작업은 몇달에 걸쳐서 일어난다 인간이 개입해서 하기가 어렵다. 회사에서 서버가 터졌으면 내가 ssh로 접속해서 보안상에서 작업할수 있으면 편한거고.
라즈베리 파이 4대 두고 서버풀이라고 생각하고 해보는것도 괜찮다 원격으로 쿠버네티스로 묶어가지고
rust를 잘쓰려면 c++잘해야하고 rust는 운영체제 임베디드 서버 네트워킹에 강한애
좀 fundamental한걸 다시 짜거나 이미 있는애들을 쪼개보는게 좋을수있다
프론트에서도 fundamental을 만들어보자 webgl이나 webgpu로 라이브러리 만든다던가
정해진 명세에 따라 pod을 만들고 docker-compose와 큰차이는없고
c++객체의 개념이라고 생각하면 편하다. pod하나를 만드는게 목적은 아니고 pod에 대한 정보를 주고 쿠버네티스에 주면 replica controller가 실행해주는거고
죽여도 살아난다 더 재밌게 하려면 raspberry pi전원 하나 빼버리면 얼마만에 알아낼까 얼마나 빠르게 복원할까
왜 web assembly가 있었으면 docker를 만들지 않았을거라고 할까?
더 작은 wasm으로 만든 서버는 더 빨리 띄울수있다 그럼 굳이 컨테이너를 사용할이유가 없는것 더 빨리 살릴수있다 죽은걸
결론 pod은 yaml파일이고 replica controller가 띄워준다
rolling update직접해보는것도 나쁘지 않다.
pod만 죽이지 말고 node를 죽여보는것도 좋은경험
