인프런 워밍업 클럽 4기 - DevOps 2주차 발자국

2주차 학습내용

• Probe: 파드의 각 상태에 대한 헬스체크 기능을 제공한다.

  • startupProbe는 파드가 성공적으로 뜬 것을 확인

  • readinessProbe는 파드내 앱이 트래픽을 받을 수 있는지 확인

  • livnessProbe는 파드내 앱이 잘 살아 있는지 확인

  • readinessProbe, livenessProbe는 startupProbe 성공후부터 주기적으로 헬스체크하며, 그렇기에 로직이 더 가벼워야 한다.

  • readinessProbe, livenessProbe의 구분이 무의미하다고 생각할 수 있지만,
    순간적인 부하에 대응하는데에 있어서 readinessProbe 로 부하 대응 후, 일정 시간후 livenessProbe 가 동작하도록 한다면,
    부하 상황을 잘 해결할 수 도 있다.

  • Probe의 헬스체크는 kubelet이 직접 컨테이너에게 수행하며, httpGet 뿐 아니라 exec(shell실행), tcpSocket 등 도 가능하다.

• ConfigMap, Secret: 둘다 앱에 환경변수를 전달하는데 쓰인다.

  • 또한 둘다 env 변수로 또는 특정 파일로 마운트(volume)시켜 키밸류값을 전달할 수 있다.

  • Secret

    • 데이터를 base64로 인코딩한 값을 전달한다. (stringData) ~ 인증서나 바이너리 값을 저장하기 위함이다.

    • type에 따라 사용목적이나 데이터 구조가 정의된다. (opaque, docker-registry..)

    • Secret에 민감정보를 관리하려면, 아래 3가지 추가적인 방법으로 다루면 좋다.

      • 1. 클러스터내에서 직접 생성하고 관리 (Admin만 해당 파일에 접근하도록 함)

      • 2. 문자 자체를 암호화하고, 앱 런타임시 복호화해 사용

      • 3. Vault와 같은 암호화 관리 서드파티 사용

• PVC, PV

  • PV: 관리자가 직접 프로비저닝하거나 스토리지 클래스를 사용해 동적으로 프로비저닝한 클러스터의 스토리지

    • spec: local(현재 노드를 스토리지 볼륨으로 사용), nfs, awsEBS .. 이 존재

       

  • PVC: 퍼시스턴트 볼륨을 파드에 마운트하는데 사용

    • PV에 대해 selector - label, resource와 accessModes가 어느정도 일치해야 연결된다.

    • 파드의 노드셀렉터와 PV의 노드어피니티가 같아야 한다.

    • spec.local 과 같은 연결은 Pod.volums.hostPath .. 로 똑같이 할 수는 있으나,
      이런 접근은 노드의 정보가 꼭 필요한 앱에서만 readonly로 할 것!
      서로 다른 LC의 Pod와 PV를 연결 레이어 PVC를 사용하자! (볼륨 재사용, 볼륨 구현체 추상화, 제한적 볼륨 접근..)

• Deployment

  • template 속성 하위 값이 변경되면 자동으로 파드를 업데이트한다. (리스타트)

    • 버전정보만 살짝 다른 ReplicaSet을 생성하고, 신규 ReplicaSet 수치에 따라 파드 생성, 기존 ReplicaSet (+파드) 제거

    • 배포전략에는 아래와 같이 3가지가 있다.

      • 기존 파드 삭제와 신규 파드 생성을 동시에하는 ReCreate ~ 서비스 다운타임이 생김

      • 일정 신규파드를 성공적으로 생성한후 일정 기존파드를 제거하는 RollingUpdate ~ 두가지 앱버전이 공존

      • 새 파드들을 전부 성공적으로 띄운후 트래픽을 온전히 옮긴다음에 기존 파드들을 전부 제거하는 Blue/Green ~ 자원소모 큼

      • RollingUpdate는 세부 설정이 있는데.

        • 업데이트동안 최대 몇개 파드를 서비스 다운으로 유지할지 (=최소 라이브 파드 유지수), maxUnavailable

        • 새 파드를 최대 몇개까지 한번에 만들지, maxSurge

        • 이 옵션들을 조합하면 다른 배포전략을 흉내낼 수있다.

          • (100,100 == Recrate) (0,100 == 유사 블루그린) (25,25 == 1/4씩 롤링업데이트) (50,0) 사용리소스를 더 늘리지 않는 롤링업데이트 (배포시 잠깐 트래픽 수용량이 낮아짐)

• Service

  • Selector ~ Label로 대상이 되는 파드를 지정하여.

  • 다음과 같은 역할을 할 수 있다.

    • 서비스 퍼블리싱: 외부에서 파드를 직접 호출할 수 있게 트래픽 연결 (NodePort type)

    • 서비스 디스커버리: 내부 DNS에 Service>name을 등록해 서로 호출할 수 있게 (ClusterIP type)

      • 다른 네임스페이스라면, Service>name.Namespace>name 으로 연결

    • 서비스 레지스트리: 파드의 LC에 맞춰 자동으로 서비스에 변경된 IP 등록 (및 제거)

    • 로드밸런싱: 서비스에 연결된 파드들에 부하 분산

  • 연결할 파드를 서비스에 기입할 때, 포트 정보를 targetPort에 직접 pod.port 넣을 수 있으나.

    • 이 경우 파드 포트 변경시 서비스도 변경해줘야 한다.

    • 그래서 보통 pod.ports.name을 Service.targetPort에 넣어둔다.

      • 그러면 pod.ports.name 과 같은 레이어의 pod.ports.containerPort 정보에 Service가 자동으로 연결한다.

      • 참고로 pod.ports.containerPort만 있는 경우는 단순 정보성 속성이된다.

        • Deployment 정보에 상관 없이, Service가 직접 선언한 파드의 포트에 서비스는 연결한다.

• HPA

  • scaleTargetRef로 타겟 Deployment 지정후, min/max replicas 범위내로 부하시 파드 오토스케일링을 수행한다.

  • metrics 하위 값을 통해 부하 기준을 설정하는데.

    • resource의 경우 평균 자원 활용량을 기준으로 업다운을 판별한다. 보통 cpu를 사용 (메모리는 앱 내부를 점검하는게 더 맞는 듯)

    • custom Metric 를 통해 앱 리소스가 아니라, 디비 커넥션수, 큐 메시지수, HTTP요청 수 등을 기준으로 삼을 수도 있다.

      • 프로메테우스나 custom-metric API, 외부 API 연결 ..

  • behavior: 트래픽 변화에 너무 민감하게 대응하지 않도록 기준을 둔다.

    • 이를테면 최근 N초 동안 임계치를 넘으면 스케일 액션을 한다던가..

  • 사실 운영환경에서 부하증가 상황이오면, 갑자기 운영파드가 터지고 이후 오토스케일링에 맞춰 증가된 파드가 생겨 트래픽을 해소하는 식이다.

    • 미리 예기치 못한 트래픽에 장사는 없으며, 오토스케일링을 보조도구로 보며 서비스 LC를 보고 미리 스케일 셋업을 하던가 큐 아키텍처로 바꾸는 식으로 트래픽에 대응하자!

• 쿠버네티스를 다운받을 때, 노드에는 kubectl, kubeadm, kubelet, container runtime 을 설치한다.

  • kubeadm이 내부 manifest.yaml 파일을 통해 쿠버네티스 클러스터 파드를 띄우며.

    • 이 때 etcd,kube-apiserver, kube-controller-manager, kube-scheduler, kube-proxy 등이 뜬다.

    • 해당 요소들을 Control Plane Component라고 한다.

  • kubectl은 저장된 인증서를 통해 사용자에게 입력받은 명령어를 kube-apiserver API로 전달한다.

    • 관련된 명령 및 오브젝트 정보는 etcd 에 저장된다.

  • Control Plane Component들은 etcd 정보를 기반으로 아래 리소스들을 세팅한다.

    • HPA, Deployment, ReplicaSet과 같은 동종의 컨트롤러 혹은 오브젝트를 관리하는 컨트롤러와

    • Service, Configmap, Secret 등 각 컴포넌트가 인프라 역할을 하는 오브젝트

  • 워커노드가 마스터 노드에 연결되면, 사용자 앱을 올릴 수있는 파드들과 kube-proxy 파드가 뜬다.

    • kube-proxy는 서비스, 파드간 네트워크 트래픽을 라우팅하는 역할을 한다.

  • metic server, calico kube-dashboard와 같은 다양한 애즈온 파드들이 있으며, 이는 별도로 설치해줘야 한다.

    • 사용목적에 따라 마스터 노드, 워커노드 혹은 양쪽에 파드가 뜰 수 있다.

2주차 학습후기

• 한번 더 세부적인 내용으로 들어갔다! 생소한 내용도 많고 꽤나 딥한데.. 그래도 재밌다! ㅎㅎ