[k8s] 4. 파드 운영

ㅎㅈㅈㅇ·2021년 6월 27일
0

Kubernetes

목록 보기
4/6

레이블 셀렉터

  • 레이블 셀렉터는 특정 레이블러 태그된 파드의 부분 집합을 선택하여 작업을 수행할 수 있게 한다
  • 레이블 셀렉터의 리소스 필터링
    • 특정한 키 포함/불포함 레이블
    • 특정한 키와 값을 가진 레이블
    • 특정한 키를 가지지만 다른 값의 레이블
  • 명령어
kubectl get po -l <LabelNameKey>=<LabelNameValue> // != 사용 가능
kubectl get po -l <LabelNameKey> // in (<LabelNameValue1>, <LabelNameValue2>), notin ...
kubectl get po -l '!<LabelNameKey>'

레이블의 활용

  • 워커 노드 레이블: 파드 스케줄링 제한
    • 일반적으로 파드를 어떤 노드에 스케줄링 하느냐는 중요하지 않다
    • 특별히, 스케줄링할 위치에 조건을 부여하고 싶은 경우에 노드 레이블과 레이블 셀렉터를 이용하는 방법이 있다
  • 명령어
kubectl label node <NodeName> <LabelNameKey>=<LabelNameValue> // Option ex) gpu=true
kubcel get nodes -l <LabelNameKey>=<LabelNameValue> // gpu=true


  • LabelNameKey는 대소문자 구분이 없는 듯하다.
  • 특정 노드에 스케줄링

  • 각 노드의 고유 레이블
    • 키: kubernetes.io/hostname, 값: 호스트 이름 <- 이것을 활용할 수는 있지만 노드가 오프라인인 경우 파드가 스케줄링되지 않을 수 있다

어노테이션

  • 특징
    • 키-값 쌍이지만 식별 정보를 갖지 않는다, 오브젝트 선택에 활용할 수 없다
    • 정보를 보유하기 위한 개념, 주로 도구들에서 사용, 새로운 기능을 추가할 때 흔히 사용
    • 파드나 오브젝트에 설명을 추가할 때 자주 쓰임 (작업자의 이름 따위를 추가하는 방식이 가능)
  • 명령어
kubectl annotate pod <PodName> <Annotation> // describe 명령으로 조회 가능

네임스페이스

  • 특징
    • 오브젝트를 겹치지 않는 그룹으로 분할, 오브젝트로 생성된 리소스의 이름은 네임스페이스 안에서만 고유하면 된다
    • 단 노드 리소스의 경우 전역(클러스터 수준)이며 네임스페이스로 구분되지 않음
  • 명령어
kubectl get ns
kubectl get po --namespace <NameSpaceName>
kubectl get po -n <NameSpaceName>
kubectl create namespace <NameSpaceName>
kubectl create -f <ResourceFile> -n <NameSpaceName>
  • 네임스페이스 격리의 이해
    • 오브젝트를 별도 그룹으로 분리해 특정 네임스페이스 안의 리소스를 대상으로 작업할 수 있게 해줌
    • 실행 중인 오브젝트에 대해 네임스페이스가 다른 오브젝트간의 통신을 격리하는 것은 네트워킹 솔루션에 따라 다르다

파드의 중지와 제거

  • 명령어
kubectl delete po <PodName>
kubectl delete po -l <LabelKey>=<LabelValue>
kubectl delete ns custom-namespace
kubectl delete po --all   //  파드를 자동으로 생성하는 레플리케이션 컨트롤러 고려
kubectl delete all --all    // 네임스페이스의 모든 리소스(rc, po, svc) 삭제, kubernetes 서비스도 삭제(잠시후 다시 생성됨)

레플리케이션과 그 밖의 컨트롤러

  • 파드의 안정적 유지
    • 노드의 kubelet이 파드 유지를 담당, 자가 치유
    • 크래시가 발생한 컨테이너를 캐치 및 자동으로 시작, 애플리케이션 외부에서 상태를 체크하고 에러 판단 및 재시작

라이브니스 프로브

  • 특징
    • 컨테이너가 살아 있는지 확인, 프로브를 주기적으로 실행하고 실패한 경우 컨테이너 재시작
    • kubectl describe로 출력되는 내용을 통해 재시작 로그를 확인할 수 있다 (Exit Code를 확인하여 오류에 대한 시그널 정보를 얻을 수 있다)
  • 컨테이너 프로브
    • HTTP GET 프로브
    • TCP 소켓 프로브
    • Exec 프로브
  • 추가 속성 설정
    • 애플리케이션 시작 시간을 고려해 초기 지연 설정할 것(initiallDelaySeconds)
    • timeout, period, #failure 설정 가능
  • 효과적인 라이브니스 프로브
    • 요청시 인증 필요 여부 체크
    • 외부 요인 영향 체크(예를 들어 DB)
    • 가볍게 유지(실행 시간, CPU 사용 시간)
    • 재시도 루프를 구현하지 않을 것

0개의 댓글