1. apiVersion : 패키지 이름과 비슷한 역할, 리소스의 Scope를 정의한 것
2. kind: 클래스와 비슷한 역할, 리소스 타입 정의
3. metadata: 리소스의 메타정보
- Label: 라벨 정보
- Name: 리소스 이름
- Spec: 리소스 스펙
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: myngix
name: myngix
spec:
containers:
- image: ngix
name: myngix
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
[Pod 생성 순서]
1. 사용자가 명령을 통해 Pod에 대한 정의를 쿠버네티스 마스터에 전달
2. 쿠버네티스 마스터는 YAML 정의의 유효성 체크 후 특정 노드에 컨테이너를 실행하도록 명령
3. 명령을 전달받은 노드는 실제 컨테이너를 노드에 실행
라벨 자체로는 큰 기능은 없다. 단순한 Key,Value 형태의 문자열이다.
Pod에 라벨을 부여한다 -> Key,Value 형태의 문자열을 Pod의 metadata property에 추가 한다는 것
kubectl label pod <NAME> <KEY>=<VALUE>
hello=world라는 라벨이 추가된 것을 볼 수 있다.
2. 선언형 명령을 이용하는 방법
ubuntu@master:~$ kubectl get pod myngix -L run
라벨링 시스템을 이용해 Pod이 특정 노드에 할당되도록 스케줄링 할 수 있다.
기본적으로는 사용자가 Pod을 생성하면 쿠버네티스 마스터가 노드를 결정하여 스케줄링한다.
쿠버네티스는 클러스터 시스템이므로, 매번 노드를 선택할 필요없이 쿠버네티스가 Pod 스케줄링 관리.
하지만 만약 A노드는 디스크가 SSD로 설정되어 있고 B노드는 HDD로 설정됐다면,
특정 Pod에 한해서 SSD 디스크를 사용해야 한다. 이럴 경우 Node Selector를 이용
#vi cmd.yaml
apiVersion: v1
kind: Pod
metadata:
name: cmd
spec:
restartPolicy: OnFailure
containers:
- name: nginx
image: nginx
command: ["/bin/echo"]
args: ["hello"]
- Command: 컨테이너 시작 실행 명령 지정
- args: 실행 명령에 넘겨줄 파라미터 지정
- restartPolicy: Pod의 재시작 정책
- Always: Pod 종료시 항상 재시작(Default)
- Never: 재시작 시도 X
- onFailure: 실패 시에만 재시작
cmd 파일을 실행하면, hello를 출력하는 쉘 스크립트로 바뀐 것을 확인할 수 있다.
env property를 사용하여 환경변수 설정
env -> name : 환경변수의 key
env -> value : 환경변수의 value
exec 로 실행중인 env Pod에 명령 전달
Pod의 내부 스토리지의 생명주기는 Pod이 사라지면 저장된 데이터도 삭제된다.
Pod의 생명주기와 상관없이 지속적으로 데이터를 저장하려면
-> 볼륨 연결
volumeMounts와 volume이 같은 level(들여쓰기)에 있으면 오류 발생!
1. volumeMounts: 컨테이너 내부에 사용될 볼륨
- mountPath: 컨테이너 내부에 볼륨이 연결될 위치 지정
- name: volumeMounts와 volumes를 연결하는 식별자
2. volumes: Pod에서 사용할 볼륨
- name: volumeMounts와 volumes를 연결하는 식별자
- hostPath: 호스트 서버의 연결 위치를 지정