Kubernetes 란?

• 인프라 와 MSA
  • 인프라

    • 

    • 온프레미스 : 야생(부지+전기+물+텐트+버너+식기+음식+술) (예: ... )
    • IAAS : 캠핑장(텐트+버너+식기+음식+술) (예: ... )
    • PAAS : 글램핑장(음식+술) (예: ... )
    • SAAS : 호텔($) (예: ... )
  • 모놀리식 아키텍처
    • 여러기능을 가진 서비스가 하나의 Application 으로 돌아가는 구조.
    • 예) 하나의 애플리케이션으로 회원가입,글쓰기,친구찾기 등등을 다 만듬.
    • 단점 : 특정기능에 과부하가 오고, 전체적인 유지보수가 버거움.
  •  MSA
    • 모놀리식 아키텍처의 여러기능을 각각에 Application 단위로 분리. 
    • 장점 : 기능단위로 고효율 저비용 Scale-Out 구조.
    • 단점 : 분산 시스템 환경에서... Transaction 관리등 복잡도가 증가 할 수 있다.
    • MSA를 위해서는 손쉽고 빠른 인프라의 구축이 필요하게 됨.
    • 그래서, 경량가상환경 위에서 독립적인 컨테이너 프로세스 단위로의 인프라로 구축하게 됨.
• DevOps
  • 개발 및 운영 을 유기적으로 잘하기 위해서, 전체 라이프사이클을 다 관리 하자는 일련의 철학.
  • 하나의 팀이 최종 서비스 배포까지 자체적으로 다 할 수 있는 환경.
• 오케스트레이션 이란?
  
  • 인프라의 추상화.
  • 클러스터내 수많은 노드들을 거대한 하나의 컴퓨터처럼 사용 할 수 있음.
  • 배포, 스케쥴링, Cluster관리, Scale In&Out, Service-Discovery, HA, 모니터링, 등등등 제공.
  • Docker같은걸 사용하다가 보니... '컨테이너 프로세스'가 많아질수록, 관리하기 점점 힘들어 짐.
  • 그래서 K8S같은 '컨테이너 프로세스 오케스트레이션'이 필요하게 된 것!
• 쿠버네티스 란?
  
  • 멀티 호스트에서 대량의 컨테이너를 실행 및 관리 등등 하는 '오케스트레이션 솔루션'.
  • IMMutable Infra-Structure :
    • cloud환경에서 resource를 변경하는 식으로 관리않고, 원하는 상태로~ 재성성 및 파기 한다는 개념!
    • 애완동물처럼 애지중지 키우려고 하지말고, 가축처럼 막 가져다 써라!
  • Pod(볼륨,네트워크,설정,컨테이너등)라는 단위로 수행을 한다.
    • 예) BasicObject : Pod, Service, Volume, Namespace
    • 예) Controllers : ...
  • 다양한 클라우드 및 환경 지원.
  • 특징
    
    • Auto-Binpacking : (HA희생 없이) 자동으로 컨테이너 스케쥴 배분.
    • Self-Healing : 헬스체크 및 다운된 노드의 컨테이너 대채.
    • Horizon-Scaling : 동적인 수평 확장.
    • Service-Discovery & Load-Balancing : DNS name 기반으로 여러게의 컨테이너 관리.
    • Auto Rollouts and Rollbacks : 무중단 배포.
    • Scret and Configuration : 중요한 설정 정보들을 따로 관리.
    • Storage Orchestration : 여러게의 컨테이너들이 사용할 스토리지.
    • Batch-Execution : 크론작업도 지원.
• 쿠버네티스 구조
  

  •  

    

  • 예) 사용자(kubectl) → 팀장(Master) → 팀원(Node) → 업무
  • 업무 : pod, replicaset, deployment, rollout, service, ingress, configmap, secrets, job, cronjob, ...
• Master 노드
  • 전체 k8s 시스템을 관리하고 통제하는, 컨트롤 플레인.
  • 즉, 클러스터를 관리하고~ 애플리케이션을 실행하지는 않는다.

  • 

    • kube-apiserver : 
      • k8s 시스템 내부의 모든 컴포넌트간의 통신은, 오직 kube-apiserver 통해만 이루어짐.
      • controller-manager 및 kube-scheduler 와 통신하고, etcd에 저장을 하는 중심.
      • 클러스터를 관리하는 RESTful API 제공.
      • 예)인증 및 권한승인 플러그인을 통한 클라이언트 인증.
      • 예) 리소스 검증 및 영구저장.
    • controller-manager : 
      • API의 요청을 받아, 실질적인 처리를하는 핵심.
      • 내부에 다양한 컨트롤러가 존재.
      • 예) replication-manager, replica-set, deamon-set, job-controller, deployment-controller, node-controller, service-controller, ... 등등등
    • kube-scheduler : 
      • API의 요청을 받은 리소스를 어느노드에서 실행할지? 결정하는 역할.
      • 클러스터 노드들의 상태를 점검 및 최상의 노드를 찾고, 다수의 POD는 RR 방식으로 워커에 분산함.
    • etcd : 
      • 아주 단순한 "다중의 Key-Value 데이터셋"
      • etcd에 k8s의 전체 설정정보가 저장됨.
      • 예) /registry -> apiregistration.k8s.io -> apiservices -> v1 ...
        • \-> clusterroles
        • \-> configmaps
        • \-> deployments
• Worker 노드
  • 컨테이너화된 애플리케이션을 실질적으로 실행하는 노드.

  • 

    • kubelet : kube-apiserver와 통신을 하고, 컨테이너를 관리.
    • kube-proxy : 애플리케이션 간에 네트워크 트래픽을 분산 및 연결.
    • 컨테이너 런타임 : 컨테이너를 실행하는 도커
• k8s Object Model
  
  • 일단 컨테이너 이미지를 Registry에 푸쉬하고, App DESC 을 게시하면~ k8s Object가 실행됨.
  • App DESC는 보통 .yaml 형식의 Manifest 파일로 정의 함.
  • 애플리케이션 디스크립션 : 각종 리소스 컴포넌트 객체정보를 명시.
  • POD
    • 밀접히 관련된 컨테이너들의 공통배포 그룹. (단일 컨테이너로 하는게 일반적)
    • 동일한 단일 Worker 노드에서 항상 함께 실행됨.
    • 해당 Application을 실행하는 "가상의 독립적인 시스템 환경"이라 보면 됨!
    • 즉, k8s에서는 컨테이너들을 POD로 그룹화하여~ 배포 및 운영.
    • ex) replicationcontrollers 나 scale rc 등의 명령어로 POD 관리가능.
    • ex) apiVersion, kind, metadata, spec, status 를 정의하면 됨.
  • Label 및 LabelSelector
    • Label : 리소스에 라벨을 붙여서, 아주 쉽고 강력하게 관리 및 운영을 할 수 있음.
    • LabelSelector : 수많은 리소스를 라벨을 활용해 필터링 하는놈.
    • ex) metadata의 labels에 정의하면 됨.
  • ReplicaSet
    
    • POD 를 관리하는 리소스. (POD 모니터링 및 복제)
    • 필수 3요소 : "LabelSelector" 으로 관리할 POD를 정해서, "replicas" 만큼 유지를 하고, 장애시 "POD템플릿" 으로 복제.
    • (기존의 ReplicationController는 없어질 예정이라고 함)
  • Deployment
    • ReplicaSet 을 업데이트하는 리소스. (downtime없는 무중단 롤링업데이트)
    • 즉, Deployment > ReplicaSet > POD
    • ex) spec에 template 및 replicas 등을 정의하면 됨.
    • ex) kubectl scale deploy 이름 --replicas=수 명령어로 스케일가능.
  • Namespaces
    • 리소스를 (시스템별로) 분리하여 나누고 싶을때 활용.
    • 각각의 리소스 이름은 각각의 네임스페이스에서만 고유함.
    • 즉, 복잡한 환경에서 각각의 영역을 명확히 하는것!
    • ex) kubectl get ns
    • ex) kubectl get pod --namespace kube-system
  • Services
    • client <-> server 환경에서, POD 같이 가변적 유동적 리소스는 적합하지않는 문제가 있음.
    • (POD 의 지속적인 변화로... IP가 바뀌더라도, 영향을 받이않는 구조가 필요)
    • 즉, 외부에 노출을 하기위해 구성되는 리소스.
    • ex) spec에 ports에 port 및 targetPort 정의하면 INTERNAL-IP는 노출됨.
    • (당연히 port 여러게 노출가능)
    • ex) spec에 sessionAffinity: ClientIP 옵션주면 Sticky방식으로 Session유지 가능.
    • (즉, Service내에 다수의 POD가 있더라도~ clientIp 기준으로 하나의 POD로만 감)
    • Service에 EXTERNAL-IP를 노출하는 3가지 방법
      • NodePort : 노드의이름을 사용하여, 리다이렉션 하는방식. ???
        • ex) spec에 type 및 ports에 nodePort 를 정의하면 됨
        • (외부 -> nodePort -> 노드 -> port -> Service -> targetPort -> POD) ???
      • LoadBalancer : 내부적으로 NodePort를 사용하여, LB가 RR하는 방식. ???
        • ex) spec에 type: LoadBalancer 정의하면 됨.
        • (외부 -> port -> LB -> 임의포트 -> 노드 -> targetPort -> POD) ???
      • Ingress : 하나의 IP으로 다양한 도메인에 개한 엑세스 제공하는 방식.
        • ex) spec에 rules/host/path/backend/serviceName&Port 등을 정의하면 됨.
        • (외부 -> 인그레스 -> 도메인별 서비스 -> 노드 -> POD)
    • POD 간 통신을 위한 ClusterIP
      • 여러 POD를 -> 하나의 Service으로 묶는 클러스터링 기능
      • ex) spec에 type: ClusterIP 정의하면 됨.
      • (POD -> port -> Service -> targetPort -> POD)
  • Network
    • 클러스터 내부적으로 모든 POD간 통신을 가능하게 하는...
    • CoreDNS : 내부에서 DNS 역할을 하는 POD가 존재함.
    • Service를 생성하면, "{서비스명}.{네임스페이스}.svc.cluster.local" 형식으로~ DNS-Entry 가 생성됨.
    • POD에서도 Subdomain을 사용하면, "{호스트명}.{서브도메인}.{네임스페이스}" 식으로~ DNS 사용가능.
    • ???
  • Storage
    • 볼륨
      • POD의 각 컨테이너가 접근하는 고유의 스토리지.
      • POD에 종속적인 리소스 컴포넌트라 보면 됨.
      • 수많은 POD가 데이터를 공유하고, 영구적으로도 저장 할 수 있어야 하는 필요성.
    • 볼륨의 종류
      • emptyDir : 컨테이너간 손쉽게 공유됨. 영구적인 공간은 아님.
      • hostpath : 노드의 파일시스템에 특정 디렉토리를 지정함. POD가 해제해도 사라지지 않음.
      • network volumn : 기존의 NFS 가 POD에 장착
      • cloud network volumn : ...
    • ...
• ...

-끝-