안녕하세요 Authorization RoleBinding 실습 강의를 수강하던 중 질문이 있어 글 남깁니다. https://cafe.naver.com/kubeops/525 ※ 앞 시간에 생성해 놓은 Namespace(nm-01), Pod(pod-1), ServiceAccount(default), Secret(nm-01) 그대로 사용 해당 게시글에서 와 같이 nm-01, pod-1, serviceAccount, Secret 를 생성해둔 상태에서 Role , RoleBinding 을 생성하였습니다. 생성한 내용은 예제에 나와있는 내용을 그대로 복사했습니다. 쿠버네티스 대시보드 -> Secret 를 가보니 네임스페이스 (=nm-01) 에 대한 정보가 저장되어있고 실제로 해당 Secret 도 nm-01 에서 나온 정보가 맞습니다. 그래서 해당 Secret 에있는 Token 값을 이용하여 아래 API 를 호출했지만, 403 forbidden 에러가 발생하며 파드 정보가 조회되질 않습니다. https://192.168.56.30:6443/api/v1/nodes/namespaces/nm-01/pods 에러의 응답값은 아래와 같습니다. { "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", "message": "nodes \"namespaces\" is forbidden: User \"system:serviceaccount:nm-01:default\" cannot get resource \"nodes/nm-01\" in API group \"\" at the cluster scope", "reason": "Forbidden", "details": { "name": "namespaces", "kind": "nodes" }, "code": 403 } 에러 내용을 보면 API Group 내의 nodes/nm-01 정보를 조회할수 없다고 나오는 것 같은데 어떤 부분이 문제인지 파악이 어렵습니다.
재시도조차 실패한 메시지들은 dlt 로 이동하게 되고 이 메시지들에 대한 처리를 위해 @KafkaListner 를 사용해서 처리하는 방법을 보여주셨는데요. 리서치를 하다보니 @DltHandler 기능이 있는걸 알게됐습니다. dlt 를 처리한다는 부분에서 @DltHandler 가 좀 더 어울릴거 같은 느낌인데 @KafkaListener 로 처리하신 특별한 이유가 있으실까요?
kafka @RetryableTopic 에 대해 알아보다보니 궁금한점이 생겨 질문 드립니다. @RetryableTopic 가 없어도 retry 는 기본적으로 진행하는거 같은데요. 제가 알아본 바로는 아래와 같은 차이점이 있는것 같았습니다. @RetryableTopic 을 사용하지 않으면 'dlt' 로 메시지가 이동되지 않는다. @RetryableTopic 을 사용하면 'dlt' 토픽이 없는 경우 자동으로 만들어주고 dlt 토픽으로 메시지를 이동시켜준다. @RetryableTopic 을 사용하지 않으면 재시도는 하지만 재시도동안에는 partition 을 blocking 한다 (= 블로킹). @RetryableTopic 을 사용하면 재시도 하기전에 retry 토픽으로 이동시키고 consumer 의 스레드를 blocking 하지 않고 별도 스레드에서 retry 를 진행한다. (= 논블로킹) 강좌에서는 retry 중에는 partition 이 blocking 된다고 하셨는데, 그 부분과 좀 다른거 같아서 문의 드립니다..! 만약 @RetryableTopic 이 논블로킹으로 별도 스레드에서 진행이 된다면 순서보장이 안되는거라서 순서보장이 필요하다면 이걸 사용하면 안되는게 아닌가 싶습니다.
예제에서는 StringSerializer 와 StringDeserializer 를 사용하도록 설정하고 ObjectMapper 를 통해 직렬화/역직렬화를 해주셨는데요. 혹시 JsonSerializer 와 JsonDeserializer 를 사용하지 않는 이유가 있을까요? 그리고, JsonDeserializer 를 사용하든 StringDeserializer 를 사용하든 역직렬화를 할 때 실패하게 되면 offset commit 이 되지 않고 재시도를 하는동안 해당 message 의 partition 은 blocking 된다고 이해하고 있는데 맞을까요? 이 경우에도 retry 이후, 해결 안되면 dlt topic 으로 이동하는게 맞을까요?
강사님 안녕하세요. 잘 배우고 있습니다. 강의를 보다가 든 생각인데 실제로 Secret을 현업에서 관리하게 될 때는 아래와 같은 구조로 이뤄질 것 같은데 맞나요? 신규 피쳐에 새로운 시크릿이 필요하다. 개발자가 devops 팀에 추가를 요청한다. devops 에서 마스터 노드로 접근하여 kubectl 을 통해 secret 을 생성한다. 해당 사항을 개발자가 노티 받고, 배포를 진행한다. SealedSecret이라는 걸 알게 되었는데, 이걸 이용하면 개발자가 직접 추가할 수도 있고, git에도 비대칭 암호화된 값이 남아 안전하다고 합니다. 보통 SealedSecret 방식을 적용하여 프로젝트를 운영하나요, 아니면 책임 관리 소재에서 저 과정을 거치나요?
리서치를 하다보니 실무에서는 auto.create.topics.enable=false 설정을 사용하는게 좋다는 글을 많이 보게 되었습니다. 네이밍 컨벤션이나 예상치 못한 topic 의 생성 등을 방지하기 위함으로 이해했는데요. 그럼, xxx.dlt 와 같은 topic 들도 직접 생성을 해줘야 하는지 궁금합니다. 그리고, 실제로 실무에서 해당 설정을 많이 사용하는지 또한 궁금합니다 🙂
consumer 쪽에서 이메일 발송 로직 대신 Thread.sleep(3000) 을 써주셨는데요. 이 말은, consumer 쓰레드 자체에서 이메일 보내는 로직을 실행한다고 가정해서 그런거라고 이해했습니다. 개인적으로 consumer 는 message 를 consume 만 하고, 실제 비즈니스 로직 (email send) 는 별개의 쓰레드로 async 하게 동작하는게 더 효율적이라고 생각이 되는데요. email 발송 로직을 별개의 쓰레드로 할 때와 현재처럼 consumer 쓰레드에서 할 때 차이점 및 주의해야할 점 (ex. offset 수동 커밋 등) 이 있을까요?
concurrency 관련하여 궁금한점이 있습니다. 하나의 topic (ex. email.send) 에 5개의 파티션이 있다고 가정. 같은 groupId 로 지정된 consumer 2 (A, B)개가 있고 각각 concurrency=3 으로 설정이 되어 있다고 가정 이런 경우, 같은 groupId 내의 컨슈머는 같은 partition 을 consume 할 수 없으니 1개의 thread 는 동작하지 않게 된다고 보면 될까요? A-1 thread ===> partition 1 A-2 thread ===> partition 2 A-3 thread ===> partition 3 B-1 thread ===> partition 4 B-2 thread ===> partition 5 B-3 thread (동작안함) ====> x 추가로 실무에서는 일반적으로 concurrency 옵션을 사용하는지 궁금합니다.
[ 👍 좋은 질문을 했을 때 좋은 답변이 돌아 옵니다] 1. 실습 중 본인의 환경이 가이드와 다른 부분이 있었다면 말씀해주세요. 실습의 내용 그대로 따라가고있습니다 2. 해당 문제의 발생 빈도(재설치 여부)와 문제 해결을 위해 시도해본 케이스를 말씀해 주시면 원인 파악에 큰 도움이 됩니다. Virtualbox, Vagrant 다시 삭제 후 재설치 하여도 동일한 문제가 발생합니다 3. 에러 메시지만 봐서는 저도 모르는 경우가 많아요. 그전에 했던 작업이 포함된 캡쳐 화면도 부탁 드려요. 4. 영상 내용에 대한 질문 시 해당 시간을 같이 올려 주시면 답변을 드리는 시간이 더 빨라집니다. ssh로 접근은 가능하지만 현재 쿠버네티스가 깔려있지 않다고 나옵니다 k get pods -A 이 명령어를 사용할 수 없어요 5. 긴 로그는 제 메일로 보내주세요. ( k8s.1pro@gmail.com ) 6. 카페 [ 강의 자료실 ]에도 많은 질문과 답변들이 있어요!
안녕하세요. 강사님 강의내용에 덕분에 많은 도움을 얻고 있습니다. 질문1. 강의수강중 오타가 아닌가 확인이 필요하여 질문드립니다. 강의 service-headless,endpoint, externalName 편의 9:40 쯤에 EndPoint내에 주소가 172.217.161.68(80) 으로 표현됐습니다. Github의 주소는 185.199.110.153(80) 으로 그림이 표현됐는데 둘을 일치시키도록 교안을 수정해야되는지 궁금합니다. 질문2. Pod Network는 20.96.0.0/12 으로 소개를 해주셨습니다. 실제 vagrant 소스에는 12가 아닌 16으로 되있고요. 이 주소형식은 공인IP형식으로 보이는데 사설IP형식을 따르는 ServiceNetwork 10.96.0.0/12 와 달리 공인IP형식인 이유가 궁금합니다.
안녕하세요 젠킨스 설정을 따라해 보면서 궁금한게 생겨서 질문 드립니다. git actions를 사용해서 cicd 환경을 만들어본 경험이 있는데요, 이때는 레포지토리에 커밋내용이 푸시되면 이를 감지해서 자동으로 빌드가 되게끔 워크플로우를 작성했던 기억이 있습니다. 젠킨스에도 이러한 기능이 있는지 궁금합니다.
강사님, 캐싱 관련해서 실무적인 관점의 질문이 있습니다. 강의에서 String 타입의 value에 JSON 형식으로 데이터를 저장해서 캐싱 처리를 한다고 배웠는데, 실무에서 어느 범위까지 캐싱하는 게 적절한지 감을 잡고 싶습니다. 과거에 MyBatis의 동적 쿼리처럼 조건부 로직이 포함된 200줄짜리 복잡한 쿼리가 DB에서 파싱되는 시간 자체만으로도 성능 부하를 유발했던 경험이 있습니다. 쿼리 자체를 수정하는 것이 베스트겠지만, 현실적으로 어려울 때가 있었습니다. 이런 '고치기 힘든 악성 쿼리'의 실행 자체를 회피하는 목적으로 Redis 캐싱을 적극적으로 사용하는 전략에 대해 궁금합니다. 실무에서는 이런 경우: 1. 쿼리 결과 데이터가 어느 정도 크기(예: 수십 MB)까지 Redis에 캐싱을 허용하시나요? 데이터가 너무 크면 오히려 Redis에 부담이 될 것 같아서요. 2. 만약 결과가 너무 크다면, 페이징 처리된 일부만 캐싱하시나요? 아니면 보고서처럼 핵심 요약 데이터만 따로 캐싱하는 전략을 사용하시나요? 3. 특히 이런 복잡한 집계/통계 쿼리는 데이터 변경이 잦지 않은데, 이런 경우 TTL은 보통 어느 정도로 설정하시는지 강사님의 경험이 궁금합니다.
안녕하세요, 강사님! 바쁘신 와중에 질문드려 죄송합니다... 단순한 질문 같지만 ProductDocument 코드에 대해 궁금한 것이 있어 질문드립니다. Elasticsearch 관련 Document 코드에 @AllArgsConstructor 나 @Data 같은 롬복(lombok) 애노테이션 을 사용해도 문제가 없을까요...? 추가로 실제 실무에서 Document에 롬복을 사용하는지 강사님 코드대로 직접 생성자, getter & setter를 작성하는지 알고 싶습니다!
안녕하세요 강사님 카프카에서 컨슈머가 메시지를 읽은 후 처리 과정에서 실패했을 때 재처리 전략을 어떻게 잡으면 좋은지 궁금합니다. consume 이후 비즈니스 로직 실행중에 예외가 발생하여 실패한 경우 OOM 등의 이유로 서버가 비정상적으로 종료되어 실패한 경우 위의 두가지 상황에서 일반적으로 어떻게 처리하는지 궁금합니다.
안녕하세요, 재성님. 추석 기간 활용해서 좋은 강의 잘 듣고 있습니다! 강의 중에 표준(입)출력을 다루는 섹션이 있는데, 제가 어렴풋이 알고 있는 내용과 살짝 차이가 있는 거 같아 질문 드립니다. 강의에서 표준 (입)출력은 명령어의 출력 결과를 전달하는 '통로'라고 설명해주셨는데, 저는 막연히 표준 입력은 키보드, 표준 출력은 모니터 정도로 알고 있었습니다. 그래서 이 개념에 대해서 정확히 알고 싶은데, 혹시 표준 입출력을 OS에서 제공하는 입출력 담당 인터페이스라고 이해하면 좋을까요? 관련 개념들이 혼재되어서 뭐라 한마디로 정리하기가 힘들어 질문 올립니다 ㅠㅠ 읽어주셔서 감사합니다!
안녕하세요 강사님 수업 잘 듣고 있습니다. 강의 범위에서 조금 벗어난 것 같긴 하지만.. 레디스 서버 구성에 대해 궁금한 점이 있어서 질문 드립니다. 강의에서는 여러 대의 웹서버에서 레디스 서버 한 대로 요청을 보내는 구성에 대해서 설명하시는데, 레디스 서버는 이중화/다중화를 고려하지 않는 건지 궁금해서요. 웹서버가 수십 대로 구성되어 있더라도 레디스 서버는 보통 한 대로 운영하는 것인지 궁금합니다.
