교보 DTS CDA 3기 9주차 후기

OK__UK·2025년 5월 9일
GSC신촌교보DTS글로벌소프트웨어캠퍼스내맘대로TIL챌린지클라우드교육

교보DTS CDA

목록 보기
7/16
post-thumbnail

시작하기 전,,,

글로벌 소프트웨어캠퍼스와 교보 DTS가 함께 진행하는 챌린지입니다

👉신나는 강의 바로 드가자~

5/7 41일차 수요일

그걸 아시나요? 우리 4일 쉬고 와서 오늘이 수요일 이라는것을?
그래서 오늘 너무 힘든것도 아시면 좋겠어요,,ㅎ

오전

  • init초기화 컨테이너

1. 라벨, 셀렉터

  • 라벨
    • 키-값 쌍으로 구성
    • 사용자가 클러스터 안에 오브젝트를 만들때 메타데이터로 설정
    • 유일ㄴㄴ, 다중 선택, 여러개 선언도 가능
    • 컨트롤러들이 파드를 관리, 선택,구분을 위해 사용
    • 생성된 라벨은 필요시 수정이 가능하고 수정되면 이전의 컨트롤러로부터 관리 되지 않음
    • 컨트롤러와 파드가 느슨하게 결합하여 유연하게 관리
    • 파드별 라벨 확인 --show-lablels
    • 라벨키값으로 단일 선택
    • 여러 파드 확인
    • 라벨 여러개 선택
  • 셀렉터
    • 등호 기반 셀렉터와 집합 기반 셀렉터 지원
    • 기호로 검색
    • 집합으로 검색
  • YAML파일로 파드 실행후 라벨로 구분하기
    • 파드들의 라벨 확인
    • 특정 라벨 검색
  • 노드셀렉터
    • 노드가 가지는 라벨 똑같음
    • 추가도 가능
    • 스케줄링할때 참고한다
    • 파드가 어떤 노드에서 실행 할 것인지 정의
    • 선언안해도 기본적으로 있는 라벨이 있음 특히 hostname을 많이 쓴다고 노드의 호스트네임이 자동으로 선언되서 ㅇㅇ
    • nodeSelector 로 실행할 노드의 라벨을 골라~
    • 제거
  • 애너테이션, 언노테이션?
    • 주석으로 생각, 필요한 사항을 기록해두는것 기능ㄴㄴ 클러스터가 인식할 수 있는 정보로 사용

오후

오후에한건 다컨트롤러야~

2. 레플리카셋(Replicaset)

  • 레플리카는 저번에도 나왔듯이 복제를 말한다!
  • 지정한 숫자만큼 파드(동일한)가 항상 클러스터 안에서 실행되도록 관리하는 것
  • 파드가 실행 되던 노드가 이상이 새겨서 종료되거나 누락된 파드를 감지하여 정상적으로 실행 가능한 노드에서 재실행
  • 롤링업데이트 지원 ㄴㄴ
  • 구성요소
    • selector: 관리될 파드를 선택할 라벨, template.labels 과 selector.matchLabels가 같아야함, 라벨을 기준으로 실행하니까 해당 라벨 파드가 실행중이면 재시작 ㄴㄴ
    • replicas: 유지할 파드 수 기본값 1
    • template: 레플리카셋이 실행할 파드의 정의, 없으면 실행해서 파드를 실행하기 위해 구체적으로 명세
  • 집합적 라벨 셀렉터도 가능 위에서 셀렉터와 동일함
  • 생성
  • 지정한것 확인
  • 삭제
  • 파드 수 변경
  • 파드를 제외한 레플리카셋만 제거가 가능 --cascade=orphan
  • 해당 라벨이 있으면 파드가 늘어나지 않고 레플리카셋만 생성

3. 디플로이먼트(Deployment)

  • 이 컨트롤러를 젤많이 쓴데
  • 배포의 기능이 많음
  • 파드를 생성하는 것이 아닌 레플리카셋을 통해 파드를 관리하는 것
  • 롤링 업데이트 가능
  • 롤아웃 즉 업데이트, 롤백 가능
  • 일정 수의 파드 유지 가능
  • 배포중 일시 정지도 가능하다
  • 과거에는 레플리카셋만 사용했지만 이제 같이 사용
  • 생성
  • 삭제
  • 파드 조절
  • 롤아웃(업데이트) 방법 3가지
    1. kubectl set image 명령으로 이미지 변경해서 업데이트
    2. kubectl edit 로 편집기 사용하여 업데이트 실시간 업데이트 가능
    3. yaml 파일 수정하고 kubectl apply로 적용
  • 배포중 일시정지, 재시작이 가능 pause, resume
  • 업데이트 종류 2가지
    1. Recreate
      • 디플로이먼트를 업데이트하면 이전 버전의 모든 파드를 즉시 종료
      • 애플리케이션은 여러 버전을 동시에 사용할 수 없으며 새 버전을 시작하기 전에 이전 버전을 완전히 중지해야할때 사용
      • 애플리케이션을 완전이 사용할수 없는 다운타임이 발생한다.
    2. RellingUpdate 롤링업데이트
      • 새로운 파드를 추가하고 오래된 파드를 하나씩 제거하여 한개씩 업데이트
      • 다운타임이 존재안함
      • 대신 이전 버전과 새버전이 동시에 처리 가능한 경우만 사용 가능
      • maxsurge: 컨트롤러에서 파드의 수를 유지하는데 업데이트할때 초과할수 있는 최대치
      • maxUnavailable: 업데이트중에 사용할 수없는 최대 파드 수
  • 롤백 rollback: 업데이트를 한것을 되돌린다
    • kubectl rollout undo
    • 위에서 애너테이션이 여기서 사용됨 history로 업데이트 내역을 확인한다

    • 지우면 롤백못함
    • 원하는 위치로 롤백 가능
    • revisionhstorylimit: 사용중인것을 제외한 이전의 업데이트 레플리카셋을 저장해둘수 있음

4. 데몬셋(Daemonset)

  • 클러스터의 모든 노드에 파드를 사용하고 싶을 때 사용하는 컨트롤러
  • 한노드에 하나씩 실행하기 위해
  • 운영 관리에 사용되는 파드를 사용할 때 사용
  • 마스터 노드에는 원래 Taints 제약사항이 있어서 노드가 못오는데 -> tolerations에서 무시할수 있음 마스터노드의 에 작성되있는것을 작성하면됨
  • 생성
  • 업데이트 종류 2가지
    1. OnDelete: 1.5이하 버전의 기본값, 템플릿을 업데이트하고 파드를 종료하면 자동으로 실행될때 업데이트내용으로 파드가 실행, 대신 수동으로 종료 시켜야함,, -> 원하는 시간에 업데이트 가능
    • 지우면 바뀜
    1. RollingUpdata: 매번 똑같은 것이니까 대충 넘어가~, 근데 여기서는 maxUnavailable만 존재, 제거하고 생성하는 것만 가능해서 왜냐면 노드 하나에 하나의 파드니까!

4. 잡, 크론잡(job,cronjob)

  • 잡 job
    • 완료를 하는 파드! 종료가 있는것 완료하고 재시작도 아님! 그냥 끝! 물론 원하면 반복도 가능함
    • 그래서 파드의 기본 정책은 Always이지만 잡으로 시작하는 파드는 OnFailure(비정상종료하면 재시작), never(완료하면 끝!)으로 정의
    • 자동으로 완료한 잡을 삭제하기 위해서는 ttlSecondsAfterFinished가 필요 일정 시간 지나면 삭제되도록 없으면 수동으로 삭제해야함
    • completions: 저상적으로 실행 완료 되어야하는 파드의 수 몇번 실행해야하는지, 기본값 1
    • parallelism: 동시에 실행 할 수 있는 파드의 수, 기본값 1
  • 크론잡 cronjob
    • 잡의 실행시간을 지정해서 실행하는 것
    • 리눅스의 cron과 똑같음!
    • schedule * * * * * 분 시간 일 월 요일
    • startingDeadlineSeconds: 지정된시간에 크론잡이 실행되지 못했을때 필드 값으로 설정한 시간이 지나면 잡이 실행 되지않는다! 그냥 넘긴다! 얘가 없으면 지정시간이 지나서 실행가능해지면 실행
    • concurrencyPolicy: 실행하는 잡의 동시성 관리
      • Allow: 크론잡을 동시 실행 가능(기본값)
      • Forbid: 잡을 동시에 실행 하지 않도록!, 실행시간이 되었는데 이전의 실행한 잡이 정상적종료가 안됬으면 이전 실행잡을 계속 실행함
      • Replace: 실행 시간이 되었는데 이전 실행한 잡이 안끝났다? 그럼 이전 실행한 잡을 종료하고 새로 시작
    • successfulJobsHistoryLimit: 정상 종료된 파드의 실행 내역을 보관하는 것 기본값 3
    • failedJobsHistoryLimit: 비정상 종료된 파드의 실행 내역을 보관하는 것 기본값 1
    • 일시 정지도 가능

5. 서비스

  • 필요한 이유만 설명해주시고 더 자세한것은 내일!
  • 객체의 한종류임! 파드, 컨트롤러같은! 웹서비스, db서비스랑은 다른것!
  • 파드는 일회성이므로 파드가 재시작되면 ip가 변경된다 그러한 ip를 미리 알 수 없기때문에 ip를 고정해야한다!
  • 서비스 객체를 사용하게 되면 파드가 클러스터 안 어디에 있던 고정 ip 주소를 통해 접근할수 있다
  • 클라이언트는 서비스의 ip만 알면 되고 서비스가 파드들의 ip를 가지고 있으면 되는 것

이후

오늘은 너무 졸려서 서서 했는데 서서도 졸리드라,,
월요일은 역시 힘들어
점심은 싸다분식에서 냉면먹음

5/08 42일차 목요일

오늘 날씨 왜이리 좋니?
대체 왜 좋니
주말에도 좀 좋아라,,

오전

어제 서비스에 대한 필요성을 배웠고 오늘은 서비스의 타입들

1. ClusterIP

  • 기본 서비스 타입으로 클러스터 내부에서 사용가능
  • 클러스터 안 노드나 파드에서 clusterip를 이용해서 서비스에 연결된파드에 접근할수 있음
  • 클러스터 외부에서는 사용할수 없음
  • 서비스에서 selector에서 선택한 라벨하고 컨트롤러에서 템플릿라벨하고 같아야 서비스에서 관리 가능
  • prot는 서비스 자신의 포트(port)와 파드의 컨테이너 포트(targetPort)가 나눠져있음
  • 생성
  • ip 연결
  • iptable를 확인하면 규칙으로 요청을 응답해준다
  • sevice는 규칙의 집합이라고 생각하면 된다! 서비스(규칙을 정의) -> 서버(서비스를 배포) -> 프록시가 나눠줌 -> iptable에 적용
  • sessionAffinity: 클라이언트에서 요청하면 매번 같은 파드로 연결하도록 하는것,
    • NONE(임의로 연결), Clientip(똑같은 클라이언트의 요청시 이전의 파트로 연결)
    • timeoutSeconds: 캐시로 생각하면 편할듯

오후

2. NodeProt

  • 외부에서 들어오는 접근을 가능하게 하기위해 nodeprot로 들어오는 prot로 구분해서 파드에 보내준다
  • nodeProt: 외부에서 접근하는 포트
  • 외부에서 30080포트로 들어오면 -> 노드에서 80번으로 서비스에게 보냄 -> 80포트 파드에게 보내줌
  • 생성
  • externalTrafficPolicy
    • local: 접근한노드에서 파드를 연결함 -> 만약 접근한 노드에 파드가 없으면 실행 안함 다른곳도 안찾아봄 어이없네? 나엿으면 찾아보겠습니다 하고 찾으러갔어
    • cluster: 접근한 노드 외에도 파드를 연결 할 수 있음 기본값

3. LoadBalancer

  • 원래는 퍼블릭 클라우드 서비스에서 사용하려고 만든 것
  • 노드 앞에 두고 각 노드별로 트래픽을 분산 시키기위한 서비스 타입
  • 필요이유
    • 보안적인 측면이 있음 nodeport를 사용하면 연결되는 내부 ip,prot등 네트워크 보안성이 떨어지기때문에
    • 각 노드 별의 ip를 알필요도 없음!
  • ip를 가지고 있다!
  • 외부에서 ip로 로드밸런서 접근 -> 트래픽를 노드들에게 분배 -> 노드에서 서비스로 보냄 -> 서비스에서 파드로
  • matalLB
  • 생성
  • 연결
  • 윈도우에서도 연결

4. Headless

  • Ip를 안가짐
  • 스테이스풀셋? 여기서 많이쓴다고
  • DNS기능을 허용하여 도메인으로 연결가능
  • 파드끼리 연결할때 많이 사용한다?

5. Application Deployment Strategies

  • 서비스하고 한다고하셔서 저번에 넘어갔는데 서비스가 끝났지!
  • 배포 방식이다! 새로운 이미지로 디플로이먼트를 배포하는 것
  • 롤링 업데이트는 매번 보니 넘어가자
  • 블루/그린(blue/green): 이전의 파드 수만큼 새로운 파드를 생성하고 한번에 서비스를 변경해서 새로운 파드로 한꺼번에 사용하도록 변경하는 방식
  • 카나리(canary): 기존 버전을 유치한채 일부버전만 새로운 파드로 교체해서 사용하는것! 일부만 바꿔놓고 상태, 반응등을 확인하고 괜찮으면 전체다 바꿈
  • 카나리로 한것을 블루/그린으로 바꿔보기

6. 인그레스

  • 서비스들을 묶는 상위객체

  • 클러스터 외부에서 내부로 접근 요청을 어떻게 처리할지 정의해둔 규칙

  • 나는 로드벨런서랑 비슷해서 조금 어려웠음

  • L7SW 수준의 접근 요청 처리 방법 제공

    • 공개 URL과 애플리케이션(컨테이너) 매핑
    • 복수의 도메인 이름을 가지는 가상 호스트로 사용 가능
    • 클라이언트의 요청을 여러 파드에 분산
    • SSL/TLS 암호화 통신 HTTPS 사용가능

  • 인그레스: 접근 규칙이 정의된 자원

  • 인그레스 컨트롤러: 인그레스 접근 규칙을 기반으로 제어하는 것 들어오는 요청을 제어해서 인그레스에 전달

  • 컨트롤러 종류, ingress-gce, ingress--nginx(우리가 사용할 것)

  • 외부 -> 노드 오기전에 서비스 -> 인그레스 컨트롤러 -> 인그레스 -> 노드 -> 서비스 -> 파드

  • 컨트롤러 부터 설치

  • 인그레스 생성

    • rewite-target: 트레픽 전달할 할곳
    • ssl-redirect: 암호화하는 건가?
    • force-ssl-redirect: 잘모르겠음!
    • app-root: 경로를 옮겨!
    • use-regex: 정규식?
    • 연결
    • 로드벨런서로 만들어서 포트 안쓰고 연결하기
    • ip 할당받고
    • 연결확인

  • ssl 설정하기

    • HTTPS로 연결하기 위해서 필요
    • 클라이언트에서 컨트롤러까지는 암호화하고 그이후부턴 필요없음!
    • 우리는 ca기관에 안하고 셀프로 openssl로 실습
    • 셀프인증 개인키, 인증서
    • 시크릿에 저장
    • 서비스로 실행
    • 인그레스 실행
    • https로 연결

7. 볼륨

  • 자주 나오니 알겠지만 영구적으로 저장하려고 하는 것!
  • 하지만 파드는 재실행하면 노드가 바뀔수 있어서 파드가 재실행할경우 데이터를 사용 못할수도?
  • 종류
    • emptyDir: 일시적으로 데이터를 저장하는것 파드안에서 컨테이너끼리 일시적으로 공유하려고
    • hostpath: 워커 노드의 파일 시스템에 파드의 디렉토리를 마운트하는것 -> 위에서 말했지만 노드들은 서로 다른 디크스를 보고 있기 때문에 재실행하면 데이터가 없을 수도?
    • Network
      • gitRepo: 깃 레포지토리를 이요하여 체크아웃을 이용한 볼륨
      • NFS: NFS서버가 공유하는 파일 혹은 디렉토리를 파드에 마운트 하는것 우리가 쓸것
      • ISCSI 등등 많지만 우리가 쓸건 정해져있으니까
    • cloud provider support plug-in: 클라우드를 사용하면 디스크를 빌려줌
  • emptyDir은 저번에 해봐서 넘어가~

8. hostPath

  • 노드 파일 시스템의 특정 파일이나 디렉토리
  • 노드에 마운트하기 때문에 파드가 종료되어도 데이터가 지워지지않는다
  • 동일한 노드에서 계속 파드가 실행되면 괜찮지만 다른 노드에서 실행하면 저장해둔 데이터를 사용 못함
  • 그래서 이걸 극복하려고 NFS나 노드셀렉터를 이용하여 동일한 노드만 사용하게 만듬
  • 파드를 연결
  • 영구 저장인지 확인
  • 워커 노드에서 확인
  • 파드를 재시작해도 남아있는지 확인
  • 동일한 노드에만 실행할 수 있게 셀렉트

이후

와와오아와아아아 오늘 아이스크림 4개 샀는데 7500원임 미친거지?
나오늘 점심에 2인분 먹은거지?
오늘은 강남불백갔는데,, 왜,, 난 어째서,,

5/9 43일차 금요일

오늘은 회식을 하는날~

오전

1. 볼륨의 정의방법

  • 디스크 볼륨을 사용하려면 물리적인 디스크를 연결하고 장치에 특성에 맞는 자세한 설정을 이해할 필요가 있음!
  • 쿠버네티스는 인프라에 대한 복잡한 과정을추상화를통해서 간단하게 하고 개발자들이 손쉽게 필요한 인프라를 설정할 수있도록 함
  • 인프라에서 종속적인 부분은 시스템 관리자가 설정하고 개발자는 이에 대한 이해 없이 간단하게 사용할 수 있도록 디스크 볼륨을 관리하는 것!
  • pvc, pv라는 개념을 알아야함!

2. PV, PVC

1. PV

  • 볼륨자체를 의미(물리적인 디스크과 유사)
  • 쿠버네티스 클러스터에서 관리 되는 ㄱ자원으로 파드와 분리되어 있으며 별도의 생명주기를 가짐
  • pod가 재실행되더라도 pv데이터는 정책에따라 유지/ 삭제가 됨
  • 정적, 동적 프로비저닝을 통해 pv로 등록

2. PVC

  • 파드가 필요한 pv에 요청하는것
  • 요구사항 같은느낌
  • 필요한 용량, 읽기쓰기등 권한 등 필요한 사항을 기술
  • 볼륨을 파드에 직접 할당하는 방식이 아닌 중간에 pvc를 두고 파드와 볼륨을 분리하고 요구에 따라 연결하도록 하는것

3. 라이프사이클 생명주기

  • 프로비저닝
    • 볼륨을 사용하기 위해 물리적으로 사용할 공가늘 확보하는 작업이 필요
    • 디스크 공간을 확보하여 pv를 만드는 과정
    1. 정적 프로비저닝
      • 특정한 용량을 가진 pv를 미리 생성하고 요청이 있을때 생성한 pv를 할당하는 방식
      • 미리 만들어둔 pv의 용량이 모두 100이라면 150을 요구한 pvc는 대기 아니며 실패
      • 물리적인 스토리지가 크더라도 pv로 요구한 만큼보다 적으면 사용못함
      • 스토리지가 제한적일 경우 사용
    2. 동적 프로비저닝
      • 사용자가 필요할 때 해당 디스크 공간에서 원하는 용량만큼을 생성해서 사용
      • 동적 프로비저닝을 위해서 pvc는 원하는 스토리지 클래스를 사용하여 pv를 생성
  • 바인딩
    • 프로비저닝을 생성된 pv와 pvc를 연결하는 단계
    • pvc가 요구하는 것에 맞는 것이 있으면 연결
    • 없으면 무한 대기
    • pvc하나에 여러 pv를 바인딩 할 순 없음
  • 사용
    • pvc는 파드에 설정되고 파드는 pvc를 통해 볼륨을 인식해서 사용
    • 할당된 pvc는 파드를 유지하는 동안 계속 사용하며 시스템에서 임의로 삭제할 수 없음 -> 지우려면 파드부터
  • 반환
    • 사용이 긑난 pvc는 삭제되고 pvc를 사용하는 pv를 다시 사용 가능한 풀에 반환되고 초기화하는 과정
    • 정책에 따라 초기화, 재사ㅛㅇ 등이 결정됨

4. pv, pvc 생성

  • pv 생성
  • 바운드
  • accessModes: 접근 정책
  • pvc 생성
  • 지우면 재사용 불가

오후

3. 볼륨을 NFS로 구성하기

  1. NFS 서버 패키지 설치
    • 볼륨 만들어두기
  2. 공유디렉토리 생성
  3. NFS Client 설정
  4. NFS를 통해 pv 생성

  5. NFS를 통해 pv와연결할 pvc 생성
  6. pvc를 이용할 파드 생성

    7 확인

4. 동적 프로비저닝, 스토리지 클래스

1. 동적프로비저닝

  • 요구하면 pv를 생성하는 것임
  • 사전에 프로비저닝을 할 필요 없이 사용자가 스토리지를 요청하면 자동을 프로비저닝 한다.
  • 스토리지 클래스 중 선택만 하면 됨

2. 스토리지 클래스

  • 스토리지 클래스는 관리작 ㅏ제공하는 스토리지의 classes를 설명할 수 있는 방법을 제공
  • 물리적인 스토리지를 구분하고 분류하기 위해 일종의 프로파일
  • 스토리지 클래스에 속하는 프로스턴트 볼륨을 동적으로 프로비저닝 할 때 사용

3. 구성

  1. 설치
  2. 스토리지 확인
  3. 기본스토리지 변경
  4. pvc 생성 및 파드 연결

5. 컨피그맵

  • 컨테이너화 된 애플리케이션에 많은 환경 변수를 통해 애플리케이션의 설정 파일이나 명령어의 인자 등을 전달
  • 컨테이너 내부의 설정 파일을 수정
  • 구성 방법
    1. 컨테이너 커맨드와 인수 내에서 구성
    2. 컨테이너에 대한 환경 변수로
    3. 애플리케이션이 읽을 수 있도록 읽기 전용 볼륨에 파일을 추가
    4. 쿠버네티스 api를 사용하여 컨피그맵을 읽는 파드 내에서 실행 할 코드 작성
  • 생성 방법
    1. yaml 파일으로 생성
    • 확인
    1. env 파일 사용해서 생성
    • 확인
  • 사용방법
    1. 일부분만 사용
    2. 전체 항목 사용
    3. 볼륨 마운트로 해서 파일을 사용

6. 시크릿

  • 컨피그맵이랑 동일함 근데 인코딩해서 저장하는 것임
  • 비밀번호, ssh키 같은 민감한 정보를 저장할때 사용
  • 생성 방법
    1. 명령어를 통해 생성
    2. yaml파일로 생성
  • ssl TCL로 구성하기

7. 스테이트풀셋

  • 레플리카와 같이 복제품을 생성하는 것 같지만 각각의 복제품이 서로다른 데이터 pv를 사용하는것
  • 랜덤으로 이름을 생성하는 레플리카셋이지만 이름을 순서대로 0부터 지정하여 변경되지 않도록 하는것
  • 구성 -> 동적 프로비저닝을 지원하는 경우 따로 생성안해도됨 pv를
    1, pv 생성
    1. 구성
    • 헤드리스로 연결
  • 스케일링
    • 파드가 제거되고 다시 재생성 되는 것은 동일하게 작동
    • pv보다 많으면 안됌
    • 추가 생성
    • 스테이트풀셋이 삭제된다고 pvc가 제거되지않는다
    • 업데이트는 큰수부터 진행되며, 삭제도 큰수부터 삭제
    • 부분적인 업데이트

9주차 후기

연휴가 너무 짧아요,, 한 2주하면 좋겠어 방학처럼
우리도 방학 만들어줘요,,,!!
그래도 이번주는 3일만 나갔잖아!
다 잊어버리고 돌아왔지만,, 블로그보면서 공부해야지,,
끝!

profile
OK__UK
접니다
이전 포스트

교보 DTS CDA 3기 8주차 후기

다음 포스트

교보 DTS CDA 3기 10주차 후기

0개의 댓글