Kubernetes - Component

우야·2021년 5월 24일
0
post-thumbnail


1. 쿠버네티스를 배포 -> 쿠버네티스 클러스가 구성된다.
2. 쿠버네티스 클러스터는 노드(머신)으로 구성되어 있고, 마스터 머신과 워커 머신으로 구성되어 있다.
3. 마스터 노드는 쿠버네티스 기본 컴포넌트(컨트롤 플레인 컴포넌트)들로 구성이된다. - (관리)
4. 워커 노드는 어플리케이션 구성 요소인 pod를 호스트한다. - (서비스)
5. 일반적으로 컨트롤 플레인은 여러 컴퓨터에 걸처 실행되고, 클러스터는 여러 노드를 실행한다.

control plane

  • 클러스터내의 스케쥴링, 이벤트등을 감지하고 처리함.

  • kube-apiserver, etcd, kube-scheduler, kube-controller-manager

  • 여러 VM에서 실행되는 컨트롤 플레인 설정 : https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/

    kube-apiserver

    • API 서버는 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트
    • API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드
    • 최종 사용자 - 클러스터의 다른 부분 - 외부 컴포넌트가 서로 통신할 수 있도록 HTTP API를 제공
    • API 서버를 통해 쿠버네티스 오브젝트(pod, namespace, configmap, event, query)를 조작
    • kubectl, kubeadm과 같은 컴낸드 라인도구를 사용하여 수행
    • REST 호출을 사용하여 API 서버에 직접 접근할 수도 있다.

    etcd

    • 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소
    • 이 데이터를 백업하는 계획은 필수이다!!

    kube-scheduler

    • 노드가 배정되지 않은 새로 생성된 파드 를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트
    • 스케쥴링시 고려되는 요소
    • 리소스에 대한 개별 또는 전체 요구 사항, 하드웨어/소프트웨어/정책적 제약, 어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인

    kube-controller-manager

    • 컨트롤러를 구동하는 마스터 상의 컴포넌트
    • 논리적으로 각 컨트롤러는 개별 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 여러 컨틀롤 루프를 단일 프로세스 내에서 실행됨
    • node 컨트롤러 : 노드가 다운되면 통지, 대응
    • replication 컨트롤러 : 시스템의 모든 replication 컨트롤러 오브젝트에 맞게 파드 유지
    • endpoint 컨트롤러 : endpoint 오브젝트를 구성(서비스, 파드 연결)
    • service account & token 컨트롤러 : 새로운 namespace에 대한 default service accout와 api 접근을 위한 default token을 생성

    cloud-controller-manager

    • 클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트
    • 라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 해 준다
    • cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행
    • 자신의 사내 또는 PC 내부의 학습 환경에서 쿠버네티스를 실행 중인 경우 클러스터에는 클라우드 컨트롤러 매니저가 없음
    • 논리적으로 각 컨트롤러는 개별 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 여러 컨틀롤 루프를 단일 프로세스 내에서 실행됨 (kube-controller-manager와 같음)
    • node 컨트롤러 : 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공 사업자에게 확인
    • route 컨트롤러 : 기본 클라우드 인프라에 경로를 구성
    • service 컨트롤러 : 클라우드 제공 사업자 로드밸런서를 생성, 업데이트 삭제

Node Component

  • 동작중인 파드를 유지, kubernetes 런타임 환경을 제공, 모든 node에서 동작

    kubelet

    • 클러스터의 각 node에서 샐힝되는 agent
    • kubelet은 pod에서 컨테이너가 동작하도록 관리하는 것으로, pod spec대로 동작하는지 확인한다.

    kube-proxy

    • 클러스터의 각 노드에서 실행되는 네트워크 프록시로 실행됨
    • 쿠버네티스의 서비스 개념의 구현부
    • 각 노드의 쿠버네티스 API에 정의된 서비스를 반영
    • TCP, UDP, SCTP Stream forward, round-robin TCP, UDP, SCTP forwarding을 백엔드 셋에서 수행 할 수 있음
      • 서비스 클러스터 ip, port는 현재 서비스 프록시에 의해 열린 포트를 지정하는 docker-links-compatible 환경변수에서 찾을수 있음
    • 노드의 네트워크 규칙을 유지 관리하는데,
    • 네트워크 규칙은 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해줌
    • 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)

    container runtime

Add-on

  • 쿠버네티스 리소스(daemonset, deployment...)를 이용하여 클러스터 기능을 구현

  • kube-system namespace에 속함

    DNS

    • 클러스터 DNS를 구성해야함

      • 쿠버네티스는 pod, service를 위한 DNS 레코드를 생성함

        • ip 주소 대신 일관된 DNS 네임을 통해 서비스에 접속 할 수 있음
      • 개별 컨테이너 들이 DNS 네임을 해석할때, DNS 서비스의 IP를 사용하도록 kubelets을 구성

        1. DNS 레코드가 되는 리소스

          • Service, Pod
        2. 서비스의 네임스페이스

          • DNS를 사용하여, API를 요청을 했을때, 같은 네임스페이스안에서는 파드명으로 요청가능하지만, 다른 네임스페이스에 있을경우 네임스페이스 + 파드로 요청해야한다.
            • 예) DNS 구성 : {pod}.{namespace} 또는 {pod}.{namespace}.cluster.local로 사용할 수 있음
          • DNS 정보는 각 pod의 /etc/resolv.conf에 있음

            nameserver 10.32.0.10
            search .svc.cluster.local svc.cluster.local cluster.local
            options ndots:5

        3. 쿠버네티스 DNS-기반 서비스 디스커버리https://github.com/kubernetes/dns/blob/master/docs/specification.md

        4. Service

          • A/AAAA 레코드
            • normal
              • 클러스터 IP
              • 형식 : my-svc.my-namespace.svc.cluster-domain.example
            • headless :
              • 서비스에 선택된 파드 IP 집합
              • 클러스터 IP 없음
              • 요청시 pod는 IP 직접 선택, 라운드로빈으로 선택된다
              • 형식 : my-svc.my-namespace.svc.cluster-domain.example
          • SRV 레코드
            • normal, headless service에 속하는 이름있는 port를 위해 만들어짐
            • 형식 :
              • normal : _my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example
              • headless : auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example
        5. Pod

          • A/AAAA 레코드

            • 형식 : pod-ip-address.my-namespace.pod.cluster-domain.example
              • 예) default namespace + 172.17.0.3 ip
                • 172-17-0-3.default.pod.cluster.local
            • deployment, daemonset으로 생성된 pod의 DNS
              • 예) pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example
          • pod spec에 hostname, subdomain 설정

            • 전체 도메인 네임(FQDN)을 구성할 수 있음
            • hostname : pod의 이름보다 hostname(foo)이 우선됨
            • subdomain : hostname(foo) + subdomain(bar)을 구성할 수 있음
              • 예) foo.bar.my-namespace.svc.cluster-domain.example
          • headless service + pod 구성

            • headless service

            • pod

            • pod DNS

              • busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example
              • busybox-2.default-subdomain.my-namespace.svc.cluster-domain.example
          • pod의 setHostnameAsFQDN 필드

            • FQDN: busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example라면...
              • pod에서 hostname 명령은 busybox-1을 반환
              • pod에서 hostname --fqdn 명령은 위의 FQDN을 반환
              • pod spec에 setHostnameAsFQDN: true를 설정 시
                -hostname, hostname --fqdn 둘다 FQDN을 반환
              • 참고 : 리눅스에서, 커널의 호스트네임 필드(struct utsname 의 nodename 필드)는 64자로 제한
                • pod에서 이 기능을 사용하도록 설정하고 FQDN이 64자보다 길면, 시작되지 않음.
          • pod의 DNS 정책

            • DNS 정책은 파드별로 설정가능
            • pod spec dnsPolicy에 지정 할 수 있음
              • default : 노드 resolve 상속
              • ClusterFirst : 노드의 resolve에 없는 것은 별도 네임서버로 전달, stub-domain, upstream DNS 서버를 구축할 수 있음 (DNS 기본 정책으로 사용)
              • ClusterFistWithHostNet : hostNetwork: true인 pod의 경우 명시적으로 설정해야함.
              • None : 파드가 쿠버네티스 환경 DNS설정을 무시하도록하고, pod내 dnsConfig 필드를 사용하게 함.
          • pod의 DNS 설정

            • dnsConfig
              • nameservers : DNS 서버가 사용할 IP주소 목록
              • searches : DNS 검색 도메인의 목록(최대 6개)
              • options : DNS 정책 옵션

          nameserver 1.2.3.4
          search ns1.svc.cluster-domain.example my.dns.search.suffix
          options ndots:2 edns0

    웹 UI (대시보드)

    컨테이너 리소스 모니터링

    • 중앙 데이터베이스 내의 컨테이너들에 대한 시계열 메트릭스를 기록 및 UI
    • https://kubernetes.io/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/
    • 리소스 메트릭 파이프라인
      • kubectl top
      • horizontal pod autoscaler
      • metrics-server에 의해 수집되며 metrics.k8s.io API로 사용
      • Metrics-server
        - 클러스터 상의 모든 노드를 발견하고 각 노드의 Kubelet에 CPU와 메모리 사용량을 질의
        - Kubelet은 쿠버네티스 마스터와 노드 간의 다리 역할을 해서 머신에서 구동되는 파드와 컨테이너를 관리
        - Kubelet은 컨테이너 런타임 인터페이스를 통해서 컨테이너 런타임에서 개별 컨테이너의 사용량 통계를 가져옴
        - Kubelet은 이 정보를 레거시 도커와의 통합을 위해 kubelet에 통합된 cAdvisor를 통해 가져옴
        - 취합된 파드 리소스 사용량 통계를 metric-server 리소스 메트릭 API를 통해 노출
        - API는 kubelet의 인증이 필요한 읽기 전용 포트 상의 /metrics/resource/v1beta1에서 제공
    • 완전한 메트릭 파이프라인
      • 좀 더 풍부한 메트릭에 접근할 수 있도록 해줌
      • Horizontal Pod Autoscaler와 같은 메커니즘을 활용해서 이런 메트릭에 대한 반응으로 클러스터의 현재 상태를 기반으로 자동으로 스케일링하거나 클러스터를 조정할 수 있다
        - kubelet에서 메트릭을 가져와서 쿠버네티스에 custom.metrics.k8s.io와 external.metrics.k8s.io API를 구현한 어댑터를 통해 노출

    클러스터-레벨 로깅

  • 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장

  • https://kubernetes.io/ko/docs/concepts/cluster-administration/logging/
    - 다른 페이지에 작성

    kubelet
    kubeadm

    kube-proxy
    scheduler
    coredns

    tiller
    flannel

    master
    worker

    cloud controller manager (optional)

    ingress controller (nginx)

    추가
    iptable (프록시 모드)
    cni
    ipvs
    fin 패킷
    qps
    snat
    cidr

profile
Fullstack developer

0개의 댓글