BEOM_IT

cloud를 다루지 않는사람들이 POD가 잘 살아있는지 정확하게 파악하기가 어려워 아래와 같은 스크립트를 작성하였다. kubernetes를 이용해 POD의 정보를 일괄 추출해 POD의 정보를 서비스별로 나눠 정상작동중인 POD를 불러오고 txt에 저장하는 스크립트를 작성하였다... 아래와 같은 스크립트를 매일 오전에 crontab에 걸어 지난 POD의 상태를 체크해볼예정이다.. ##divison.txt 서비스명 서비스코드 서비스명 서비스코드 서비스명 서비스코드 서비스명 서비스코드 ex)a서비스 Acode ## dir선언 후 dir 만들고 있다면 문자 출력 dir=result if [ ! -d $dir ] then mkdir /home/test/today/$dir else echo "Directory ex..

1. bash-completion 패키지 설치 yum install bash-completion -y 2. bash-completion 설치 완료 확인 kubectl completion bash 3. 자동 완성 스크립트 결과 저장 echo 'source

로컬에서 POD 안으로 복사 $ kubectl cp 디렉토리/파일이름 POD이름:디렉토리/파일이름 POD에서 로컬로 file 복사 $ kubectl cp namespace pod이름:디렉토리/파일이름 /옮길 디렉토리/파일이름 namespace와 pod이름 사이에 /를 넣으면 에러가 나서 띄어쓰기로 썼는데, 혹시 안되면 / 한 번 넣어보기 경로는 절대경로!!

각 컨테이너의 상태를 주기적으로 체크해서, 문제가 있는 컨테이너를 자동으로 재시작하거나 또는 문제 있는 컨테이너를 서비스에서 제외시킬 수 있다. 이러한 기능을 헬스 체크라고 하며 컨테이너가 살아 있는지 아닌지를 체크하는 Liveness probe, 컨테이너가 서비스가 가능한 상태인지를 체크하는 Readiness probe가 있다. Readniness probe는 Container 안의 어플리케이션이 서비스 할 준비가 되면 쿠버네티스에게 알리도록 설계 되어 있다. 서비스가 Pod로 트래픽을 보내기 전에 Readiness probe 검사 단계가 통과되어야만 해당 pod로 트래픽을 보내는 것을 의미한다. Liveness probe는 배포된 애플리케이션의 상태가 정상인지 비정상인지 여부를 판단하여 Kuberne..

EKS 오류시 1 CPU,MEM등 Pod의 상태를 확인한다. kubectl get hpa -A or kubectl top po -n [ns명] 2 k8s 이벤트를 확인한다. kubectl get event -n [ns 명] --sort-by='metadata.creationTimestamp' or kubectl describe po -n [ns명] [pod명] 3 JVM설정 확인 pod의 JVM은 Docker image의 시작 스크립트에 있으나 (CI/CD담당자역활)Heap 메모리의 사이즈는 Configmap에서 설정한다. ConfigMap 또한 CI/CD에서 진행하나 급하게 수정 할 때 담당자가 수정할 수 있다. 4 Pod 크기 변경 Jenkins job으로 Resources 사양을 변경 이 부분도 C..

retry on 설정이 없을시 retry attempt의 설정은 0으로 간주된다. 이는 retry 매커니즘의 동작방식에 따라 변경될수 있고 특정 시스템 or 프레임워크의 구현에 따라 다를 수 있습니다. 일반적으로 "retry on" 설정은 어떤 유형의 예외 또는 오류가 발생할 경우 리트라이를 시도해야 하는지를 지정하는 데 사용됩니다. "retry attempts" 설정은 리트라이를 시도할 최대 횟수를 지정합니다. 이러한 설정이 없으면, 리트라이 메커니즘은 기본적으로 활성화되지 않고 0으로 간주될 수 있습니다. 따라서, "retry attempts" 설정이 0이면, 리트라이가 전혀 이루어지지 않을 것입니다. 하지만 이는 구체적인 시나리오나 사용 중인 시스템에 따라 다를 수 있으므로, 정확한 동작을 확인하려..

쿠버네티스(Kubernetes)는 컨테이너 오케스트레이션(Orchestration) 툴로서, 컨테이너 기반 애플리케이션을 관리하기 위한 다양한 컴포넌트를 제공합니다. 쿠버네티스를 배포하면 클러스터가 생성된다. 컨트롤플레인 컴포넌트(Master) - 클러스터 전체를 관리 및 기능 실행 1. Kubernetes API 서버: 쿠버네티스 클러스터의 중심 컴포넌트로서, 쿠버네티스 클러스터 전체의 상태와 구성을 관리합니다. API 서버는 RESTful API를 제공하며, 다른 모든 쿠버네티스 컴포넌트와 상호작용합니다. - 사용자와 컨트롤 플레인과 통신하는 쿠버네티스 API 2. etcd: 쿠버네티스 클러스터의 구성 정보를 저장하는 분산 데이터 저장소입니다. 모든 쿠버네티스 노드에서 실행되며, 클러스터 전체의 구성..

개발자 -> git (형상관리)-> 배포 파이프 라인 ->git merge 승인 -> Jenkins의 pipeline을 호출 -> (두가지 방식) VM 배포) .jar 형식의 패키지 파일로 배포 될 VM 서버에 파일을 전송해 변경사항 적용 컨테이너 배포) build를 통해 생성된.jar 형식의 패키지 파일을 Dokerfile을 통해 어플리케이션 동작을 수행한 컨테이너 이미지 생성 -> 해당 이미지 파일에 버전 정보를 가지는 tag를 달아 Container Image Registy에 Release -> Registry 의 컨테이너 이미지는 yaml 파일을 통해 PaaS 환경에서 POD 형태로 배포 서버구분 VM PaaS(컨테이너) 배포단위 jar 패키지 파일 단위 배포 컨테이너 이미지 단위 배포 배포절차 ..