scaling과 rolling update, rollback(원상복구)
pod을 늘린다. 동일한 라벨을 주면 service가 알아서 똑같은걸로 인식
rolling update. 쿠버네티스에서는 하나하나 바꾼다. pod안에있는 어플리케이션의 상태까지 염두에 두고 해야해서 의미가 있는건 아닌데 하나씩 살아있는 pod들을 교체하는 rolling update
구르면서 업데이트한다. 하나 띄우고 하나 죽이고
이거해도 어플리케이션 돌아가고 있는거 죽이고 업데이트하면 의미없다 끊긴다
죽이는건 조심해야한다.
파일을 열었는데 안닫으면 저장은 안될수있는것처럼
kubectl�scale�deployments/kubernetes-bootcamp�--
replicas=4
desired state를 변경
clusterIP는 디버그 용도
curl minikube ip동작하지 않음
minikube service쓰기
통계적으로 분산하는거지 배칭은 아니다.
flush 당장 디스크로 내보내라 당장 네트워크로 내보내라 등 명령
update deployment from v1 to v2
pod이미지들이 교체됨 ⇒ update
한방에 업데이트하는게 아니라 rolling update해줌
Rolling back to previous version
rollout history 업데이트한거에 대한 기록을 보여달라.
첫번째껀 revision=1이 됨
쿠버네티스에서 pod을 실행할때 최초는 revision=1
버전별로 확인할 수있음.
rollback 과거버전으로 돌아가는것
scaling up은 쉽다 back은 힘들다
오픈소스 중에서 순서대로 다운로드해야하는게 있었다면? 특정 소프트웨어 버전이 기억 안난다거나 하면
옛날버전이 돌아갔어서 rollback했는데 환경이 달라져서 에러가 발생한 경우가 있다
이전의 이전으로 돌아가야하는 경우가 있다
그래서 보통 모든 버전을 다 가지고 있고 repository에
숨어있었던 문제가 왜 나온건지 알려면 뭘 변경했는지 기록해야하기 때문
몇년 몇분기에 출시했던걸로 돌아가고 싶다 등의 요청
맥os는 백업시스템이 있다 원래 서버였기 때문에 타임머신 누르면 원하는 폴더에 자동으로 끌어올린다
원래 서버에서는 과거로 회귀하는게 일반적인 작업이다
특정지점으로 이동하라는 행위를 한다.
