kubernetes Object 기본 정리

Object 기본 정리

Pod - Container, Label, Node Schedule

• Container
  • 하나의 독립적인 서비스 구동 가능
  • 한 컨테이너가 하나 이상의 포트를 가질 수 있지만 중복되는 포트는 가질 수 없다.
  • 한 컨테이너에서 다른 컨테이너로 접근할 떄에 포트를 통해 접근 가능
  • 참고로 파드 IP 는 쿠버네티스 클러스터 내에서만 접근 가능하고, 휘발성이 있다(재생성시 변경)
• Label
  • 모든 오브젝트에 달 수 있는데, 파드에서 가장 많이 사용된다.
  • 목적에 따라 오브젝트를 분류하고 그 분류된 오브젝트들만 따로 골라서 연결하기 위함
  • key - value 쌍이고 한 파드에는 여러개의 라벨을 달 수 있다.
  • 뭐 type-web / io-dev 이런 식으로 구분 가능하도록 할 수 있음
• Node Schedule
  • 파드는 결국 여러 노드 중 한 노드에 올라가야 한다
  • 내가 선택하는 방법 / 쿠베가 선택해주는 방법
  • 각 파드에 라벨을 단 것 처럼 노드에 라벨을 달고 파드를 만들 때에 노드를 선택할 수 있다.
    • NodeSelector 에 넣어주면 됨
  • 쿠버네티스 스케쥴러가 판단
    • 노드 별로 전체 사용 가능한 자원 량이 있는데 그에 맞춰서 쿠버네티스가 해줌
  • 참고로
    • memory : 넘기면 pod 종료
    • CPU : 초과시 request 로 낮춤

Service - ClusterIP, NodePort, LoadBalancer

• ClusterIP
  • cluster 내에서만 접근 가능
    • 외부에서는 접근이 안된다.
  • 파드 ip로도 접근이 되기는 한데, 이 파드 ip 는 죽었다 부활하고 하면 변경되기 때문에 service 로 사용한다.
  • 가장 기본 type
  • 얘는 보통 클러스터 IP 를 통해 접근할 수만 있어서 인가된 사용자만 사용 가능
    • 내부 대쉬보드
    • Pod 의 서비스 상태 디버깅
• NodePort
  • node 의 ip 로 접근하면 얘가 service 로 트래픽을 보내고 그 service가 다시 node 내에 있는 pod 로 전달해주는 방식
    • 참고로 랜덤으로 보내기는 한데... externalTrafficPolity 를 Local 로 두면 최초로 접근한 노드 내로 간다.
  • 노드포트는 30000 ~ 32767 사이
  • 이거는 물리적인 호스트의 IP 를 통해 접근할 수 있는데, 보통은 이 애들은 내부망에서만 접근이 가능하도록 설정하는 경우가 많다.
    • 클러스터 밖에 있지만 그래도 내부망에서 접근할 때 사용한다.
      • 간단하게 보여주는 용도로 사용
• Load Balancer
  • 앞의 NodePort 와 비슷한데 이거는 밖에 LoadBalancer 가 따로 있어서 얘가 node 로 보내준다.
    • 근데 Load Balancer 의 경우는 플러그인이 따로 필요하다.
      • AWS, GCP, Azure 등 사용하면 기본적으로 제공된다.
  • 실제로 외부에 서비스를 노출시키기 위해서 이를 사용
    • 내부 IP 를 노출시키지 않고 외부 IP를 통해서 사용
  • 즉 외부에 서비스 사용할 때는 이를 쓴다.

Volume - emptyDir, hostPath, PVC / PV

• emptyDir
  • 컨테이너들끼리 데이터를 공유하기 위해 볼륨을 사용하는 것
  • 항상 볼륨이 최초에 사용될 때에는 비어있기 때문에 emptyDir 이라고 명시되는것
  • 두개의 서버가 하나의 volume 에 mount 되어 있으면 따로 파일을 주고받을 필요 없이 자신의 로컬 파일처럼 편하게 사용 가능하다.
  • 볼륨은 파드 안에 생성되기 때문에 파드가 삭제되면 같이 삭제된다.
    • 그래서 이 볼륨 안의 데이터는 꼭 일시적인 사용 목적에 의한 데이터만 넣는 것이 좋다.
• hostPath
  • 각 node의 path 를 사용한다.
  • 여러 파드들의 node 내부의 볼륨을 따로 사용한다.
    • 그래서 같은 노드 내에 배치한다면 파드가 죽어도 데이터가 사라지지 않는 장점이 있기는 하다.
      • 근데 문제가 있는데, 만약 파드 중 하나가 죽은 후 재생성 될 때 다른 노드에 파드를 만들게 되면 기존 노드에 있던 볼륨을 마운트할수 없게 된다.
        • 노드가 추가될 때마다 node 의 path 끼리 마운트를 해주는 것도 가능은 하다. 근데 굳이 이렇게 하기는 좀 그럼
  • 각각 노드에는 기본적으로 자신을 위해서 사용되는(시스템 파일이나 여러 파일 등) 파일이 있는데 파드 자신이 할당되어 있는 호스트의 데이터를 읽거나 써야 할 때 사용하면 된다.
• PVC / PV
  • 파드의 영속성 있는 볼륨을 제공하기 위한 볼륨
  • 로컬도 있기는 한데 외부 원격 볼륨도 가능함
    • 이런 영속적인 볼륨들을 PV(Persistent Volume)이라고 한다.
  • 근데 파드에서 이런 볼륨들에 바로 연결하는게 아니라 뭔가 하나를 통함
    • 그게 바로 PVC(Persistent Volume Claim) 이다.
      • 즉 PVC는 Pod 에서 요청하는 볼륨 리소스이고 실제 Storage 는 PV 가 제공한다.
      • 쿠버네티스는 볼륨 사용에 있어서 User / Admin 영역을 나눔
        • Admin - 쿠버네티스 운영자
          • PV, Volume
        • User - 파드의 서비스 만들고 배포를 만드는 서비스 담당자
          • Pod, PVC

ConfigMap, Secret

Dev, Prod 간에 SSH, User, Key 가 바뀌어야 한다.
그런데 그를 위한 이미지를 다르게 가져가야 하는데, 이 값 떄문에 이미지를 별도로 관리하느건 부담되는 일이다.
그래서, 이를 외부에서 할 수 있도록 도와주는 것들이 ConfigMap 과 Secret 이다.

• ConfigMap
  • 내가 분리해야 하는 일반적인 상수들을 모아서 만듬
• Secret
  • 보안적인 관리가 필요한 것들
• 파드 생성 시 두개를 연결할 수 있다.

이것들을 만드는 방법은 3가지 있다.

• Env(Literal)
  • 상수를 그냥 넣어주는 것
  • 파드를 생성할 때에 저것들을 가져와서 만들어 준다.
  • 참고로 secret 은 메모리에 저장되고 데이터에 한계가 있다.
  • key - value
• Env(File)
  • 파일을 통으로 담는것
  • 파일 이름이 key, 내부 내용이 value
  • 참고로 secret은 만들 때 알아서 base64 코딩이 된다. 두번 되지 않도록 주의.
  • 참고로 환경 변수(Env 방식)은 한 번 설정한 것은 파드를 재생성하지 않으면 기존 파드에서 수정이 안됨
    • 파드가 죽은 후 부활해야 수정 가능
• Volume Mount(File)
  • 파일 마운트 하는거
  • 파드를 만들 떄에 mount path 를 정의할 수 있다.
  • 요거는 마운트를 통해 가져오는 것이기 때문에 값이 변경되면 pod 부활 없이도 바로 적용이 가능하다.

Namespace, ResourceQuota, LimitRange

쿠버네티스 클러스터에는 전체 사용할 수 있는 자원이 있다.
메모리, CPU 등의 자원
그래서 각각의 namespace 에는 여러 파드를 만들 수 있다.
각 파드는 필요한 자원을 클러스터 내의 자원을 공유해서 쓰는데, 만약에 한 파드에서 전부 써버리면 다른 파드에서는 사용할 수가 없다.
이런 문제 해결을 위해 Resource Quota 가 존재해서 각 namespace 마다 최대 한계를 정할 수 있다.
하나의 파드에서 문제가 있기는 해도 다른 namespace 에서의 문제는 없다.
근데 한 파드에서 너무 사용량을 크게 하면 그 namepspace 에 들어갈 수 없는데, limitRange 를 통해 한 pod 가 namespace 에 들어가도록 제한 가능
파드 뿐 아니라 클러스터에도 가능하다.

• namespace
  • 한 namespace 내에서 pod 의 이름은 중복이 불가능하다.
  • 타 네임스페이스의 자원과는 분리되어 관리된다.
    • 즉, 어떤 namespace 의 service 가 다른 namespace 의 pod에 접근이 안되는거
  • namespace 를 지우면 그 내부의 자원들이 다 지워진다.
• ResourceQuota
  • 네임스페이스의 자원 한계를 설정
  • 제한하고 싶은 자원을 적어서 설정 가능
  • ResourceQuota 에 제한된 것을 만들어 줬다면 내부의 pod 들에도 그 내용을 작성해 줘야 한다.
• LimitRange
  • 각 파드마다 네임스페이스에 들어올 수 있는지 자원을 체크해 준다.