칼의 치치

Isto Gateway Istio는 쿠버네티스와 같은 컨테이너 오케스트레이션 시스템 위에서 동작하는 오픈 소스 서비스 메시(service mesh) 솔루션입니다. 서비스 메시는 마이크로서비스 간의 통신을 관리하고, 제어하며, 보안을 강화하는 데 사용되는 인프라 계층입니다. Istio는 마이크로서비스 아키텍처 내에서 서비스 간의 통신을 쉽게 만들어주고, 트래픽 관리, 서비스 간의 인증과 인가 처리, 서비스 간의 데이터 모니터링과 같은 기능을 제공합니다. 기본 구성 요소 Istio는 다음과 같은 주요 구성 요소로 이루어져 있습니다: Envoy Proxy: 모든 서비스 인스턴스 옆에 배치되는 경량의 사이드카 프록시. Envoy는 Istio의 데이터 플레인을 구성하며, 모든 진입 및 진출 트래픽을 중재하고, 고..

볼륨 (Volume): Kubernetes에서 볼륨은 컨테이너 내부와 외부 간의 데이터를 공유하기 위한 방법입니다. 볼륨은 컨테이너의 파일 시스템과 독립적으로 존재하며, 컨테이너가 종료되더라도 데이터가 보존됩니다. 예를 들어, 컨테이너 내부에서 생성한 데이터를 다른 컨테이너에서 사용하거나 호스트 시스템의 파일 시스템에 접근할 때 볼륨을 사용할 수 있습니다. 볼륨은 컨테이너에 지속적인 데이터 저장을 제공하지만, 볼륨 자체는 별도의 수명 주기나 관리를 가지지 않습니다. - 호스트 볼륨/nfs/iSCI/Ceph - 컨테이너와 별개의 리소스 영역 , 노드의 스토리지 영역 영구 볼륨 (Persistent Volume): 영구 볼륨은 클러스터 내에서 생성되고 관리되는 스토리지 리소스입니다. 이러한 볼륨은 클러스터 ..

기본적인 환경 변수 사용 환경변수는 컨테이너 내에서 설정되는 간단한 키-값 쌍으로, 애플리케이션의 동작을 조정하는 데 유용 apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-container image: my-app-image env: - name: ENV_VARIABLE_1 value: "value1" - name: ENV_VARIABLE_2 value: "value2" 위와 같이 ENV_VARIABLE_1 : "value1" 등의 값을 정적 설정을 통해서 사용 가능 kubectl exec -it sample-env --env | grep ENV_VARIABLE_1 으로 확인 가능함 아래와 같이 타임존에 대해서 UT..

기본 개념 디플로이먼트는 여러 레플리카셋을관리하여 롤링업데이트나 롤백등을 구현하는 리소스 디플로이먼트> 레플리카> 파드 순으로 관리 1) 신규 레플리카셋을 생성 2) 신규 레플리카셋의 레플리카 수를 단계적으로 늘림 3) 이전 레플리카셋의 레플리카 수를 단계적으로 줄임 2,3 반복 이전 레플리카 셋은 레플리카수를 0으로 유지 * 안정적인 파드 기동 방법으로 추천됨 - 파드 장애시 자동으로 파드 재생성 - 레플리카만으로 배포할 경우 롤링 업데이트 등의 기능을 사용할 수 없음 디플로이먼트가 업데이트(레플리카셋이 생성되는) 되는 조건 레플리카 수 등의 변경등은 업데이트 되지 않는다 실질적으로 파드의 내용 변경이 필요함 즉 레플리카 spec.template의 내용이 변경되어야 실제로 업데이트된다. (spec.te..

레플리카셋 - 파드에 레플리카를 생성하고 지정한 파드수를 유지하는 리소스 - 노드나 파드에 장애가 발생했을 때 지정한 파드 수를 유지하기 위해 다른 노드에서 파드를 기동시켜 주기 때문에 장애 시에도 많은 영향을 받지 않음 (high Availability, LoadBalance를 수행함) - 모니터링은 특정 레이블을 가진 파드 수를 계산하는 형태로 이루어짐 (yaml 형식) - template에 명시된 형태로 pod를 자동 생성함 - replicas로 유지할 pod의 숫자를 정함 - 특정 레이블을 가진 레플리카 수가 부족한 경우 매니 페스트에 기술된 spec.template으로 파드를 생성하고 수가 많을 경우 해당 레이블을 가진 파드 중에서 하나를 삭제함 ( 따라서 해당 모니터링을 위해 selector...

KubeConfig 인증서를 통한 쿠버네티스 API 서버에 대한 접근을 구성파일을 통해 명시하고 사용하는 방식 * 아래와 같이 kubectl 명령어를 통해서 사용하던 방식을 파일로 저장 * KubeConfig 파일은 명시하지 않을시에 쿠버네티스의 디폴트 위치에 있는 파일을 사용하기 때문에 따로 명시하지 않아도 사용 * /root/.kube/config에 존재 KubeConfig File 구성요소 1. Clusters : 개발환경 , 배포환경 등 쿠버네티스 기본 환경에 관한 내용 2. Users : 유저에 대한 정보 , 구분 ,인증 정보 3. Contexts : Users와 Clusters에 대한 정보를 연결해주는 Context 정보 생성 예시 apiVersion: v1 kind: Config cluste..

쿠버네티스는 모든 파드는 노드네임이 존재하나 노드네임을 직접 명시 하지 않으면 랭킹 알고리즘을 통해 적절한 노드에 파드를 생성한다. 스케줄러는 생성할 적절한 노드를 선택하고 파드들의 상태를 확인한다. - kubectl get pods -n kube-system NAME READY STATUS RESTARTS AGE coredns-78fcd69978-5x8np 1/1 Running 0 14d coredns-78fcd69978-fsffz 1/1 Running 0 14d etcd-docker-desktop 1/1 Running 0 14d kube-apiserver-docker-desktop 1/1 Running 0 14d kube-controller-manager-docker-desktop 1/1 Runnin..

pod, deployment, service를 내부적인 목적에 따라서 세트로 묶어서 구분함 쿠버네티스는 시작할때 3가지 네임스페이를 만듦 default: 초기 기본 네임스페이스 kube-system: network나 dns를 위해 사용자들에서 분리해 낸 네임스페이스를 만듦, 실수로 삭제, 수정할 수 없도록 만듦 kube-public: 모든 유저가 사용하는 리소스들을 관리하는 네임스페이스 각 네임스페이스별로 사용할 수 있는 리소스의 양을 정해두고 사용할 수 있음 네임스페이스 안에서는 name으로 각 파드들을 호출할 수 있음 다른 네임스페이스에 존재하는 파드들은 '서비스네임.네임스페이이스.(서비스,파드등 구분).도메인'으로 구분함 ex)db-service.dev.svc.cluster.local kubectl..

- 서비스 애플리케이션의 다양한 구성요소에서의 통신을 위해 사용함 내부의 모든 파드들 간의 연결뿐만 아니라 클러스터 외부와의 연결도 담당함 1. NodePort 쿠버네티스 노드의 ip (192.168.1.2)이고 노드 내부의 파드의 ip는 10.244.0.2인상태에서 외부(192.169.1.10)가 파드에 접속하는 방법 파드의 80 포트(targetPort)를 서비스(10.106.1.12)의 80(port)으로 연결하고 해당 서비스를 노드의 특정포트(nodePort, 30000~32767)에 연결하여 사용함 apiVersion : v1 kind : Servcie metatdata : name: myapp-service spec: type: NodePort ports: - targetPort:80 port..

1. etcd (자세한 설명 : https://tech.kakao.com/2021/12/20/kubernetes-etcd/) 쿠버네티스는 Key-Value형태로 데이터 저장 고가용성 Key-Value 자료구조 ETCD control client로 cli를 통해 서버에 대한 정보를 키-밸류 값으로 가져올 수 있음 쿠버네티스가 ETCD를 활용하여 클러스터에 관한 정보를 저장함 (노트,포드,시크릿) 클러스터에서 어떤 정보를 수정 변경할 때마다 etcd에 저장됨 kube -system 조회를 통해 etcd-master를 확인할 수 있음 마스터 노드에서 확인 가능 다중 마스터 클러스터에서는 각 etcd 서버가 서로를 연결하도록 구성 2. kube-api-server kubectl 명령어로 입력하면 kube-api..