blog.

10.2 스테이트풀셋 이해하기 1) 안정적인 네트워크 아이덴티티 제공하기 - 스테이트풀셋으로 생성된 파드는 서수 인덱스(0부터 시작)가 할당되고 파드의 이름과 호스트 이름, 안정적인 스토리지를 붙이는 데 사용된다. - 거버닝 서비스 ㄴ 그룹의 특정 파드에서 동작하기를 원하는데 이런 이유로 스테이트풀셋은 거버닝 헤드리스 서비스를 생성해서 각 파드에게 실제 네트워크 아이덴티티를 제공해야 한다.   - 스테이트풀셋 교체하기  - 스테이트풀셋 스케줄링 ㄴ 스케일링하면 사용하지 않는 다음 인덱스를 갖는 파드 인스턴스를 생성, 반대로 다운해도 동일한다. ㄴ 이 부분이 레플리카셋과 대조적이다. ㄴ 1) 한 시점에 하나의 파드 인스턴스만 스케일 다운 (데이터 손실 방지), 2) 하나라도 비정상적인 경우 스케일 다운 작..

10.1.데이터베이스 파드를 복제하는 데 레플리카를 사용할 수 있을까? - 각 레플리카가 별도의 퍼시스턴트볼륨 클레임을 사용하도록 만들 수 없다.  1) 개별 스토리지를 갖는 레플리카 여러 개 실행하기 - 방법1) 수동으로 파드 생성하기 ㄴ 레플리카셋이 파드를 감시하지 않으므로 수동으로 파드를 관리하고 파드가 사라지면 다시 생성해야 한다. ㄴ 노드 실패나 고장으로 인한 재스캐쥴링 보장하지 않음 - 방법2) 파드 인스턴스별로 하나의 레플리카셋 사용하기 ㄴ 노드 실패나 고장으로 인한 재스캐쥴링 보장ㄴ 레폴리카셋의 장점을 발휘 못함 ex, 의도된 레플리카 수를 자유롭게 변경못함 - 방법3) 동일 볼륨을 여러 개 디렉터리로 사용하기 ㄴ 모든 파드가 동일한 퍼시스턴트볼륨을 사용하게 하되 각 파드의 볼륨 내부에서 ..

9.3 디플로이먼트 사용하기 - 낮은 수준의 레플리케이션 컨트롤러 또는 레플리카셋이 아닌 높은 수준의 선언적 업데이트 리소스이다.  1) 디플로이먼트 실습kubectl rollout status deployment kubia 디플로이먼트 상태 확인하기 위해 사용되는 명령어  2) 디플로이먼트 전략 - RollingUpdate 전략 : 새 파드를 만들기 전에 이전 파드를 모두 삭제한다. ㄴ 여러 버전을 병렬로 실행하는 것을 지원하지 않고 새 버전을 시작하기 전에 이전 버전을 완전히 중지해야하는 경우 이 전략 사용 ㄴ 짧은 서비스 다운타임이 발생- Recreate 전략 : 이전 파드를 하나씩 제거하고 동시에 새 파드를 추가해 전체 프로세스에서 애플리케이션을 계속 사용할 수 있도록 하고 서비스 다운 타임이 없..

9.1 파드에서 실행 중인 애플리케이션 업데이트 1) 오래된 파드를 삭제하고 새 파드를 교체 - 레플리케이션컨트롤러를 사용하면 파드 템플릿은 업데이트 하고, 새 인스턴스 생성할 때 업데이트된 파드 템플릿 사용할 수 있다. - 이전 파드 인스턴스를 삭제해 쉽게 교체할 수 있다.   2) 새 파드 기동과 이전 파드 삭제 - 다운타임이 발생하지 않고 한 번에 여러 버전의 애플리테이션이 실행하는 것을 지원하는 경우에는, - 프로세스를 먼저 전환해 새 파드를 모두 기동한 후 이전 파드를 삭제할 수 있다.  3) 롤링 업데이트 수행 - 파드를 단계별로 교체하는 롤링 업데이트를 수행할 수 있다. - 이전 레플리케이션컨트롤러를 천천히 스케일 다운하고 새 파드를 스케일 업해 이를 수행할 수 있다.   9.2 레플리케이션..

8.2.3 앰배서더 컨테이너를 이용한 API 서버 통신 간소화   앰베서더 컨테이너 패턴  - API 서버와 직접 통신하는 대신 메인 컨테이너의 애플리케이션은 https 대신 http로 앰베서더에 연결 - 앰베서더 프록시가 api 서버에 대한 https 연결 처리  https://github.com/luksa/kubernetes-in-action/blob/master/Chapter08/curl-with-ambassador.yaml kubernetes-in-action/Chapter08/curl-with-ambassador.yaml at master · luksa/kubernetes-in-actionCode from the Kubernetes in Action book. Contribute to luksa..

8.1 Downward(하강) API 로 메타데이터 전달 - 7장 환경변수, 컨피그맵, 시크릿 볼륨은 이미 알고 있는 데이터에 적합하다- but 파드의 IP, 호스트 노드 이름 또는 파드 자체의 이름과 같이 실행시점까지 알려지지 않은 데이터의 경우에 대해서 해결방법이 필요하다 >  Downward API    Downward API  - 환경변수 또는 파일로 파드의 해당 환경의 메타 데이터를 전달할 수 있다.  API 서버: 이 서버는 포드와 관련된 메타데이터와 상태 정보를 제공합니다. 그림에서 '포드 매니페스트'라는 문서에 메타데이터와 상태 정보를 포함하고 있습니다.포드 매니페스트: 포드와 관련된 구성 정보와 현재 상태를 정의합니다. 여기에는 포드의 이름, 네임스페이스 등 메타데이터와 상태 정보가 포함..

7.4 컨피그맵으로 설정 분리 - kubectl create configmap 명령어 사용 kubectl create configmap fortune-config --from-literal=sleep-interval=25  kubectl get configmap fortune-config -o yaml...apiVersion: v1data: sleep-interval: "25"kind: ConfigMapmetadata: creationTimestamp: "2024-10-01T14:04:20Z" name: fortune-config namespace: default resourceVersion: "1459822" uid: 9ebe8eea-8264-44a6-bb7c-9d804670abc9 ... ..

7.1 컨테이너화된 애플리케이션 설정 - 일반적으로 명령줄 인수로 설정 넘겨주는 것으로 시작해서 옵션 목록이 커지면 파일에 저장하고 사용한다. - 컨테이너화된 애플리케이션에서는 설정을 애플리케이션에 전달할 때 환경변수를 사용한다. 왜 그럴까 ?> 만약 파일에 저장할 경우, 설정 파일을 컨테이너 이미지 안에 포함하거나 파일이 포함돼 있는 볼륨울 컨테이너에 마운트 해야해서 어렵다.> 또, 파일을 이미지 안에 넣고 빌드하는 것은 애플리케이션 소스코드에 설정 파일을 넣고 하드코딩하는 것과 동일하다. - 다른 방법으로는 최상위 레벨의 쿠버네티스 리소스에 저장하고 이를 기타 다른 깃 저장소 혹은 다른 파일 기반 스토리지에 저장하고 사용.  ▶ 정리하면, 다음 3가지 방법이 있다. 1) 컨테이너에 명령줄 인수 전달 ..

이상적으로 쿠버네티스에 애플리케이션을 배포하는 개발자는 기저에 어떤 종류의 스토리지 기술이 사용되는지 알 필요가 없어야 하고, 동일한 방식으로 파드를 실행하기 위해 어떤 유형의 물리 서버가 사용되는지 알 필요가 없어야 한다.  6.5 퍼시스턴트볼륨과 퍼시스턴트볼륨클레임 소개 - 퍼시스턴트볼륨 PV PersistentVolume- 퍼시스턴트볼륨클레임 PVC PersistentVolumeClaim - 개발자가 파드에 기술적인 세부사항을 기재한 볼륨을 추가하는 대신 클러스터 관리자가 기반 스토리지를 설정하고 쿠버네티스 API 서버로 퍼시스턴트볼륨 리소스 생성해 쿠버네티스에 등록한다.- 퍼시스턴트볼륨이 생성되면 관리자는 크기와 지원 가능한 접근모드를 지정한다.   IT 용어에서 "볼륨(Volume)"과 "클레임..

6.1 불륨 소개 - 쿠버네티스 볼륨은 파드의 구성 요소로 컨테이너와 동일하게 파드 스펙에서 정의. ㄴ 독립적인 쿠버네티스 오브젝트가 아니므로 자체적으로 생성, 삭제될 수 없음  - 첫 번째 파드에는 publicHTML 이라는 볼륨이 있어서 이 볼륨은 WebServer 컨테이너의 /var/htdocs에 마운트되어 웹 서버에서 서비스 - 두번째 파드에서는 첫 번째 파드의 동일 볼륨이 ContentAgent 컨테이너에 /var/html의 다른 경로에 마운트돼 있고, ContentAgent는 해당 경로에 작성하고 이 내용을 웹 서버가 서비스 - 세번째 파드는 로그를 작성하는 lovVo1 볼륨을 가지고, 이 볼륨은 WebServer와 LogRotator z컨테이너의 /var/logs 에 마운트  - 사용 가능한..