helm과는 좀 벗어나는 얘기지만 그래도 딱히 해결할 곳이 없어서 문의합니다. 모니터링이라고 하면 시스템이 죽고 살고, 자원을 얼마나 쓰고 얼마나 남았고 를 봐야 할거 같은데요. 전통적인 서버-application 인 시스템은 서버의 자원을 모니터링하고, application이 죽었나 살았나 확인하고. 이렇게 되어 있습니다. 근데 여기서 k8s라는 한 layer가 더 들어오다 보니 도통 어디를 봐야 할지가 혼동이 옵니다. 시스템 자원만 보기에는, k8s에서 할당한 자원, 즉 pods 내부를 모니터링 해야 하는건지 그 방법이 있는건지, 거기에 더해 pod이 죽고 살고 deployment가 몇개가 문제가 발생 했고 등 이런것들을 속시원히 모니터링 할 수 있는 툴이 좀 있을까요? 다양한 노드, 호스트들의 자원, 서비스 현황, pods상태 등을 하나의 대시보드로 보고 싶습니다....
argoCd 를 이용해 CD를 구성했습니다. sync 하여 예제 app 을 배포한 후 해당 app의 CD 를 제거 했습니다. 제가 생각했던 결과물은 "CD를 제거 하면 worker node에서 예제 app이 제거 되는 것" 이었습니다. 하지만 deploy, svc, pod 전부 그대로 떠 있더라구요. 원인이 무엇일까요? 제가 잘못 한 부분이 있는 것일까요 아니면 argoCd에선 CD를 삭제해도 CD만 제거될 뿐 worker node에 띄워진 app은 건드리지 않는 것인가요?
1. spec.capacity.storage 와 spec.accessModes가 동일할시에 자동으로 연결 시켜준다고 강의에서 확인하였습니다. 그런데 제가 본 다른 글중에서 labelSelect 로 선택하는 경우도 있고, stoarage의 양이 pv가 pvc보다 더 높은경우도 보았습니다. ``` apiVersion : v1 kind : PersistentVolumeClaim metadata : name : myclaim spec : accessModes : - ReadWriteOnce volumeMode : Filesystem resources : requests : storage : 8Gi storageClassName : slow selector : matchLabels : release : "stable" matchExpressions : - { key: environment, operator: In, values : [dev]} ``` pv와 pvc가 연결되는 경우가 사실 여러가지가 있는건가요? 2. 아마 storageClass를 사용하지 않을때는, pvc에서 spec.storageClassName을 ""로 명시하는 경우가 있는것같습니다. 그 경우는 ""로 명시하지 않을경우, 기본 스토리지 클래스가 잡혀서 PV가 없어도 자동으로 생성이 되어서 그런걸까요? 3. 기본 스토리지 클래스는, 제가 설정한적도 만든적도 없는데, 언제 어떤것이 만들어 진건가요? 4. 그리고 storageClass 를 사용하지 않는 경우에도 , Pv 와 pvc 에 storageClass 를 명시하는 경우도 보았는데 , 이 경우는 어떤 경우일까요 ? 항상 강의 잘보고 있습니다. 감사합니다. :)
뒷 부분 3.2, 3.3 강의에서 설명을 해주시네요. 질문은 남겨 놓겠습니다. 실습 환경으로 vm 4개가 만들어지게 되는데요, 마스터노드1개와 워커노드3개 구성으로 보입니다. 구성된 실습환경에 대해 한 번 설명을 해주셨으면 좋겠습니다. - 노드 4개가 클러스터 구성이고 마스터노드의 역할 등 - 구성해두신 쿠버네티스에 대해 pod 와 오브젝트들에 대한 설명 등
안녕하세요 강의 잘 듣고 있습니다. 다름이 아니오라 YAML 파일을 작성하는데 있어 궁금한 점이 생겨 문의드립니다. 오브젝트를 정의하기 위해 개별속성값들에 대한 정보를 기입을 해줘야 하는 것으로 알고 있습니다. - apiVersion - kind - metadata - spec Q. 위에 기재한 4개 속성은 인터넷에 쉽게 검색하면 나올 수 있지만 - 내부적인 추가 개별속성값 (selector, args.. etc)들은 어떤 것들이 있는지? - 그것들이 어떤 의미를 내포하는지? - 아래 속성값들과 어떤 relation을 가지고 있는지? 이러한 내부 속성값들에 대한 detail한 부분들을 어디에서 공부할 수 있는지 궁금합니다. Ex) 잘못된 Deployment YAML 문법 apiVersion: apps/v1 kind: Deployment metadata: name: httpd-frontend spec: replicas: 3 selector: matchLabels: app: httpd-frontend template: metadata: labels: app: httpd-frontend spec: containers: - name: httpd-frontend image: httpd:2.4-alpine # 올바른 문법 apiVersion: apps/v1 kind: Deployment metadata: name: httpd-frontend spec: replicas: 3 selector: matchLabels: name: httpd-frontend template: metadata: labels: name: httpd-frontend spec: containers: - name: httpd-frontend image: httpd:2.4-alpine 이 경우 matchLabels 가 어떤 의미를 내포하고 내부 속성값들로 어떤 것들을 기입할 수 있는지 궁금하며 왜 selector → matchLabels 내 app이 아닌 name을 기입해야하는지 어떤 상관관계를 가지는지 궁금합니다. 즉, 최상위 속성값들을 제한 하위 속성값들에 대한 관계 및 의미를 알고 싶은데 어디서 알 수 있는지 궁금합니다.
안녕하세요. 강의 1.2 코드로 쉽게 구성하는 쿠버네티스 랩 환경 구축 도중 에러가 발생해서 질문 드립니다. 아래의 캡처 화면 처럼 m-k8s-1.20 가상머신은 정상적으로 설치된 거 같고 그 이후에 master-node.sh 실행에서 문제가 발생하는 것 같습니다. kubeadm init ~~ 하는 부분에서 아래처럼 오류가 나타나는데 이유를 알 수 있을까요?
현재 Azure Cloud내 동일 VNet에 VM 3대를 생성하고 Case 4의 클러스터 설치 작업을 진행하였습니다. DashBoard 설치까지는 이슈없이 잘 진행이 되었으나 DashBoard 설치 후 VM에 할당된 공인 IP를 입력하여 PIP:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ 에 접속 시 { "kind": "Status", "apiVersion": "v1", "metadata": { }, "status": "Failure", "message": "error trying to reach service: dial tcp 20.97.224.67:8443: i/o timeout", "code": 500 } 메시지가 뜨는 이슈가 있습니다. 모든 포트에 대해 Open을 해두었기에 포트나 IP 차단에 대한 이슈는 없을겁니다. 혹시 다른 케이스의 설치작업을 진행해줘야 할까요?? 아니면 별도로 진행해줘야 할 작업이 있을까요? 추가적으로 VM 내에서 curl localhost:8001 로 접속시 Connection Refused가 뜹니다.
현재 Azure Cloud내 동일 VNet에 VM 3대를 생성하고 Case 4의 클러스터 설치 작업을 진행하였습니다. DashBoard 설치까지는 이슈없이 잘 진행이 되었으나 DashBoard 설치 후 VM에 할당된 공인 IP를 입력하여 PIP:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ 에 접속 시 { "kind": "Status", "apiVersion": "v1", "metadata": { }, "status": "Failure", "message": "error trying to reach service: dial tcp 20.97.224.67:8443: i/o timeout", "code": 500 } 메시지가 뜨는 이슈가 있습니다. 모든 포트에 대해 Open을 해두었기에 포트나 IP 차단에 대한 이슈는 없을겁니다. 혹시 다른 케이스의 설치작업을 진행해줘야 할까요?? 아니면 별도로 진행해줘야 할 작업이 있을까요? 추가적으로 VM 내에서 curl localhost:8001 로 접속시 Connection Refused가 뜹니다.
안녕하세요 질문이있어서 글 남깁니다. 컨테이너 기반으로 서버 구축시에 쿠버네티스를 통하여 스케일 아웃이되어 트래픽 분산을 할 수 있으며 사용 리소스에 따라 컨테이너를 오케스트레이션하여 비용을 절감시킨다고 알고 있습니다. 그러나 생각보니 실질적으로 가상머신 내부의 컨테이너 기술을 사용하는거고 가상머신 자체를 스케일다운을 하지 않는 이상은 컨테이너 영역에서의 오케스트레이션으로 비용절감이 의미가 있을지 궁금합니다. (컨테이너 기반 서버의 수는 리소스에 따라 감소하나 실제 윗단 가상OS의 스케일 다운은 자동적으로 처리가 안되기 때문입니다.) 이에 관련하여 왜 컨테이너를 사용시 비용이 절감되는지 자세한 이유를 설명듣고 싶습니다. 감사합니다.
