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..
1. Init Container Application 컨테이너 실행 전 미리 동작 시킬 컨테이너로, 본 컨테이너 실행 전 사전 작업이 필요한 경우 사용합니다. 그림과 같이 application을 실행하기 위해 DB - login 등으로 여러 작업이 선행되어야 하는 상황이라고 생각하면 됩니다. 이 때 필요한 컨테이너의 개수는 3개로, 우측 상단처럼 3/3으로 표시됩니다.(3/3으로 전부 잘 올라와야 application 정상 실행) 2. Static Container 이제까지는 생성한 pod들을 특정 worknode에 할당할 수 없었고, master node에 의해 자동으로 고르게 분배되어 올라갔습니다. 그러나 Static 컨테이너를 통해 특정 node에서만 실행하도록 pod를 지정해줄 수도 있습니다. S..
cordon과 drain은 필요에 의해 worknode를 사용 중지할 때, 혹은 작업을 한 쪽으로 넘겨야 할 때 사용하는 명령어입니다. 1. Cordon kubectl cordon worker2.example.com # worker2.example.com 노드를 중지 kubectl uncordon worker2.example.com # worker2.example.com 노드를 다시 Ready 상태로 돌림 worker2 노드를 cordon하고 kubectl get nodes 로 상태를 확인합니다. 다른 노드와 달리 "SchedulingDisabled" 로 상태가 바뀐 것을 알 수 있습니다. 지금부터 새로 run하는 pod는 모두 worker3으로 할당됩니다. cordon 후 새로 만든 webserver2..
Kubernetes에서 deploy로 만든 replicas set 개수를 조정하는 방식은 크게 세 가지가 있습니다. 우선 nginx 이미지를 가지고 web이라는 deploy를 하나 생성하겠습니다. 1. scale 명령어 이용 kubectl scale deployment [NAME] --replicas=[NUMBER] --replicas 옵션을 통해 원하는 만큼 replicas set 수를 늘리거나 줄일 수 있습니다. 줄어들 때는 최근에 만든 것부터 삭제됩니다. 2. yaml 파일 수정 kubectl get deployments.apps [NAME] -o yaml kubectl get deployments.apps [NAME] -o yaml > deploy.yaml # 생성한 해당 deploy에 대한 ya..
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..
- Total
- Today
- Yesterday
- RECA
- Vmware
- aws cli
- Google Cloud DNS
- IAM
- ycampus
- vsphere
- rocky9
- 클라우드 DNS 서비스
- EKS
- AWS
- Local Zones
- IAC
- kubectl
- Linux
- Route53
- Docker
- github
- Window Server Manager
- Git
- 에티버스러닝
- Azure DNS
- k8s
- kubernetes
- redhat
- VM Tools
- VPC
- Route53 비용 정책
- Windows Server
- Ansible
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |