기능 얘기할때는 그래도 얼추 이해하면서 봤는데실습은...왜 저걸 하고 느닺없이 values파일에 에 뭔지도 모르는 presets이 왜나오고 logsCollections이 왜나오고..전혀 감을 못잡겠네요 ㅠㅠ 강사님은 필요시에따라 딱딱 찾아가서 뭔가를 작업하고 그 작업을 위해 가이드를 보고 이 가이드의 기능이나 방법 파악을 하시는데.......아~ 좌절입니다. ㅠㅠ 파일에 이 옵션을 보고 custom파일로 만들때 어떤 설정들을 옮기고...각 하나하나 어떤역할이며.........실습들어오고 정말 하나도 이해가 안되네요 ㅠㅠ우리가 쓰는 이미지는 쿠버네티스 버전이라서 다른 버전의 이미지에서 제공하는 기능은 쓰면 안된다고 하는데 이것도 대체...무슨말인가요? 쿠버네티스를 쓰는데 쿠버네티스가 아닌 다른버전이라뇨?? 아~~ 멘붕입니다.

똑같이 따라하고 있고 values.yaml 파일에auth_enabled: false 로 되어있으면 기본 fake폴더가 생긴다고 하셨는데 저는 안생겨있네요? ㅠㅠindex폴더안에도 prefix으로 준 부분으로 생성된 파일이 없고 index폴더안에 delete_requests폴더가 있네요. 강사님은 index랑 delete_requests가 같은위치에 있었는데 말이죵 ㅠㅠ 

강의를 듣다보니...프로메테우스 아키텍처랑도 비슷하다는 느낌이 많이 드네요?loki도 설치하면 grafana가 존재하나요? 아니면 prometheus설치했을때 존재하는 그라파나를 같이 사용하나요? 결론은 로깅 시스템 구성할때 loki는 어플리케이션 로그 수집용이고 프로메테우스는 노드 메트릭 수집용이라는 차이인거네요?

기존에 mymonitoring이라고 해서 cpu//memory 대시보드 만든건 쿼리에 메트릭조회가 잘 됩니다.거기에서 보면 DataSource 부분에 mixed가 선택되어있고 밑에 A, B 쿼리에서 ${datasource}가 선택되어있는데 ...저 mixed선택부분에 밑에 여러개 리스트가 보이던데 원래 mixed그대로 두는게 맞는지..저기에 보이는거랑 밑에 A,B에서 선택하는거랑 무슨차이가 있는지요? 왜 여쭤보냐면 nginx-controller 강사님 하신대로 대시보드 복사해서 왔는데 거기에는 A,B,C에는 Datasource 이미 prometheus가 선택되어있고 A,B,C에는 선택이아니라 그냥 이름만 표시되어있어서요..어떻게 하는게 맞는건지 헷갈립니다.${datasource} 그리고 그랸 Prometheus 이거 차이는뭔지 헷갈립니다.

job이름이 조회가 되면 Operator까지의 기능은 동작을 잘 한거다. 라호 하신 부분은 즉, operator가 여기에 secret을 보고 prometheus에 nginx 메트릭 가져올 serviceMoinitor를 선택한 설정을등록했다고 보면되는것이다라고 보면될까요?아니면 저 잡등록된 의미는 무엇일가요?

prometheus리소스 야믈내용을 아래에서 보면 이 값과 매칭되는 레이블에 이 내용이 있는 ServiceMonitor 를 찾는것이다.release: monitoring 이라고 prometheus리소스 야믈내용에 있는데요. values.yaml의 serviceMonitorSelector 설정을 통해 수정 가능하다고 하셨는데serviceMonitor를 monitoring이라고 선택하는부분을 변경할강사님이 만드신 values-custom.yaml에도 없고values-yaml에도 해당 항목이 없던데release: monitoring은 설정이 없을때 디폴트값인가요???만약 추가할려면 values.yaml에 어떻게 넣어야 하나요? 항목이 안보여서요..그나마 values.yaml안에 serviceMonitor항목 하위 항목들중에 jobLabel: jobLabel selector: {} # matchLabels: # k8s-app: kube-dns이부분이 보이긴 하던데..여기에 release: monitoing 이라고 넣어야 하는건가요? 

기존 대시보드에서 쿼리를 가져오는데cpu 패널 그리는데 쿼리가A Query :sum(node_namespace_pod_container:container_cpu_usage_seconds_total:sum_irate{namespace="a-anotherclass-434",container!=""})by(pod, container)/sum(kube_pod_container_resource_requests{job="kube-state-metrics", namespace="a-anotherclass-434", resource="cpu"})by(pod, container) 이렇게 되어있던데...두번째 kube_pod_container_resource_requests 함수의 sum값으로 왜 갑자기 나누기를 했는지가 궁금합니다. 어떤 의도이신지요?그리고 앞 쿼리를 나누기 전에 대략 cpu값들이 20~30%라면 뒤에 request는 0.1%에 해당됩니다. 그러면 20/0.1로 나눠버리면 200이 나오는게 맞는데..강사님은...그렇게 안나오는게 좀 이해가 안가네요 ?  추가로 메모리할때는 requests는 메모리와 1:1 비율이니까 max값을 1로 했는데 request가 메모리와 1:1비율이라는게 무슨의미안가요?

일단 따라하고 있는데 보이지 않던 value가 보입니다.총 쿼리가 A,B,C 세개인데..그리고 궁금한건...아니...직접 강사님은 node를 by옵션으로 추가하거나 이런건 어떻게 감감적으로 알수있는지 궁금하고 B같은경우에 Options값에는 legends에 그대로 안건들고 capacity라고 뒀는데 이유가있고 또 저건 뭔지도...궁금합니다.실제로 혼자 한다고 했을땐 legend값이나 by 부분 처가한거나..node를 추가한거나..이런걸 다 어떻게 알고 해야하나 갑갑하네요..감사합니다.

그라파나 지표 생성시기존꺼에서 가져오고 이전 함수들은 최신함수로 변경하셨는데 지표값이 안나오면...그런 특정 메트릭이 변경됐고 어떤걸로 해야할지는 구글링으로 확인하면될가요?

이 단원 들어오면서 어렵네요.operator가 prometheus crd를 보고 statefulset prometheus 를 만들어준다고했는데그럼 serviceMonitor crd를 보고는 operator가 무얼 만들어줍니까? serviceMonitor crd도 있고 prometheus설치하면서 service 리소스 타입도 있던데....이건 servicemonitor리소스와는 또 어떤관계인건지...?servicemonitor라는 crdservicemonitor kind타입의 리소스아래 service들......[root@k8s-master kube-prometheus-stack]# k get service -n monitoringNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEalertmanager-operated ClusterIP None <none> 9093/TCP,9094/TCP,9094/UDP 18hmonitoring-grafana ClusterIP 10.109.212.0 <none> 80/TCP 18hmonitoring-kube-prometheus-alertmanager ClusterIP 10.106.151.30 <none> 9093/TCP,8080/TCP 18hmonitoring-kube-prometheus-operator ClusterIP 10.105.53.49 <none> 443/TCP 18hmonitoring-kube-prometheus-prometheus ClusterIP 10.105.22.75 <none> 9090/TCP,8080/TCP 18hmonitoring-kube-state-metrics ClusterIP 10.99.143.250 <none> 8080/TCP 18hmonitoring-prometheus-node-exporter ClusterIP 10.101.93.137 <none> 9100/TCP 18hprometheus-operated ClusterIP None <none> 9090/TCP 18h그리고 아래 설명에서 말한 service들은 대체 어떤 service들인가요? 실제 서비스할 앱들이 있는 pod를 select하고있는 service 리소스들을 말하나요? 아니면 아래 service라고 칭한건....promethues 설치하면서 만들어진 serivceMonitor crd를 통해 만들어진 servermonitor 리소스가 있고 또 monitoring 네임스페이스에 있는 service 리소스들이 있는데 무얼 말하는지~~서비스서비스 계속 나오니 누구 어떤 서비스를 의미하는건지 구분이 통~ 안됩니다. ㅠㅠ    그리고serviceMonitor crd안에 잇는selector:matchLabels:app.kubernetes.io/instance: monitoringapp.kubernetes.io/name: prometheus-node-exporter이 설정을 그대로 monitoring-prometheus-node-exporter 라는 service 리소스에서 사용하는건가요?   여기 아래 서비스들. 앱이 들어있는 파드 select하는 서비스를 말하는지..kube-prometheus-stack 설치시 생성되는 service리소스를 말하는지...도통 ㅠㅠ- endpoints : 매칭될 타겟 Service의 Port 이름- jobLabel : 타겟 Service의 Label에 key가 jobLabel을 찾아 value 값을 매트릭의 job 라벨로 사용- selector : 매칭될 타겟 Service의 Label 정보

values-custom.yaml내용중에    storageSpec:      volumeClaimTemplate:        spec:          #storageClassName: "storageClassName"          accessModes: ["ReadWriteOnce"]          resources:            requests:              storage: 1Gi          selector:            matchLabels:              app.kubernetes.io/name: prometheus-volume근데 만약 파드를 늘리게 되면 이 스펙에 PVC가 또 만들어지는 거기 때문에 물론 PV를하나 더 수동으로 만들면 연결은 되겠지만 관리적으로 좋지가 않아서 테스트 환경에서 불가피할때만 이렇게 사용을 하시는 게 좋아요 라고 하신부분이 이전 설명에서 말한 prometheus 는 statefulset이라 데이타 공유를 하면 단일서버용으로 만들어진 시스템이라 데이터충돌이 난다고 말씀하셨던 그 부분을 말하는 내용입니까?

 Pod를 두개로 늘리려면 PV만 수동으로 하나더  만들면되긴 하는데 그렇게 하면 두 Prometheus가 결국 한볼륨을 바라보게 된다. 그럼 문제가 된다.?prometheus는 단일 서버용으로 만들어진 시스템이다.이부분에서StatefulSet인 파드를 두개로 만들었으면 그리고 PV를 수동으로 하나더 만들엇으면 어차피 storageclass라서 동적으로 pvc도 하나더 만들어지고 각각의 파드가 pod -pvc -pv구조로 연결되는거 아닌가요? 왜 결국 한 한볼륨을 결국 바라보게된다는게 이해가 안갑니다. statefuleset pod마다 각각의 고유 pvc를 사용하는거 아닌가요?

먼저 강의 질문 드리고 그 외 질문드려보겠습니다.강의에서 파드를 사전에 1,2개를 삭제해서 다른 worker노드로 보낸건 트래픽이 안끊게 하기위해 실습을 위해 보여주기위함인거죠? 만약 실운영에서 woker노드가 3개이상이면 그럴 필요없는지..실무에서 그렇게 원래하는건지 궁금합니다.  두번째는 실제 업그레이드 할때 강사님이 말씀해주신 부분외에...가령 리소스의 특정 annotation이나 버전값 등등 뭔가 버전업되면서 바뀌어야 하는정보들에 대한 실 가이드 문서를 별도로 보질 않아서 그런것들에 대해 파악하는법을 좀 알고싶습니다.쿠버 공식문서에 버전업 할때 필요한 모든 정보가 하나의 가이드에 다 들어있지 않을것 같긴한데요...가령 changelog라든가 이렇게 있던데..실제보면 양이 상당하고 모두 영어인데다가 ㅠㅠ그래서 실제 뭐뭐 바뀌는지...실무에서 정말 하나하나 다보고 파악하고 정리해야하나요?실무에서 놓치지 않고 업그레이드를 위해 빠지지 않고 다 업그레이드에 변경사항들 다 녹일려면 뭐뭐 봐야하는지...그리고 changelog보는법도 좀 알려주십시오.이것도 상당히 중요한부분같다는 생각이 들거등요이건 강의에 없는내용이고 평소궁금한부분이라 남겨봤습니다. 감사합니다.

annotations:           kubectl.kubernetes.io/last-applied-configuration 부분을 kubectl에서  내용을 업데이트해준다 .kubernetes에서 알아서 내용들을 업데이트 해준게 아니라.         클라이언트가 동시에 리소스에 수정하게 될때 충돌을 관리하는데 유리하다.  그래서 server-side옵션을 주면 서버가 주도해서 이 리소스에 대한 모든          내용을  수정관리 해주기 때문에 리소스에 대한 충돌이 일어나지 않는다. . 모든 리소스가 이렇게 server-side로 관리하면 kubernetes가 부담되기 때문에         클라이언트가 이런내용들은 알아서 계산해서 저장 할때 같이 반영한다.이렇게 말씀하셨는데요...저 annotation부분의 내용은 실제 아래 리소스 yaml내용을 반영을 했다 client가~~~ 이런의미인가요?근데 저렇게 annotation 바로 밑에 kubectl.kubernetes.io/last-applied-configuration 항목에 저 내용들이 들어간들 무슨 의미가 있는지 궁금해요..실제 필요한건..그밑에 name,namespace 나 spec 이하부분들이 중요한거 아닌가요?거기에 추가로 server-side로 하면 client다른 수정과 충돌을 피한다고 했는데실무에서 운영인데 함부로 누가 같은 리소스를 따로 공유도 없이 수정할려고 들까요? 그런 상황이 있을리 만무하지 않나싶어요...그래서 결론은 client에서 누군가 수정을 동일리소스에 할거 같아서 server-side옵션을 주는건 발생하기 희박할거 같단 생각이 들고.그리고 yaml안에 last-applied-configuration이라 내용의 쓰임이...단순이 그냥 정보성정도아닌가 여쭤봅니다. 저 값들로 뭔가 하지않을것 같아서요

강사님이 언급하신 말씀중에리눅스버전을 설치를 하면서 연결되어 있는 레파지토리의 containerd 버전을 보면 이 버전이 최상위버전으로 레파지토리에 올라가 있다.이렇게 하셧는데...같은 rocky버전일텐데..yum --showduplicates list containerd.io또는dnf --showduplicates list containerd.io이 명령어로 확인하셨을가요?저는 해보면 32버전까지만 보여서요 containerd.io.x86_64 1.6.32-3.1.el8 docker-ce-stable 

오퍼레이터 역할을 하는 컴포넌트를 개발을 해서 같이 배포를 시켜요---> 이부분은 첨부한 이미지에서 삼각형으로 deployment전체를 얘기하시는거죠? 거기에 operator는 그림에 하나만 괄호로 표시되어있는데 옆에 있는 다른pod도 같은 Operator인가요?  또 한가지는 오퍼레이터는 사용자가 CRD를 생성을 했을 때 watch로 감지를 받거나 필요시에 get으로 조회도 해서 CRD의 속성 값들을 확인하고 그 속성에 따라 secrets를변경을 합니다 ---> watch로 감지를 받는다(?)는데 저는 이 말자체가 와닿지 않아요 ㅠㅠ. 어떤의미인지~~그리고 crd생성 표시옆에 Opt라는게 CRD에서 갑자기 나와서 실체가 뭔가요? 그리고 이게 그림에서 Pod두개를 감시한다는건가요? 그림에서 표시된 Pod Operator 하나만을 감시한다는 뜻인가요?Opt라는게 뭔지요? Opt가 operator 를 감시를 하고 또 반대로 Operator에서 역으로 CRD 속성값을 확인하는건가요? 설령 crd속성값을 확인하는게 실제 값이 있는게 아니고 crd에는 속성정의만 했을뿐인데..속성값을 확인해서 어떤용도 어떻게 한다는건지도 이해가 안가네요 ㅠ 그림에서도 operator pod가 sercret를 변경이라고 표시되어있는데...crd 를 확인하면 그냥 속성 정의만 되어있는데...secret의 실제값은 어디에서 확인해서 변경한다는걸까요? 속성이름만을 변경한다는걸까요? secret에 변경하고자 하는 실제값은 어디있는걸까요?좀 헷갈립니다.^^

CRD 패턴 말씀중에 이해가 필요해서 질문올려봅니다. 강의중 아래와 같이 말씀하셨습니다.crd를 보고 로직을 쿠버 개발자가 만들어 리소스를 생성하고 crd는 별도로 또 devops엔지니어가 crd를 만들도록 업무가 구별되어있나요?또 crd를 보고 쿠버 개발자가 한다고 하셨는데 또 반대로 구조를 만들어놓으면 거기에 맞게 crd를 devops엔지니어가 만든다는게...뭐가 뭔지 이해가 안갑니다.. ㅠㅠ 뭐가 우선인지~~ 그리고 보통 쿠버 운영하는사람이 다 하지 않나요? crd 만든사람 따로 쿠버 리소스 만드는사람 따로 있나요?myDatabase를 조회해서 안에 있는 속성을 보고 여러 리소스들을생성시키는 로직이 있어야 되는데 이건 직접 구현이 필요한 부분이고요 그래서 이렇게Kubernetes 개발자가 이런 구조를 만들어 놓으면 DevOps 엔지니어 엔지니어는 이 CRD를만들어서 쉽게 배포를 할 수가 있게 돼요

 Prometheus와 같은 서버역할을 하는 컴포넌트들은 사전에 이미 worker노드IP를 이미 알고 있는 상태라서DaemonSet에 설정된 containerPort 를 보고 각 노드별로 설치된 Pod를 호출해서 CPU와 메모리 데이터를 수집하는것이다.라고 하셨느데요서버역할을 한다고 표현하신게 무슨 의미인지 궁금합니다.그리고 Promethues가 저렇게 리소스 정보를 수집하기위해 별도로 저런 DaemonSet yml형태로 DaemonSet을 생성해야 하나요? 아니면 promethues 설치 패키지 안에 그런 Daemonset리소스(hostNework:true)를 생성하는게 포함되어있는건가요?

안녕하세요 강사님OpenTelemetry 구조와 Log 포맷 실습 과정에서 제공해주신 Core, Cust Application 배포했는데아래 사진과 같이 에러가 발생하는데cust,core pod 둘다 아래 사진처럼 로그가 남습니다 배포자료 확인 부탁드립니다 ㅠ.

 안녕하세요 강사님opentelemetry 연동까지 했는데 위와 사진과 같이grafana dashboard에는 unknown_service 이라고 logs에서 하나만 보이는데 확인해볼 설정이 있을까요?