시작하세요 도커,쿠버네티스#6 쿠버네티스(KUBERNETES)
흑... 노션에서 그대로 옮기는 건, 너무 무리한 작업인 거 같다... 좀 더 효율적인 방법이 없을까
쿠버네티스
쿠버네티스 전체 개요
오브젝트
오브젝트 목록 확인
kubectl api-resources
특정 오브젝트 설명
kubectl explain pod
포드 생성
kubectl apply -f nginx-pod.yaml
포드 확인
kubectl get pdos
포드 정보 확인
kubectl describe pods {PODS_NAME}
포드 컨테이너 내부 확인
kubectl exec -it my-nginx-pod bash
포드 로그 확인
kubectl logs my-nginx-pod
포드 삭제
kubectl delete pod {POD_NAME}
🐋 YAML 파일에서 - 를 쓰는 건 여러 개의 하위항목이 있음을 의미
컨테이너 접속
kubectl exec -it my-ngnix-pod -c ubuntu-sidecar-container bash
여러 개 리소스 정의
한 번에 여러 개 포드를 생성하는 것은 비효율적인 작업이다.
포드가 생성된 노드에 장애가 생겨도 포드는 다른 노드에서 생성되지 않는다.
Replicaset
- 정해진 수의 동일한 포드가 항상 동일하게 관리합니다.
##### YAML 작성법 #####
spec.replicas = 동일한 포드를 몇 개 유지할 건지 설정
spec.templates = 포드를 사용할 때 생성할 templates를 정의
설정된 label의 리소스 필터링
kubectl get pods --show-labels
kubectl get pods -l app
kubectl edit
kubectl edit pods {PODNAME} YAML에서 지정하지 않은 옵션까지 확인할 수 있다.
K8S 좀비 클러스터 지우는 법
잘못해서 한 번 만든 k8s 클러스터가 지워지지 않는다… !
그럴 때는,
IAM에서 액세스 관리 → 역할에서 k8s master node / k8s worker node를 지우고 ec2에서 인스턴스를 종료하면 다시 살아나지 않는다 !!
Deployment
🐋 레플리카셋으로 마이크로서비스 구조의 컨테이너를 구성할 수 있을 것 같지만, ”레플리카셋과 포드의 정보를
디플로이먼트(DEPLOYMENT)라는 오브젝트에 정의한다.”
Deployment의 yaml 예시
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: my-nginx
template:
metadata:
name: my-nginx-pod
labels:
app: my-nginx
spec:
containers:
- name: nginx
image: nginx:1.10
ports:
- containerPort: 80
디플로이먼트 삭제
배포하는 레플리카셋과 파드가 삭제된다.
kubectl delete deploy my-nginx-deployment
디플로이먼트 업데이트
디플로이먼트를 사용하는 이유
🐋 “애플리케이션 업데이트와 배포를 편하게 하기 위해서이다.”
업데이트 시, 레플리카셋의 변경 사항을 저장하는 리비전(revision)을 남겨 롤백 가능하게 해주고, 무중단 서비스시 포드의 롤링 업데이트의 전략을 지정할 수 있다.
어플리케이션 버전 업데이트
kubectl apply -f deployment-nginx.yaml --record
이미지 변경 업데이트 시
kubectl set image deployment my-nginx-deployment nginx=nginx:1.11 --record
리비전 정보
🐋 “디플로이먼트는 포드의 정보가 변경되어 업데이트 발생 시 → 이전의 정보를 저장한다.”
리비전 정보를 열람
kubectl rollout history deployment my-nginx-deployment
record true 옵션으로 디플로이먼트를 변경하면 변경 사항을 저장, 해당 버전의 레플리카셋을 보존
리비전 롤백 시
이전 버전의 리비전으로 롤백 시 --to-revision에는 되돌리려는 리비전의 번호를 입력
kubectl rollout undo deployment my-nginx-deployment --to-revision=1
디플로이먼트 정보 출력
kubectl describe deploy my-nginx-deployment
서비스(Service)
포드의 IP를 확인하는 방법
kubectl get pods -o wide
서비스의 종류
- Cluster IP 타입 : 쿠버네티스 내부에서만 포드들에 접근할 때 사용, 외부로 포드를 노출하지 않기 때문에 쿠버네티스 클러스터 내부에서만 사용하는 포드에 적합.
- NodePort 타입 : 포드에 접근할 수 있는 포트를 클러스터의 모든 노드에 적용, 외부에서 포드를 접근할 수 있는 서비스 타입.
- LoadBalancer 타입 : 클라우드 플랫폼에 제공하는 로드 밸런스를 동적으로 프로비저닝하여 포드에 연결. NodePort 타입과 마찬가지로 외부에서 접근 가능한 서비스. 일반적으로 AWS, GCP 등과 같은 클라우드 플랫폼 환경에서만 사용 가능.
🐋 포드를 내부에서만 접속하고 싶다. → Cluster IP 외부에서도 포드를 접근하고 싶으면 → NodePort 실제 운영 환경
→ LoadBalancer
ClusterIP 타입의 서비스
YAML 파일 형식
apiVersion: v1
kind: Service
metadata:
name: hostname-svc-clusterip
spec:
ports:
- name: web-port
port: 8080
targetPort: 80 //포드 템플릿과 같은 포트 아이피 필요
//Ip:8080-> Container port 80
selector:
app: webserver
type: ClusterIP //서비스가 어떤 타입인지 ClusterIP/ NodePort /LoadBalancer
Cluster IP 개요
NodePort 타입의 서비스
YAML 파일 형식
apiVersion: v1
kind: Service
metadata:
name: hostname-svc-nodeport
spec:
ports:
- name: web-port
port: 8080
targetPort: 80 // PublicIP:~~ -> ServicePort 8080 -> Container port 80
nodePort: ~~ // nodePort의 포트번호를 지정할 수도 있다. 보통은30000 ~ 32768 사이
selector:
app: webserver
type: NodePort
NodePort 개요
🐋 NodePort는 자동으로 ClusterIP 또한 생성하여, 내/외부 네트워크를 통해 접근 가능하다 !
LoadBalancer 타입의 서비스
YAML 파일 형식
apiVersion: v1
kind: Service
metadata:
name: hostname-svc-lb
spec:
ports:
- name: web-port
port: 80
targetPort: 80
selector:
app: webserver
type: LoadBalancer
서비스 생성 시 → External-IP 항목이 추가 , port 번호와 같이 사용하여 서비스에 접근
LoadBalancer 개요
서비스 삭제
이전 버전의 리비전으로 롤백 시 --to-revision에는 되돌리려는 리비전의 번호를 입력
kubectl rollout undo deployment my-nginx-deployment --to-revision=1
디플로이먼트 정보 출력
kubectl describe deploy my-nginx-deployment
서비스(Service)
포드의 IP를 확인하는 방법
kubectl get pods -o wide
서비스의 종류
- Cluster IP 타입 : 쿠버네티스 내부에서만 포드들에 접근할 때 사용, 외부로 포드를 노출하지 않기 때문에 쿠버네티스 클러스터 내부에서만 사용하는 포드에 적합.
- NodePort 타입 : 포드에 접근할 수 있는 포트를 클러스터의 모든 노드에 적용, 외부에서 포드를 접근할 수 있는 서비스 타입.
- LoadBalancer 타입 : 클라우드 플랫폼에 제공하는 로드 밸런스를 동적으로 프로비저닝하여 포드에 연결. NodePort 타입과 마찬가지로 외부에서 접근 가능한 서비스. 일반적으로 AWS, GCP 등과 같은 클라우드 플랫폼 환경에서만 사용 가능.
<aside> 🐋 포드를 내부에서만 접속하고 싶다. → Cluster IP 외부에서도 포드를 접근하고 싶으면 → NodePort 실제 운영 환경 → LoadBalancer
</aside>
ClusterIP 타입의 서비스
YAML 파일 형식
apiVersion: v1
kind: Service
metadata:
name: hostname-svc-clusterip
spec:
ports:
- name: web-port
port: 8080
targetPort: 80 //포드 템플릿과 같은 포트 아이피 필요
//Ip:8080-> Container port 80
selector:
app: webserver
type: ClusterIP //서비스가 어떤 타입인지 ClusterIP/ NodePort /LoadBalancer
Cluster IP 개요
NodePort 타입의 서비스
YAML 파일 형식
apiVersion: v1
kind: Service
metadata:
name: hostname-svc-nodeport
spec:
ports:
- name: web-port
port: 8080
targetPort: 80 // PublicIP:~~ -> ServicePort 8080 -> Container port 80
nodePort: ~~ // nodePort의 포트번호를 지정할 수도 있다. 보통은30000 ~ 32768 사이
selector:
app: webserver
type: NodePort
NodePort 개요
🐋 NodePort는 자동으로 ClusterIP 또한 생성하여, 내/외부 네트워크를 통해 접근 가능하다 !
LoadBalancer 타입의 서비스
YAML 파일 형식
apiVersion: v1
kind: Service
metadata:
name: hostname-svc-lb
spec:
ports:
- name: web-port
port: 80
targetPort: 80
selector:
app: webserver
type: LoadBalancer
서비스 생성 시 → External-IP 항목이 추가 , port 번호와 같이 사용하여 서비스에 접근
LoadBalancer 개요
서비스 삭제
kubectl delete -f hostname-svc-lb.yaml