Deployment 로 배포를 하고 있는 상태에서 관리할 수 있도록 하는 명령어들에 대해서 알아보겠습니다. rollout status kubectl rollout status deployment {Deployment 시스템 명} 명령어를 입력하여 현재 실행 중인 Deployment의 현재 상태를 확인할 수 있습니다. 그 전에 rollout 명령어를 적용하기 이전에 yml 설정을 변경해줘야하는 부분이 있습니다. Deployment 내용이 들어있는 Pod yml 파일에 들어가주도록 합니다. 거기서 우선 버전을 초기 버전인 release0 버전으로 바꿔주겠습니다. 그리고 minReadySeconds 설정값도 주석 처리 해주었습니다. 변경 사항을 적용해줍니다. 이제 다시 kubectl rollout status..

Deployment 는 Replica Set 중 하나 입니다. Replica Set에 기능 하나만 추가된 형태라고 보면 됩니다. Deployment 를 이용하면 가동 중지 시간 없이 자동으로 롤링 업데이트를 할 수 있습니다. 이전에 가동 중지 시간없이 Pod의 Label을 이용해서 수동으로 새로운 버전을 배포했었습니다. 이번에는 자동으로 가동 중지 시간없이 업데이트를 할 수 있는 Deployment 를 알아보겠습니다. https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#deployment-v1-apps Kubernetes API Reference Docs kubernetes.io Deployment의 yml 형식은 이렇습니다. 형식을..

Replica Set 작성이 완료되었으면 적용시켜야겠죠? 적용시켜보는 과정을 알아보겠습니다. 우선 kubectl delete pod --all 명령어를 사용하여 기존에 생성해서 실행중이던 pod들을 종료시켜줍니다. kubectl apply -f {yml 파일명} 명령어를 사용하여 작성했던 Replica Set 을 생성하고 적용시켜줍니다. 현재 Pod yml 에는 Replica Set 으로 변경하여 구성되어있습니다. kubectl get all 명령어를 입력했을 때 추가적으로 ReplicaSet 시스템이 실행중인 것을 확인할 수 있습니다. current 부분에 현재 실행중인 Replicas 의 수, 즉, 컨테이너 수를 알 수 있습니다. ready 부분은 요청에 응답하는 컨테이너의 수입니다. 이제 minik..

레이아웃을 설정하는 방법에는 여러가지가 있습니다. flex, grid, 외부 라이브러리, 부트스트랩, media query 등... 그 중에서 flex 는 유연하게 원하는 레이아웃을 설정해줄 수 있습니다. Flexbox Lorem ipsum dolor sit amet consectetur adipisicing elit. Temporibus eveniet minus dolor qui laudantium molestias repudiandae reprehenderit impedit aliquid, fugit eligendi placeat, unde praesentium, vel veritatis voluptate ex corporis magni deleniti. Ipsum id at ad quo neque ..

이번에는 Replica Set을 작성하는 방법을 알아보겠습니다. nano {pod yml 파일명} 명령어를 입력하여 pod 편집기로 들어옵니다. 작업을 하기 이전에 yml 파일의 편의성에 대해 잠깐 짚고 가자면, yml 파일 안에 여러 Pod들에 대한 내용을 전부 넣어 한번에 관리할 수 있습니다. Service.yml 의 경우에도 여러 Service들을 전부 넣어 한번에 관리할 수 있습니다. 다만 1000개 이상의 대량의 yml 내용들을 관리하게 된다면 비효율적이기 때문에 이렇게 대량의 경우에는 따로 분리하여 관리해야 합니다. Replica Set를 사용하여 기존의 Pod 를 업그레이드 시켜보겠습니다. 기존에 존재했던 webapp release0 버전을 삭제 후 진행하겠습니다. release0-5 버전의..

지금까지 Pod 를 생성하고 Service 를 생성하여 운영 및 관리하는 방식을 사용해보았는데 실제로는 이렇게 직접 Pod를 생성하고 운영하지 않는다고 합니다. 실무에서 자주 사용하는 방식 중 하나가 Replica Set 중 하나를 사용해서 운영하는 것이라고 합니다. Pod 를 직접 생성하고 운영하게 되면 Pod는 생명 주기도 짧을 뿐만 아니라 Pod가 망가지면 해당 Pod를 되살리는 것은 불가능합니다. 만약, 새벽에 운영 중인 시스템의 Pod 가 고장이 나거나 특정 node가 고장이 나면 전체적인 Pod들은 동작이 되지 않아 클레임이 오게 될 확률이 높습니다. 따라서 Pod를 직접 배포하지 않습니다. 이를 보완하기 위해서 Replica Set로 배포합니다. Replica Set는 구성 요소를 하나 더 ..