인프런 커뮤니티 질문&답변

이 부분은 첨부한 이미지에서 삼각형으로 deployment전체를 얘기하시는거죠? 거기에 operator는 그림에 하나만 괄호로 표시되어있는데 옆에 있는 다른pod도 같은 Operator인가요? -> 네 맞습니다. 지금까지 배운 내용을 토대로 이해하시면 되세요. 배포는 항상 Deployment와 같은 컨트롤러 한다고 보시면 됩니다.

watch로 감지를 받는다(?)는데 저는 이 말자체가 와닿지 않아요 ㅠㅠ. -> 예를 들어 kubectl get events는 쿠버네티스의 다양한 이벤트 로그들을 조회하는 명령입니다. 근데 여기서 kubectl get events -w 를 하게되면 -w 는 watch 옵션이고요. 해보시면 아시겠지만, 한번만 조회되는 게 아니라 현재 이벤트 상태를 구독하는 상태가 되요. 그래서 모니터 화면엔 event 로그의 변경사항이 생길 때마다 즉각적으로 변경된 내용이 표시가 되요.

이렇게 조회가 아닌 변경시 알람을 받는 게 watch고요. 쿠버네티스의 내부 동작은 대부분 watch를 통해 변경을 감지합니다.

그리고 crd생성 표시옆에 Opt라는게 CRD에서 갑자기 나와서 실체가 뭔가요? -> 이건 저도 보면서 먼가 한참 생각했네요.. 결론은 kube-apiserver를 잘못 그려 놓은 것 같습니다. 수정할 예정이고요. 쿠버네티스에 대부분의 트래픽은 kube-apiserver를 통해서 하게 되고, CRD 생성시 Operator의 경우 watch도 kube-apiserver를 통해 받는 다는 내용입니다.

그리고 이게 그림에서 Pod두개를 감시한다는건가요? -> Pod 두개가 kube-apiserver를 통해 get을 하거나 kube-apiserver로 부터 watch를 받는 다는 의미입니다.

opt가 operator 를 감시를 하고 또 반대로 Operator에서 역으로 CRD 속성값을 확인하는건가요? -> CRD 생성 시 kube-apiserver를 지나게 되고, kube-apiserver에게 watch를 걸어 놓은 Pod(operator)에게 watch가 보내집니다. opt 때문에 혼동을 드린 점 죄송합니다.

그림에서도 operator pod가 sercret를 변경이라고 표시되어있는데...crd 를 확인하면 그냥 속성 정의만 되어있는데...secret의 실제값은 어디에서 확인해서 변경한다는걸까요? 속성이름만을 변경한다는걸까요? secret에 변경하고자 하는 실제값은 어디있는걸까요? -> crd 리소스는 내용이 복잡하고 상세 내용을 파악하기 어려울 겁니다. 그리고 crd는 pod와 service와 같이 나만의 커스텀 리소스의 규격을 정의하기 위한 용도이지, secret의 실제 내용을 넣는 곳은 아니고요. crd로 커스텀 리소스를 정의하고 그 커스텀 리소스 안에 secret의 실제 내용을 넣습니다. 그리고 그걸 operator를 개발할 때 커스텀 리소스 안에 secret에 해당하는 내용을 뽑아서 실제 배포가 됐을 때 Secret에 반영을 시키는 거고요.

일단 opt때문에 오해가 생겼지만, 해당 내용들은 큰 흐름만 파악하시고, 이후 CRD로 만들어진 오픈소스를 다뤄보시면서 다시 한번 해당 강의를 보면서 정리를 하는 게 좋습니다. CRD가 이론만 가지고 이해하기 힘든 개념이기도 하고요. 저도 상세하게 설명 드리게 되면 깊이 들어가게 되기 때문에 휙휙 설명을 드린 감이 있었는데, 오히려 정확하게 파악하고자 하시는 분들에겐 혼란을 드린 것 같네요.

안녕하세요, 인프런 AI 인턴입니다.

odark님께서 질문하신 Operator 패턴과 관련된 부분은 Kubernetes 환경에서의 리소스 관리와 자동화를 위한 중요한 개념입니다.

1. Operator의 역할과 배포

• Operator는 Kubernetes 환경에서 지정된 Custom Resource Definition(CRD)를 기반으로 리소스를 자동으로 관리하고 조정합니다. 이는 사용자가 정의한 규칙에 따라 동작하며, CRD를 참조하여 필요한 리소스를 생성, 삭제, 업데이트 등의 작업을 수행합니다. Operators는 배포 시, 일반적으로 Deployment 내에 존재하며, 해당 Deployment가 여러 가지 ReplicaSet 및 Pod를 포함할 수 있습니다.

• 첨부된 이미지에서 볼 수 있듯이, 오퍼레이터는 다수의 Pod 중 하나로 실행될 수 있습니다. 그러나 Operator의 기능(코드 로직)이 여러 Pod에서 수행될 수 있는지, 또는 어떤 Pod와 상호작용하는지는 Operator 자체의 설계와 구현에 따라 다릅니다.

2. Operator와 CRD의 상호작용

• Operator는 Kubernetes의 리소스를 관리하기 위해 CRD를 감시(Watch)하고, 필요할 때 CRD의 세부 정보를 조회(Get)하여 작업을 수행합니다.

• Opt와 Operator에 대한 질문은 여러 장치의 명명 방식이나 로컬 환경에 의존할 수 있습니다. Opt라는 명칭이 CRD와 연관된 별도의 구성 요소나 내부 로직이 아니라면 코드나 아키텍처 다이어그램 문맥에서 비롯된 명칭일 수 있습니다.

• 일반적으로 실제 환경에서는 Operator(예: Pod)이 CRD의 변화를 감시하고, 해당 변경사항에 따른 조치를 자동으로 수행합니다. 이로 인해 각 리소스가 조정될 필요가 없습니다. 추가적으로, Operator는 특정 Pod의 상태 변경이나 새로운 리소스 생성을 적절히 감시할 수 있습니다.

아래 관련 질문 URL을 참고하시어 kubelet 소스코드 로직 구성에 대한 설명과 함께 Operator의 역할 및 CRD와의 상호작용에 대해 더 깊은 이해를 할 수 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.