Chapter1 - 범위: 섹션3 2024/01/10

YongsHub commented 7 months ago

VM vs Container
Pod, Service, Volume, ConfigMap, Secret, Namespace, ResourceQuota, LimitRange

YongsHub commented 6 months ago

VM 3대를 띄워서 실습하는 환경에 대해 올바르게 이해했는지 질문

결국 Kubernetes Cluster는 Server 1대는 Master, 나머지는 Node들로 이루어진 Server 구성 되었음으로 이해
하나의 Master에는 여러 Node들이 연결되어짐

따라서 우리가 구성한 실습 환경은 VM으로 Guest OS를 띄어 Node역할, Master역할을 하는 환경을 구축하는 이유는 즉, 다른 물리적인 자원이더라도 Kubernetes Cluster를 통해 관리할 수 있음을 보여주기 위한 것으로 이해했음

동일하게 이해 했는지 궁금합니다

YongsHub commented 6 months ago

동일한 이해 했는지 Check Point

Container
Label
Node Schedule

himJJong commented 6 months ago

체크1

NodePort
Load Balancer

Load Balancer는 NodePort의 기본적인 특징을 가지고 있는데, 차이점은 외부로의 연결이 되는지 안되는지(추가 플러그인 설치가 필요함) 이것 뿐인지..?

himJJong commented 6 months ago

체크2

PVC / PV

PVC가 필요한 이유와 전체적인 동작과정 이해했는지

himJJong commented 6 months ago

체크3

ResourceQuota와 LimitRange 차이 이해

himJJong commented 6 months ago

VM 3대를 띄워서 실습하는 환경에 대해 올바르게 이해했는지 질문

결국 Kubernetes Cluster는 Server 1대는 Master, 나머지는 Node들로 이루어진 Server 구성 되었음으로 이해

하나의 Master에는 여러 Node들이 연결되어짐

따라서 우리가 구성한 실습 환경은 VM으로 Guest OS를 띄어 Node역할, Master역할을 하는 환경을 구축하는 이유는 즉, 다른 물리적인 자원이더라도 Kubernetes Cluster를 통해 관리할 수 있음을 보여주기 위한 것으로 이해했음

동일하게 이해 했는지 궁금합니다

넵 저도 위에서 말씀하신거와 같이 이해했습니다. 추가로 궁금한거는 제 환경과 태용님 환경이 살짝 달라서, 본인의 쿠버네티스 클러스터 환경을 어떻게 사용하고 있는지 공유해도 재밌을 것 같습니다. :)

himJJong commented 6 months ago

개인의 별난 궁금증

k8s 로드밸런서와 Nginx 로드밸런서는 어떤 차이점이 있을까??

1) k8s에서 로드밸런서 역할을 하는 것은 Service 오브젝트입니다. 알다시피 Service 오브젝트는 Label, Selector를 이용해 특정 Pod를 선택하고, Pod의 엔드포인트로 트래픽을 분산합니다.

전체적인 간단 흐름

[1] 클라이언트가 서비스에 접근하게 되면 [2] k8s Service 오브젝트는 선택된 Endpoint에 도착한 트래픽을 분산 [3] 선댁된 Endpoint는 Pod로 전달

2) nginx에서는 'upstream' 블록을 사용하여 여러 서버(서비스를 제공하는 여러 백엔드 서버)를 그룹화하고, 각 그룹에 대한 로드 밸런싱을 설정합니다. 로드 밸런싱 알고리즘을 별도로 설정할 수 있고, HTTP/HTTPS or TCP/UDP 레벨에서 로드밸런싱 수행이 가능합니다.

전체적인 간단 흐름

[1] 클라이언트가 Nginx에 요청 [2] Nginx는 정의된 로드 밸런싱 알고리즘에 따라 request를 upstream 그룹의 서버 중 하나로 보냅니다. [3] 선택된 서버는 클라이언트에게 response 합니다.

결론
[x] 관리 및 배포 관점 k8s의 Service는 k8s API를 통해 관리되고, 클러스터 전체에서 Service를 쉽게 배포할 수 있습니다. Nginx를 이용한 로드 밸런서는 별도의 설정 파일을 관리하고, 서버에 직접 설치 및 유지 보수가 필요합니다.
[x] 유연성 및 기능 Nginx는 다양한 로드 밸런싱 알고리즘과 레이어에서의 기능을 제공 k8s의 Service는 클러스터 내부의 서비스 레벨에서의 로드 밸런싱을 주로 담당합니다.

k8s의 로드 밸런서는 클러스터 내부에서 Service에 대한 로드 밸런싱을 관리하고 배포하는데 중점을 두고 Nginx는 서버 레벨에서 다양한 기능과 유연성을 제공하여 로드 밸런싱을 수행합니다.

YongsHub commented 6 months ago

VM 3대를 띄워서 실습하는 환경에 대해 올바르게 이해했는지 질문

결국 Kubernetes Cluster는 Server 1대는 Master, 나머지는 Node들로 이루어진 Server 구성 되었음으로 이해

하나의 Master에는 여러 Node들이 연결되어짐

따라서 우리가 구성한 실습 환경은 VM으로 Guest OS를 띄어 Node역할, Master역할을 하는 환경을 구축하는 이유는 즉, 다른 물리적인 자원이더라도 Kubernetes Cluster를 통해 관리할 수 있음을 보여주기 위한 것으로 이해했음 동일하게 이해 했는지 궁금합니다

넵 저도 위에서 말씀하신거와 같이 이해했습니다. 추가로 궁금한거는 제 환경과 태용님 환경이 살짝 달라서, 본인의 쿠버네티스 클러스터 환경을 어떻게 사용하고 있는지 공유해도 재밌을 것 같습니다. :)

강사님의 답변도 인용합니다! 안녕하세요. 맞습니다. 마스터 노드만 있으면 워커노드들은 네트워크만 연결되면 어떤 물리적인 자원에 있던 연결 가능합니다. 저도 강의 때문에 이것저것 설치하느라 자원이 모자르게 되는데, 집에서 안쓰는 pc나 노트북이 생기면 포맷하고 리눅스를 설치해서 마스터에 계속 연결하면서 클러스터를 늘리고 있어요. 쿠버네티스 클러스터에 대한 세부 구성에 대한 이해가 궁금하시면, 섹션8. [중급편] 아키텍쳐에 component 먼저 보시는 것도 좋습니다.

YongsHub commented 6 months ago

체크1

NodePort

Load Balancer

Load Balancer는 NodePort의 기본적인 특징을 가지고 있는데, 차이점은 외부로의 연결이 되는지 안되는지(추가 플러그인 설치가 필요함) 이것 뿐인지..?

Node Port Service Object를 통해서 서비스에 연결된 Pod들에 대해 접근할 수 있는 점 Load Balancer Service Object를 통해서 서비스에 연결된 Pod들에 대해 접근할 수 있는 점 말씀해주신대로 External IP를 통해 공통적으로 연결된 Pod들을 외부에서 접근할 수 있는 차이점이 존재하지만 LimitRange에 명시된 Resource에 따라 트래픽 분산의 역할도 하지 않을까 싶습니다

YongsHub commented 6 months ago

체크2

PVC / PV

PVC가 필요한 이유와 전체적인 동작과정 이해했는지

User 영역과 Admin의 영역 Persistent Volume을 생성할때 특징이 각각 존재하기 때문에 User영역에서 제한된 Pod들에 대해 접근할 수 있는 개발자들이 Persistent Volume Claim을 통해 필요로 하는 PV에 접근할 수 있는 Flow로 강의를 듣고 이해했습니다

YongsHub commented 6 months ago

개인의 별난 궁금증

k8s 로드밸런서와 Nginx 로드밸런서는 어떤 차이점이 있을까??

k8s에서 로드밸런서 역할을 하는 것은 Service 오브젝트입니다. 알다시피 Service 오브젝트는 Label, Selector를 이용해 특정 Pod를 선택하고, Pod의 엔드포인트로 트래픽을 분산합니다.

전체적인 간단 흐름

[1] 클라이언트가 서비스에 접근하게 되면 [2] k8s Service 오브젝트는 선택된 Endpoint에 도착한 트래픽을 분산 [3] 선댁된 Endpoint는 Pod로 전달

nginx에서는 'upstream' 블록을 사용하여 여러 서버(서비스를 제공하는 여러 백엔드 서버)를 그룹화하고, 각 그룹에 대한 로드 밸런싱을 설정합니다. 로드 밸런싱 알고리즘을 별도로 설정할 수 있고, HTTP/HTTPS or TCP/UDP 레벨에서 로드밸런싱 수행이 가능합니다.

전체적인 간단 흐름

[1] 클라이언트가 Nginx에 요청 [2] Nginx는 정의된 로드 밸런싱 알고리즘에 따라 request를 upstream 그룹의 서버 중 하나로 보냅니다. [3] 선택된 서버는 클라이언트에게 response 합니다.

결론

[x] 관리 및 배포 관점 k8s의 Service는 k8s API를 통해 관리되고, 클러스터 전체에서 Service를 쉽게 배포할 수 있습니다. Nginx를 이용한 로드 밸런서는 별도의 설정 파일을 관리하고, 서버에 직접 설치 및 유지 보수가 필요합니다.

[x] 유연성 및 기능 Nginx는 다양한 로드 밸런싱 알고리즘과 레이어에서의 기능을 제공 k8s의 Service는 클러스터 내부의 서비스 레벨에서의 로드 밸런싱을 주로 담당합니다.

k8s의 로드 밸런서는 클러스터 내부에서 Service에 대한 로드 밸런싱을 관리하고 배포하는데 중점을 두고 Nginx는 서버 레벨에서 다양한 기능과 유연성을 제공하여 로드 밸런싱을 수행합니다.

말씀해주신 대로 NginX는 Web Server이자 Load Balancer 역할을 할 수 있습니다. 더해서 명시해주신 것처럼 NginX 여러 백엔드 서비스를 그룹화하여 로드 밸런싱의 역할을 할 수 있겠네요!! 하지만 -> Kubernetes를 사용하지 않는다면 각각의 서비스에 대한 추적이나 관리가 불편할 수 있고 과부하가 생겨서 서비스가 죽은 시나리오가 생긴다면 Resource를 유연하게 늘리는 행위 또는 restart를 제공하기는 어렵지 않을까 싶습니다.

하지만 Kubernetes를 사용함으로서 물리적인 자원에 대한 모니터링이나 Resource 분배, 제한 등등 쿠버네티스 자체에서 물리적인 공간이 다르더라도 하나의 Cluster 내에서 관리하고 자체 LoadBalancer Service Object를 제공하다보니 장점이 있지 않을까 감히 추측해봅니다.

YongsHub commented 6 months ago

@himJJong VM 환경은 UTM을 이용했고 https://kubetm.github.io/k8s/02-beginner/cluster-install-case7/

Apple Silicon M Series 설치편을 참고하여 설치했습니다

다만 다른점은 Rocky Linux ISO Download 링크에 걸린 minimal.iso version이 아닌 CD/DVD 를 선택했습니다 UTM 4.5.5 version에서 OS 선택 시, CD/DVD를 명시하고 있는데 강사님이 다운로드 버전은 minimal.iso version을 명시해뒀어요!

himJJong commented 6 months ago

체크1

NodePort

Load Balancer

Load Balancer는 NodePort의 기본적인 특징을 가지고 있는데, 차이점은 외부로의 연결이 되는지 안되는지(추가 플러그인 설치가 필요함) 이것 뿐인지..?

Node Port Service Object를 통해서 서비스에 연결된 Pod들에 대해 접근할 수 있는 점 Load Balancer Service Object를 통해서 서비스에 연결된 Pod들에 대해 접근할 수 있는 점 말씀해주신대로 External IP를 통해 공통적으로 연결된 Pod들을 외부에서 접근할 수 있는 차이점이 존재하지만 LimitRange에 명시된 Resource에 따라 트래픽 분산의 역할도 하지 않을까 싶습니다

제가 이해한 것이 옳은지 확인해주시면 감사하겠습니다. 클러스터 내에서 로드 밸런서는 노드 트래픽 분산을 하고, Pod는 네임 스페이스 안에 있으면서, 다른 영역인 Node 서버 위에 있게 됩니다. 네임 스페이스 내에 Pod는 존재하면서, 노드라는 것은 VM에서 생성한 GuestOS입니다. 결국 로드 밸런서는 NodePort의 성격을 가지고 있기 떄문에, Service 객체에 접근하면 네임 스페이스 내에 존재하는 노드와 모두 연결되어 있고 이 때문에 트래픽이 분산된다고 이해해도 될까요? 여기서 추가로 로드 밸런서는 외부에서 접근할 수 있는 IP 플러그인을 달 수 있는것이구요.

궁금한것은 LimitRange와 ResourceQuota는 결국 네임 스페이스 내에서 자원의 양이 부족해서 서로 영향을 받지 않고, 클러스터 내에서 문제를 발생시키지 않기 위해 사용하는 것 아닌가 하는 궁금증이 들었습니다. 트래픽 분산과는 관계없지 않나요??

himJJong commented 6 months ago

@YongsHub

VM 환경은 UTM을 이용했고 https://kubetm.github.io/k8s/02-beginner/cluster-install-case7/

Apple Silicon M Series 설치편을 참고하여 설치했습니다

다만 다른점은 Rocky Linux ISO Download 링크에 걸린 minimal.iso version이 아닌 CD/DVD 를 선택했습니다 UTM 4.5.5 version에서 OS 선택 시, CD/DVD를 명시하고 있는데 강사님이 다운로드 버전은 minimal.iso version을 명시해뒀어요!

1) 저는 Virtual BOX를 이용해서 Master, Node1, Node2 GuestOS를 생성했습니다. 2) 이때 Vagrant 라는 것이 있는데, Vagrant 스크립트 File 및 실습 관련 파일을 추가한 폴더를 데스크탑 위치에 생성했습니다. 그러면 해당 폴더 위치에서 간편하게 설치한 관련 파일을 이용해서 vagrant 명령어로 Virtual box 내 생성한 것을 띄우고 내릴 수 있더라구요. 3) 노드,master 접속은 terminal로 클러스터 내를 접속하고, k8s Dashboard와 함께 실습을 진행중에 있습니다!

YongsHub commented 6 months ago

체크1

NodePort

Load Balancer

Load Balancer는 NodePort의 기본적인 특징을 가지고 있는데, 차이점은 외부로의 연결이 되는지 안되는지(추가 플러그인 설치가 필요함) 이것 뿐인지..?

Node Port Service Object를 통해서 서비스에 연결된 Pod들에 대해 접근할 수 있는 점 Load Balancer Service Object를 통해서 서비스에 연결된 Pod들에 대해 접근할 수 있는 점 말씀해주신대로 External IP를 통해 공통적으로 연결된 Pod들을 외부에서 접근할 수 있는 차이점이 존재하지만 LimitRange에 명시된 Resource에 따라 트래픽 분산의 역할도 하지 않을까 싶습니다

제가 이해한 것이 옳은지 확인해주시면 감사하겠습니다. 클러스터 내에서 로드 밸런서는 노드 트래픽 분산을 하고, Pod는 네임 스페이스 안에 있으면서, 다른 영역인 Node 서버 위에 있게 됩니다. 네임 스페이스 내에 Pod는 존재하면서, 노드라는 것은 VM에서 생성한 GuestOS입니다. 결국 로드 밸런서는 NodePort의 성격을 가지고 있기 떄문에, Service 객체에 접근하면 네임 스페이스 내에 존재하는 노드와 모두 연결되어 있고 이 때문에 트래픽이 분산된다고 이해해도 될까요? 여기서 추가로 로드 밸런서는 외부에서 접근할 수 있는 IP 플러그인을 달 수 있는것이구요.

궁금한것은 LimitRange와 ResourceQuota는 결국 네임 스페이스 내에서 자원의 양이 부족해서 서로 영향을 받지 않고, 클러스터 내에서 문제를 발생시키지 않기 위해 사용하는 것 아닌가 하는 궁금증이 들었습니다. 트래픽 분산과는 관계없지 않나요??

apiVersion: v1
kind: Service
metadata:
  name: svc-3
spec:
  selector:
    app: pod
  ports:
  - port: 9000
    targetPort: 8080
  type: LoadBalancer

노드 트래픽 분산이라는 말이 조금 모순이 있는 것 같아요

저희가 실습에서 했듯, LoadBalancer의 kind는 즉, Service Object입니다. spec의 selector를 보시면 라벨링된 pod들을 지정하는 것을 볼 수 있어요! 따라서, 노드 트래픽 분산 보다는 Service에 의해 select된 pod들에게 트래픽이 분산된다. 라고 생각되며 Docs에도 명시되어 있습니다.

In Kubernetes, a Service is a method for exposing a network application that is running as one or more Pods in your cluster.

Pod는 네임 스페이스 안에 있으면서, 다른 영역인 Node 서버 위에 있게 됩니다. 네임 스페이스는 하나의 클러스터 내에서 생성된 것이기 때문에 Pod가 네임 스페이스 안에 있다는 것은 저도 동의합니다.

"다른 영역인 Node 서버 위에 있다" 라는 말은 어떤 의도인지 정확하게 이해하지 못했지만, 여러 Node들, 즉 각각의 물리적인 자원을 하나로 관리하는 것이 Kubernetes Cluster의 역할이고 이 Cluster 내에 Namespace를 생성합니다.

그 아래 계층이 Namespace 공간에 Pod들이 존재한다고 저는 이해했습니다.

따라서 Nodeport가 필요한 이유는 여러 Node들이 존재하는 Cluster 내 Service를 접근하기 위해서는 하나의 Nodeport를 통해서 클러스터 외부에서 접근을 하기 위함이라고 생각합니당 즉, 클러스터 외부에서 클러스터 아무 노드에 연결하고 Nodeport 서비스로 연결할 수 있음을 의미하는 것 같습니다.

LimitRange와 ResourceQuota는 말씀해주신 것처럼 Namespace와의 Resource와의 연관이지 트래픽 분산과는 무관한것 같습니다. 예리한 지적 감사해요!!

himJJong commented 6 months ago

1일차 범위 내용 토론 덕분에 잘못 알았던 점, 애매모호한 점 이해하고 알아가요~ 감사합니다!!

YongsHub / -Kubernetes-Study

Chapter1 - 범위: 섹션3 2024/01/10 #1

k8s 로드밸런서와 Nginx 로드밸런서는 어떤 차이점이 있을까??