로그 포 로그

Liveness Probe는 Pod spec에 정의된, Pod가 계속 실행할 수 있도록 보장 하는 기능입니다. Self-healing 주기적인 80 포트 접속을 통해 Pod 상태를 확인하고 문제가 발생한 컨테이너를 reboot하도록 합니다. 따라서 현장의 모든 컨테이너에는 livenessProbe가 전부 포함되어 있습니다. (기존의 yaml 파일에 kunernetes.io/docs에서 긁어 온 livenessProbe: 하단 네 줄을 붙여넣으면 됩니다.) apiVersion: v1 kind: Pod metadata: name: liveness-pod # pod 이름 spec: containers: - image: smlinux/unhealthy # container 이름 name: unhealthy-co..

Pods 생성과 실행 kubectl create deployment [POD_NAME] --image=[IMAGE] kubectl run [POD_NAME] --image=[IMAGE] Pods 삭제 kubectl delete pods [NAME] # run으로 만든 단일 Pod 삭제 kubectl delete deployment [NAME] # deployments 삭제 kubectl delete all --all # 전체 Pods 삭제 kubectl delete pods [NAME] -n [NAMESPACE] # 특정 namespace의 Pod 삭제 Yaml 파일 kubectl run web --image=nginx -o yaml --dry-run=client > web.yaml # nginx 이미지..

1. 컨테이너 시스템이 가져온 변화 1-1. 컨테이너 시스템이 가져온 변화 Virtual Machine의 등장은 기존에 필요했던 하드웨어 비용을 크게 감소하는 효과를 가져왔고, 컨테이너의 등장은 언제 어디서든지 환경에 구애받지 않고 Application을 배포, 실행할 수 있는 확장성과 이식성을 크게 발전시켰습니다. 특히 VM과 달리 별도의 Guest OS가 필요하지 않아 빨라진 속도도 컨테이너 시스템의 큰 이점입니다. +) 그리고 이러한 컨테이너 시스템에서는 Linux 기반의 컨테이너 이미지 사용을 위해 U2L** 이 필요합니다. **U2L = Unix 시스템(Windows 등)을 Linux 시스템으로의 전환 1-2. public + private 하이브리드 시스템 구축의 필요성 Public Cloud..

1. 컨테이너의 개념 우리가 Application 개발을 한다고 생각해 보겠습니다. 사용 언어와 라이브러리를 포함해 많은 자원이 필요한데, 항상 개발 환경과 운영 환경이 일치하지 않기 때문에 다양한 문제가 발생할 수 있습니다. 소프트웨어의 규모가 커지고 복잡해질수록 문제는 심각해지는데, 이를 "Dependency Hell" 이라고 표현합니다. 어떤 소프트웨어를 설치하기 위해 다른 라이브러리 - 또 다른 라이브러리를 끊임없이 의존할 경우, 혹은 버전이 달라질 경우 의존성 지옥에 빠지게 되는데요, 이와 같은 Application 종속성 관리의 어려움을 해결하기 위한 대안이 바로 컨테이너입니다. 컨테이너의 기본 아이디어는 운영 환경 일치를 위해 가상화된 환경을 구축하는 것입니다. 어떤 환경에서나 실행 가능하도..