# 쿠버네티스 클러스터 쿠버네티스 클러스터는 크게 마스터 노드와 워커 노드로 나뉘어 진다. ## 생성된 마스터 노드 확인 ```shell kubectl get nodes ``` ## 오브젝트 세부 정보 가져오기 ```shell kubectl describe node ``` # Pod 기본적으로 쿠버네티스는 개별 컨테이너를 ***직접*** 다루지 않는다. 대신 Pod라고 하는 함께 배치된 다수의 컨테이너라는 개념을 사용한다. 각 Pod는 논리적으로 분리된 머신이다. (쿠버네티스는 Pod 또한 직접 생성하지 않는다. kubectl run을 이용해서 생성할 경우 ReplicationController를 생성하고, 이 ReplicationController가 파드를 생성한다.) 또한, Pod는 여러개의 컨테이너를 가질 수 있으며, 모든 컨테이너는 하나의 워커 노드에서 실행된다. (파드는 여러개의 컨테이너를 가질 수 있고, 컨테이너는 단일 프로세스를 실행하는 것을 목적으로 한다.) 만약 여러개의 컨테이너를 가진 Pod이 있다면 해당 Pod안의 컨테이너들은 동일한 리눅스 네임스페이스를 가지므로 동일한 네임스페이스, 호스트 이름, 네트워크 인터페이스를 공유한다. > 하지만 파일시스템은 다른 컨테이너와 완전히 분리된다. (참고로 Pod간의 통신에서는 다른 NAT 없이도 IP만으로 통신이 가능하다.) ## Pod 생성 ```yaml apiVersion: v1 kind: Pod metadata: name: pod-test spec: containers: - image: nginx/nginx name: nginx ports: - containerPort: 80 protocol: TCP ``` ```shell kubectl create -f .yaml ``` ports 부분이 있어야만 해당 포트가 열리는 것은 아니다. 명시적으로 나열함으로써 다른 사람의 이해를 돕기 위해서이다. ## Pod 조회 ```shell kubectl get pods kubectl descibe pod kubectl get po -o yaml ``` > Pod를 생성하면 스케쥴링되는데, 여기서 스케쥴링은 특정 노드에 할당됨을 의미한다. ## Pod Log 컨테이너화된 애플리케이션은 로그를 파일에 쓰기보단 `표출 출력`과 `표준 에러`에 로그를 남겨야한다. ```shell kubectl logs kubectl logs -c ``` ## Pod에 접근 Pod는 자체적으로 IP주소를 가지고 있지만, 이 주소는 클러스터 내부에 있어서 외부에서 직접적으로 접근이 불가능하다. 이를 위해 서비스 오브젝트가 필요하다.(LoadBalancer 등) ```shell kubectl expose rc --type = LoadBalancer --name kubectl get services ``` > Minikube는 로드밸런서 서비스를 지원하지 않으므로 minikube service 을 이용해 접근가능한 IP를 얻어야한다. 더 간단히 포트포워딩을 통해 연결할 수도 있다. ```shell kubectl port-forward 8888:8080 ``` ## Pod 삭제 방법들 ```shell kubectl delete po kubectl delete po -l key1=value1 kubectl delete po --all ``` ### 왜 서비스가 필요한가 파드는 언제든지 On/Off가 가능하다. 즉, 일시적이다. 파드는 켜지고 꺼질때마다 IP가 새로 생성된다. 이로 인해 항상 변경되는 파드의 IP주소로 통신하지 않는다. 서비스는 파드가 아니라 파드 그룹의 위치를 나타내고, 서비스가 받은 요청은 서비스에 속해 있는 파드 중 하나에게 전달된다. ## Pod의 수 늘리기 ```shell kubectl scale rc --replicas=3 ``` > 파드의 수를 추가하는 것이 아니라, 원하는 파드의 상태를 명시하는것이다. ## Label Label을 이용하면 파드와 다른 리소스들을 조직화하여 관리할 수 있다. ```yaml apiVersion: v1 kind: Pod metadata: name: pod-test labels: key1: value1 key2: value2 spec: containers: - image: nginx/nginx name: nginx ports: - containerPort: 80 protocol: TCP ``` ```shell kubectl get po --show-labels # 레이블 확인 kubectl label po key1=value2 # 레이블 변경 kubectl get po -l key1=value1 # 레이블 조건 조회 kubectl get po -l key1=value1,key2=value2 # 레이블 조건 조회2 (and) kubectl get po -l '!key1' # key를 가지고 있지 않은 pod kubectl get po -l "key1" # key를 가지고 있는 pod (value는 상관없다.) kubectl get po -l key1!=value2 # key1의 값이 value2가 아닌것. kubectl get po -l key1 in (value1, value2) # key1의 값이 value1, value2 둘중하나인지 kubectl get po -l key1 notin (value1, value2) # key1의 값이 value1, value2 둘다아닌지 ``` > 참고로 노드에도 Label을 붙일 수 있고, spec.nodeSelector를 통해 원하는 Node에 Pod 배치가 가능하다. ### Annotation 레이블말고도 키,값 쌍을 가지는 annotation을 가질 수 있다. 레이블과 비슷하지만 annotation은 식별정보를 가지지 않는다. meta.annotations에 명시한다.(annotation에는 label 보다 큰 256kb까지의 데이터를 넣을 수 있다.) ## Namespace 레이블은 하나의 Pod이 여러개를 가질 수 있다. 이로인해 겹치는 그룹이 생기게 되는데, 네임스페이스를 이용하여 문제를 해결할 수 있다. > 노드는 네임스페이스에 속해있지 않다. ```shell kubectl get ns # 전체네임스페이스 확인 kubectl get po -n default # default 네임스페이스에 속해있는 리소스 확인 ``` ### Namespace 생성 ```yaml apiVersion: v1 kind: Namespace metadata: name: mynamespace ``` ```shell kubectl create namespace mynamespace ``` ### namespace 사용 ```shell kubectl create -f .yaml -n mynamespace ``` ### namespace, 리소스 삭제 ```shell kubectl delete ns mynamespace kubectl delete all --all # 현재 네임스페이스에서 모든 유형의 리소스 모두 삭제(시크릿등의 특정 리소스는 그대로 있다.) ```

#scaling

HPA 그리고 Keda - 1