Category: Kubernetes

0

Istio - Sidecar Injection

목차 Istio - Locality Load Balancing (지역 로드 밸런싱) Istio - Sidecar Injection Istio - Istio 설치 및 addon 설치 Istio 란? 참고 https://istio.io/latest/docs/ops/deployment/architecture/ https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/ https://happycloud-lee.tistory.com/104 Sidecar injectionIstio는 Pod 안에 Envoy proxy container 를 Sidecar 패턴으로 생성하여 Service Mesh (discovery, connect, monitor) 를 합니다. Pod안에 Proxy container를 삽입하는것을 Sidecar Injection 이라고 부릅니다. Istio 에서 Sidecar Injection 은 Kubernetes 의 MutatingAdmissionWebhook 을 사용하여 구현됩니다. 이것은 Kubernetes의 API Server에 대한 요청 처리 중에 사용되며, 새로운 Pod가 생성될 때 Istio가 Sidecar Proxy 컨테이너를 자동으로 추가하는 것을 가능하게 합니다. Istio가 Sidecar를 주입하는 방식은 크게 두 가지 방법이 있습니다. 첫 번째는 자동 주입 방식으로, 이는 기존의 Kubernetes 오브젝트에 Istio의 Sidecar Proxy를 자동으로 추가합니다. 이를 위해서는 Istio의 설치 시 Kubernetes 리소스를 수정해야 합니다. 두 번째 방식은 수동 주입 방식으로, 이는 기존의 Kubernetes 오브젝트에 Istio의 Sidecar Proxy를 수동으로 추가해야 합니다. Sidecar 자동 주입 방식

0

Istio - istioctl

목차 Istio - Locality Load Balancing (지역 로드 밸런싱) Istio - Sidecar Injection Istio - istioctl Istio 란? 공식 홈페이지 https://istio.io/latest/docs/setup/getting-started/ Istioctl 설치brew install istioctl Istio Profile 확인istioctl profile list 특정 Profile 설치

0

CNCF (Cloud Native Computing Foundation)

공식 홈페이지 https://www.cncf.io/ CNCF 란CNCF(Cloud Native Computing Foundation)는 Linux 재단( Linux Foundation)의 하위 조직으로, 클라우드 네이티브 컴퓨팅을 지원하고 발전시키는 오픈소스 프로젝트의 생태계를 관리하고 유지보수하는 비영리 단체입니다. CNCF는 클라우드 네이티브 애플리케이션을 위한 오픈소스 기술의 개발, 유지보수, 보급을 촉진하고 있으며, 이를 위해 Kubernetes, Prometheus, Envoy, CoreDNS, containerd 등 다양한 프로젝트를 관리하고 있습니다. 이러한 기술들은 모두 클라우드 네이티브 애플리케이션의 구축, 배포, 운영을 위해 필요한 기반 기술을 제공하고 있습니다. CNCF는 이러한 오픈소스 프로젝트의 개발, 운영, 확장을 지원하며, 이를 통해 클라우드 네이티브 컴퓨팅 생태계를 확장하고 발전시키고 있습니다. 또한 CNCF는 이러한 프로젝트를 사용하는 사용자 및 개발자 커뮤니티를 지원하고, 교육 및 인증 등 다양한 활동을 통해 클라우드 네이티브 기술의 활용과 보급을 촉진하고 있습니다.

0

Helm

목차 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod Post not found: k8s/k8s 공식 홈페이지 https://istio.io/latest/docs/setup/getting-started/ Helm 이란Helm은 Kubernetes 애플리케이션 배포 관리 도구입니다. Helm은 패키지화된 Kubernetes 리소스를 쉽게 배포하고 관리할 수 있도록 해주는 툴입니다. Helm은 chart 라는 것을 사용하여 Kubernetes 리소스를 패키지화합니다. Chart는 애플리케이션의 구성과 릴리즈 정보를 포함하고 있습니다. Chart를 사용하면 애플리케이션을 배포하고 업데이트하는 프로세스를 쉽게 자동화할 수 있습니다. Helm은 또한 Helm Repositories 라는 것을 제공합니다. 이는 Helm Charts를 저장하고 공유할 수 있는 저장소입니다. 공개 또는 비공개 저장소를 사용하여 애플리케이션을 더 쉽게 배포하고 공유할 수 있습니다. Helm은 Kubernetes의 많은 기능을 지원합니다. 예를 들어, Helm은 릴리즈를 롤백하는 기능을 제공하며, 릴리즈 히스토리를 추적할 수 있습니다. 또한 Helm은 템플릿을 사용하여 리소스를 더 쉽게 생성할 수 있습니다.

0

Istio 란?

목차 Istio - Locality Load Balancing (지역 로드 밸런싱) Istio - Sidecar Injection Istio - Istio 설치 및 addon 설치 Istio 란? 공식 홈페이지 https://istio.io/latest/docs/setup/getting-started/ https://gruuuuu.github.io/cloud/service-mesh-istio/ Istio 란? Istio는 서비스 매쉬 (Service Mesh) 를 구현하기 위한 오픈소스 플랫폼 서비스 매쉬는 마이크로서비스 아키텍처에서 많은 서비스 인스턴스들이 동작하는 환경에서, 서비스들 간의 통신을 관리하고 모니터링할 수 있도록 해주는 기술 입니다. Istio는 Kubernetes 환경에서 동작하며, 다양한 기능을 제공합니다. 예를 들어, 서비스 간의 통신 보안, 트래픽 라우팅, 부하 분산, 서비스 간의 장애 처리 등을 제공합니다. 이러한 기능을 통해 서비스 매쉬를 쉽게 구현할 수 있고, 서비스들 간의 통신 관리를 간편하게 할 수 있습니다. Istio Architecture

0

Service Mesh

목차 Istio - Locality Load Balancing (지역 로드 밸런싱) Istio - Sidecar Injection Istio - Istio 설치 및 addon 설치 Istio 란? 공식 홈페이지 https://istio.io/latest/docs/setup/getting-started/ https://gruuuuu.github.io/cloud/service-mesh-istio/ 서비스 메쉬 서비스 매쉬(Service Mesh)는 분산 시스템에서 서비스 간의 통신을 관리하고 모니터링하는 아키텍처 패턴 마이크로서비스 아키텍처에서는 여러 개의 작은 서비스로 분할되어 동작하며, 각각의 서비스는 서로 다른 언어, 프레임워크, 플랫폼에서 개발될 수 있습니다. 이러한 분산 시스템에서는 서비스 간의 통신을 관리하는 것이 중요합니다. 서비스 매쉬는 네트워크 인프라에서 서비스 간의 통신을 추상화하고, 서비스 간의 통신을 보안하고, 부하 분산을 수행하며, 서비스 간의 장애 처리를 제공합니다. 서비스 매쉬는 서비스 간의 통신을 중앙 집중적으로 관리하는 기존의 아키텍처 패턴과는 달리, 분산 시스템에서는 서비스 매쉬를 사용하여 각각의 서비스가 통신 관리를 담당하게 됩니다. 이로 인해, 각각의 서비스는 독립적으로 확장하고, 업그레이드하며, 유지보수할 수 있습니다.

0

CoreDNS

목차 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod 쿠버네티스 - Data Plane 쿠버네티스 - Control Plane Post not found: k8s/k8s 참고 공식 문서 https://kubernetes.io/docs/concepts/services-networking/service/ CoreDNS CoreDNS는 쿠버네티스(Kubernetes) 클러스터 내에서 DNS(Domain Name System) 기능을 제공하는 가벼운 DNS 서버 쿠버네티스 클러스터 내의 파드, 서비스 및 기타 리소스를 DNS 이름으로 매핑하여 네트워크 통신에 사용됩니다. CoreDNS는 클러스터 내부에서 DNS 조회를 처리하기 위해 디폴트로 설치되는 DNS 서버입니다. 이전에는 쿠버네티스에선 kube-dns 라는 DNS 서버가 사용되었지만, 쿠버네티스 버전 1.11부터는 CoreDNS가 디폴트로 사용됩니다. CoreDNS 기능

0

쿠버네티스 - ConfigMap

목차 쿠버네티스 - Secret 쿠버네티스 - ConfigMap 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod 쿠버네티스 - Data Plane 쿠버네티스 - Control Plane Post not found: k8s/k8s ConfigMap 쿠버네티스(ConfigMap)은 애플리케이션의 설정 데이터를 저장하고 관리하기 위한 리소스 설정 데이터는 키-값 쌍으로 구성되며, 애플리케이션에서 필요한 설정 값을 포함할 수 있습니다. ConfigMap은 클러스터 수준 또는 네임스페이스 수준에서 생성될 수 있으며, 클러스터 수준의 ConfigMap은 모든 네임스페이스에서 사용할 수 있습니다. ConfigMap은 주로 환경 변수, 설정 파일, 명령행 인수 등과 같은 애플리케이션 구성에 사용됩니다. 이러한 구성 데이터는 컨테이너 이미지와 분리되어 애플리케이션을 다양한 환경에서 재사용하거나 구성을 변경할 수 있도록 합니다. 또한 ConfigMap은 애플리케이션을 업데이트하거나 배포하는 동안 구성을 쉽게 관리할 수 있도록 도와줍니다. ConfigMap은 YAML 또는 JSON 형식으로 정의되며, 쿠버네티스 클러스터에 생성 및 적용됩니다. ConfigMap을 생성한 후에는 해당 ConfigMap을 사용하려는 Pod의 컨테이너에 마운트하거나 환경 변수로 설정할 수 있습니다. 이렇게 하면 애플리케이션은 ConfigMap에서 정의된 설정 값을 사용할 수 있습니다. 예를 들어, ConfigMap에서 “db_host”라는 키에 대한 값으로 “database.example.com”을 설정하면, 애플리케이션은 이 값을 읽어와 데이터베이스 호스트로 사용할 수 있습니다. ConfigMap은 클러스터나 네임스페이스 수준에서 변경 및 관리할 수 있으므로, 변경된 설정 값은 애플리케이션을 다시 시작하지 않고도 즉시 적용될 수 있습니다. 파일을 통째로 ConfigMap 으로 만들기

0

쿠버네티스 - ReadinessProbe & LivenessProbe

목차 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod Post not found: k8s/k8s Pod Pod 는 쿠버네티스에서 관리하는 가장 작은 배포 단위 쿠버네티스는 Pod 을 이용해 Container 를 관리 한다. Pod 는 단일 Node 에서 실행되며 각각의 Pod 는 고유한 IP 와 Host 이름을 가지고 있다. 쿠버네티스는 Pod 을 배포 하고 Pod 안에 한개 이상의 컨테이너가 존재한다. Pod 내 Container는 모두 동일한 Host 에서 실행되며 Network 와 저장소를 공유한다. apiVersion: v1kind: Podmetadata: name: echo labels: app: echospec: containers: - name: app image: ghcr.io/subicura/echo:v1 다중 컨테이너

0

쿠버네티스 - k9s

목차 Post not found: k8s/namespace Post not found: k8s/ingress Post not found: k8s/deployment Post not found: k8s/replicaset Post not found: k8s/node Post not found: k8s/pod

0

쿠버네티스 - Resource 제한

목차 Post not found: k8s/namespace Post not found: k8s/ingress Post not found: k8s/deployment Post not found: k8s/replicaset Post not found: k8s/node Post not found: k8s/pod ResourcePod의 spec에서 resources 필드를 통해 리소스를 제한할 수 있습니다. resources 필드는 limits 와 requests 로 구성됩니다. limits는 Pod가 사용할 수 있는 최대 리소스 양을 설정하고, requests는 Pod가 최소한으로 필요로 하는 리소스 양을 설정합니다. apiVersion: v1kind: Podmetadata: name: my-podspec: containers: - name: my-container image: nginx resources: limits: cpu: "1" memory: "512Mi" requests: cpu: "500m" memory: "256Mi"

0

쿠버네티스 - 토폴로지 인지 힌트 (Topology Aware Hint)

목차 Post not found: k8s/namespace Post not found: k8s/ingress Post not found: k8s/deployment Post not found: k8s/replicaset Post not found: k8s/node Post not found: k8s/pod 참고 https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/kubernetes-versions.html https://kubernetes.io/ko/docs/concepts/services-networking/topology-aware-hints/ https://tetrate.io/blog/minimizing-cross-zone-traffic-charges-with-istio/ 토폴로지 인지 힌트 (Topology Aware Hint)쿠버네티스 클러스터가 멀티-존(multi-zone) 환경에 배포되는 일이 점점 많아지고 있다. 토폴로지 인지 힌트 는 트래픽이 발생한 존 내에서 트래픽을 유지하도록 처리하는 메커니즘을 제공한다. 이러한 개념은 보통 “토폴로지 인지 라우팅”이라고 부른다. 서비스의 엔드포인트를 계산할 때, 엔드포인트슬라이스 컨트롤러는 각 엔드포인트의 토폴로지(지역(region) 및 존)를 고려하여, 엔드포인트가 특정 존에 할당되도록 힌트 필드를 채운다. 그러면 kube-proxy와 같은 클러스터 구성 요소는 해당 힌트를 인식하고, (토폴로지 상 가까운 엔드포인트를 사용하도록) 트래픽 라우팅 구성에 활용한다. 토폴로지 인지 힌트(Topology Aware Hints) 는 클라이언트가 엔드포인트를 어떻게 사용해야 하는지에 대한 제안을 포함시킴으로써 토폴로지 인지 라우팅을 가능하게 한다. 이러한 접근은 엔드포인트슬라이스(EndpointSlice) 및 엔드포인트(Endpoint) 오브젝트의 소비자(consumer)가 이용할 수 있는 메타데이터를 추가하며, 이를 통해 해당 네트워크 엔드포인트로의 트래픽이 근원지에 더 가깝게 라우트될 수 있다. 비용을 줄이거나 네트워크 성능을 높이기 위해, 인접성을 고려하여 트래픽을 라우트할 수 있다.

0

Istio - 토폴로지 인지 힌트

목차 Post not found: k8s/namespace Post not found: k8s/ingress Post not found: k8s/deployment Post not found: k8s/replicaset Post not found: k8s/node Post not found: k8s/pod 참고 https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/kubernetes-versions.html https://kubernetes.io/ko/docs/concepts/services-networking/topology-aware-hints/ https://tetrate.io/blog/minimizing-cross-zone-traffic-charges-with-istio/ 쿠버네티스 Node Zone 확인kubectl get nodes -L topology.kubernetes.io/zone Istio 에 토폴로지 인지 힌트 추가apiVersion: v1kind: Servicemetadata: annotations: # topology-aware-hints 추가 service.kubernetes.io/topology-aware-hints: auto name: istiod namespace: istio-system

0

쿠버네티스 - Namespace

목차 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod Post not found: k8s/k8s Namespace 란? 쿠번네티스 Cluster 들을 논리적으로 나누기 위한 수단. Namespace 를 이용하면 Pod, Service, Volumn 과 같은 다양한 리소스를 분리하고 격리할 수 있다. Namespace 생성kubectl create namespace your-namespace-name apiVersion: v1kind: Namespacemetadata: name: [Namespace 이름] kubectl apply -f namespace.yaml

0

쿠버네티스 - Ingress

목차 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod Post not found: k8s/k8s Ingress