🍳머리말
kubernetes에서 자주쓰는 용어 설명글
📕cluster
container화된 app을 실행하는 node입니다.
여기에 여러 node가 담길 수 있습니다. node에는 여러 pod가 존재할 수 있고 하나의 pod안에는 여러 container가 있을 수 있습니다.
📔 node
노드는 쿠버네티스에서 워커 머신을 말하며 클러스터에 따라 가상 또는 물리 머신일 수 있습니다. 각 노드는 컨트롤 플레인에 의해 관리된다. 하나의 노드는 여러 개의 파드를 가질 수 있고, 쿠버네티스 컨트롤 플레인은 클러스터 내 노드를 통해서 파드에 대한 스케쥴링을 자동으로 처리한다. 컨트롤 플레인의 자동 스케줄링은 각 노드의 사용 가능한 리소스를 모두 고려합니다.
모든 쿠버네티스 노드는 최소한 다음과 같이 동작합니다.
- Kubelet은, 쿠버네티스 컨트롤 플레인과 노드 간 통신을 책임지는 프로세스이며, 하나의 머신 상에서 동작하는 파드와 컨테이너를 관리.
- 컨테이너 런타임(도커와 같은)은 레지스트리에서 컨테이너 이미지를 가져와 묶여 있는 것을 풀고 애플리케이션을 동작시키는 책임을 맡음.
📔 pod
파드는 언제나 노드 상에서 동작합니다.
파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커와 같은)들의 그룹을 나타내는 쿠버네티스의 추상적 개념이며 비영구적 자원입니다. 관리와 networking 목적으로 존재하며 일부는 컨테이너에 대한 자원을 공유합니다. 자원은 아래 3가지 입니다.
- 볼륨과 같은, 공유 스토리지
- 클러스터 IP 주소와 같은, 네트워킹
- 컨테이너 이미지 버전 또는 사용할 특정 포트와 같이, 각 컨테이너가 동작하는 방식에 대한 정보
파드는 특유한 "로컬호스트" 애플리케이션 모형을 만들어. 상대적으로 밀접하게 결합되어진 상이한 애플리케이션 컨테이너들을 수용할 수 있습니다. 가령, 파드는 Node.js 앱과 더불어 Node.js 웹서버에 의해 발행되는 데이터를 공급하는 상이한 컨테이너를 함께 수용할 수 있습니다. 파드 내 컨테이너는 IP 주소, 그리고 포트 스페이스를 공유하고 항상 함께 위치하고 함께 스케쥴링 되고 동일 노드 상의 컨텍스트를 공유하면서 동작합니다.
파드는 쿠버네티스 플랫폼 상에서 인식가능한 최소 단위가 됩니다. 우리가 쿠버네티스에서 배포를 생성할 때, 그 배포는 컨테이너 내부에서 컨테이너와 함께 파드를 생성한다. 각 파드는 스케쥴 되어진 노드에게 묶여지게 된다. 그리고 (재구동 정책에 따라) 소멸되거나 삭제되기 전까지 그 노드에 유지됩니다. 노드에 실패가 발생할 경우, 클러스터 내에 가용한 다른 노드들을 대상으로 스케쥴되어집니다.
pod는 비영구적 자원으로 고유한 IP 주소를 갖지만, deployment에서는 한 시점에 실행되는 파드 집합이 잠시 후 실행되는 해당 파드 집합과 다를 수 있습니다. 즉, 유동적인 ip를 갖습니다.
📔 deployment
deployment : pod의 health를 검사해서 pod의 container가 종료되었다면 재시작해줍니다. pod의 생성 및 scaling을 관리하는 방법으로 권장되는 방법입니다.
📔 namespace
가상 클러스터입니다. 네임스페이스를 통해 쿠버네티스는 동일한 물리 클러스터 내에 있는 여러 클러스터(여러 팀 또는 프로젝트 용도)를 관리할 수 있습니다.
📕service
서비스는 하나의 논리적인 파드 셋과 그 파드들에 접근할 수 있는 정책을 정의하는 추상적 개념입니다. 서비스는 종속적인 파드들 사이를 느슨하게 결합되도록 해줍니다. 서비스는 모든 쿠버네티스 오브젝트들과 같이 YAML (보다 선호하는) 또는 JSON을 이용하여 정의됩니다. 서비스가 대상으로 하는 파드 셋은 보통 LabelSelector에 의해 결정됩니다.
비록 각 파드들이 고유의 IP(veth)를 갖고 있기는 하지만, 그 IP들은 서비스의 도움없이 클러스터 외부로 노출되어질 수 없습니다. 서비스들은 여러분의 애플리케이션들에게 트래픽이 실릴 수 있도록 허용해줍니다. 서비스들은 ServiceSpec에서 type을 지정함으로써 다양한 방식들로 노출시킬 수 있습니다.
📔 Cluster Ip
실제로 존재하지 않지만 cluster 내부에서 kube-proxy에 의해 관리되어지는 IP. cluster 외부에서 접근할 수 없습니다.
📔 NodePort
NodePort 서비스를 만든다는 것은 Service를 하나 만들어 외부의 어떤 Port 번호를 지정하여 붙게끔 하고, 내부의 어떤 Pod를 서비스할지를 Label Selector로 지정해주어 Target Port 번호를 정의하는 것. NAT가 이용되는 클러스터 내에서 각각 선택된 노드들의 동일한 포트에 서비스를 노출시켜준다. :를 이용하여 클러스터 외부로부터 서비스가 접근할 수 있도록 해준다. ClusterIP의 상위 집합.
service의 각 cluster node는 node자체의 이름을 통해 port를 열고 port에서 발생한 traffic을 service로 redirect합니다.
📔 LoadBalancer
(지원 가능한 경우) 기존 클라우드에서 외부용 로드밸런서를 생성하고 서비스에 고정된 공인 IP를 할당해준다. NodePort의 상위 집합.
📔 ExternalName
CNAME 레코드 및 값을 반환함으로써 서비스를 externalName 필드의 내용(예를 들면, foo.bar.example.com)에 매핑. 어떠한 종류의 프록시도 설정되지 않음. 이 방식은 kube-dns v1.7 이상 또는 CoreDNS 버전 0.0.8 이상을 필요로 함.
📕kubernetes component
📔 Addons
애드온은 쿠버네티스 리소스(데몬셋, 디플로이먼트 등)를 이용하여 클러스터 기능을 구현합니다. 이들은 클러스터 단위의 기능을 제공하기 때문에 애드온에 대한 네임스페이스 리소스는 kube-system 네임스페이스에 속합니다.
📔 DNS
여타 애드온들이 절대적으로 요구되지 않지만, 많은 예시에서 필요로 하기 때문에 모든 쿠버네티스 클러스터는 클러스터 DNS를 갖추어야만 합니다.
클러스터 DNS는 구성환경 내 다른 DNS 서버와 더불어, 쿠버네티스 서비스를 위해 DNS 레코드를 제공해주는 DNS 서버입니다.
쿠버네티스에 의해 구동되는 컨테이너는 DNS 검색에서 이 DNS 서버를 자동으로 포함합니다.
📔 Web UI (dashboard)
대시보드는 쿠버네티스 클러스터를 위한 범용의 웹 기반 UI입니다. 사용자가 클러스터 자체뿐만 아니라, 클러스터에서 동작하는 애플리케이션에 대한 관리와 문제 해결을 할 수 있도록 해줍니다.
📔 Container Resource Monitoring
컨테이너 리소스 모니터링은 중앙 데이터베이스 내의 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 줍니다.
📔 Cluster-Level Logging
클러스터-레벨 로깅 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 집니다.
📕참조
https://www.redhat.com/ko/topics/containers/what-is-a-kubernetes-cluster
https://kubernetes.io/ko/docs/tutorials/hello-minikube/
https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/
https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/expose/expose-intro/
https://kubernetes.io/ko/docs/concepts/overview/components/
'Cloud' 카테고리의 다른 글
(Kubernetes) - k8s namespace 생성하기 (0) | 2021.11.09 |
---|---|
(Kubernetes) - storage (0) | 2021.10.26 |
(Kubernetes) - workload (0) | 2021.10.20 |
DevOps와 NoOps (0) | 2021.10.13 |
Kubernetes 등장 배경과 장점 (0) | 2021.10.12 |