노는 게 제일 좋아

여러 가지 관점이 있겠지만 그냥 나의 여러가지 생각을 한 번 말해보겠다. 1. 서비스의 시작(단일 서비스)서비스가 1개이므로, Argo CD에서 직접 하나의 애플리케이션을 등록 및 관리- 가장 간단한 구조- 여기서 부터 시작해서 관리하게 됨 여기서 고려할 점은 어차피 저장소는 하나이기 때문에 저장소를 잘 관리하면 됨-> gitops 파이프라인을 잘 지키면 됨-> sync Policy도 여기서 잘 생각해봐야함-> lint 와 같이 문법 관리, schema validation과 같이 문법을 관리해야함-> git commit, git pr, branch 규칙을 잘 지킬 것-> 분리할 수 있는 value.yaml 파일을 잘 분리시켜야 좋음 또한 Argo CD가 배포 클러스터에 대한 권한 관리가 잘 되어있어야함..

접근 제어는 여러가지 방법이 있음 Security Group을 통한 IP ALB Listener Rule에서 CIDR 기반 필터 WAF를 ALB에 연결 Ingress Controller Annotation을 통한 IP 여기선 ALB - ingress를 이용한 접근 제어를 해보려고 함 왜?Security Group은 AWS resource라서 생성해야함-> 생성하면 삭제도 해야하고 관리해야함-> 나의 경우엔 영구적으로 필요한 것은 아니기 때문에 굳이?라는 생각Listener Rule-> 같은 AWS 리소스WAF-> 같은 리소스 리소스는 Terraform으로 생성하는 것이 규칙이기 때문에 진짜 임시로 하기 위해서 만든다는 것이 정말 비효율적이라고 생각했던 찰나에 ingress 등장사실 이 역시 ALB에..

주요 옵션Node Selector: 특정 레이블 노드에 배치Node Name: 특정 노드에 강제 배치Taints & Tolerations: 노드 접근 제어Node Affinity & Pod Affinity/Anti-Affinity: 조건 및 Pod 관계 기반 배치Topology Spread Constraints: 균등한 Pod 분산1. Node SelectorNode Selector는 Pod를 특정 레이블이 있는 노드에 배치하는 가장 간단한 방법spec: nodeSelector: disktype: ssd gpu-vendor: nvidia주요 활용 사례:SSD 디스크 노드에 데이터베이스 배치GPU 노드에 ML 워크로드 배치특정 CPU 아키텍처노드 선택특징: 레이블 key-value가 정확히 일..

1. 클라이언트 요청 및 DNS 쿼리클라이언트가 curl, 브라우저 등으로 service.example.com 요청 전송DNS 쿼리 수행: 권한 DNS 서버로부터 A/AAAA 레코드 응답 수신AWS: Amazon Route 53 권한 네임서버GCP: Google Cloud DNS 권한 네임서버 2. 클라우드 로드밸런서(LB) 처리외부 로드밸런서로 TCP 트래픽 수신L4 포워딩: 클라우드 로드밸런서가 수신한 TCP 세션을 Kubernetes 노드의 NodePort로 전달하는 과정이 과정을 통해 외부에서 들어온 연결이 특정 노드 포트로 ‘전환’되어 Service 트래픽이 클러스터 내부로 유입됨 Session Handoff 단계에서 클라이언트와 백엔드 노드 간의 연결 매핑 및 소스·대상 포트 정보가 유지되어 ..

Pod는 우리가 생각한 대로 동작함예를 들면 Pod 는 image tag, image repo를 입력하면 image를 pulling 함하지만 정확하게 구체적인 동작을 알지 못함어떻게 그렇게 할 수 있는 것인지?알아보자 Pod란Pod는 Kubernetes에서 가장 작은 배포 단위로, 하나 이상의 컨테이너를 그룹화하여 네트워크와 스토리지를 공유하는 구조 모든 컨테이너는 공통 IP, 볼륨, 네임스페이스를 공유각 Pod는 단일 네임스페이스에 속함기본적으로 하나의 컨테이너를 포함하되, sidecar 패턴 등으로 복수의 컨테이너를 구성 가능Pod가 생성될 때 자동으로 ServiceAccount와 연결됨 Pod를 만들 때, token을 집어넣으면 되지 않았을까?, 왜 ServiceAccount, Secret을 통해..

Redis는 싱글스레드? Redis는 데이터 처리를 담당하는 메인 이벤트 루프가 싱글스레드로 동작하는 것 -> redis-client 와 싱글스레드로 동작함-> 싱글스레드이기 때문에 간섭, lock 없이도 빠르게 작동 가능함 하지만 백그라운드에서 동작하는 작업은 멀티스레드로 작동 -> 그렇기 때문에 우리가 redis prod 상황에서도 백업이 가능함더군다나 6.0부터 도입된 I/O 멀티스레딩: 클라이언트 요청을 처리할 때의 네트워크 I/O를 멀티스레드로 병렬 처리 가능 Redis는 Replica로 하면 다 된다? Replica(슬레이브)를 두면 읽기 부하를 분산할 수 있고, 장애 발생 시 failover도 가능한 것이 사실하지만 쓰기 부하는 절대 분산되지 않음 -> 쓰기는 여전히 Master에만 가..

istio를 실무에서 사용하는 방법클러스터 내 서비스 간의 보안 통신을 위해 istio를 주로 사용함주로 Sidecar mode를 이용-> 파드 단위로 트래픽 제어 또는 보안정책, 모니터링이 필요하기 때문sidecar로 주입되기 때문에 애플리케이션 코드 수정없이 관리 가능하지만 sidecar이기 때문에 리소스 사용량이 조금 높으면서, sidecar이기 때문에 파드 생성 시, 주입되어야 해서 느림 ambient mode-> 노드 단위에서 프록시를 관리파드보다 위에서 관리함(L4기반)리소스 효율적이거나 대규모일 때 고려할 만 함 istio 관리 운영helm, istioctl 로 제어가 가능하지만istio는 직접 관리하지 않고 istio operator로 간접관리 경우가 있음istioctl을 래핑하고 CRD..

RBAC (Role-Based Access Control)란?RBAC는 Kubernetes 내 리소스에 대한 접근을 제어하기 위한 권한 기반 접근 제어   RBAC의 구성 요소1. Role / ClusterRoleRole: 특정 namespace 내 권한 정의ClusterRole: 클러스터 전체 혹은 여러 namespace에 걸친 권한 정의# Role 예시apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: namespace: dev name: pod-readerrules:- apiGroups: [""] resources: ["pods"] verbs: ["get", "list"]2. RoleBinding / ClusterRoleBindingRo..

정의Istio는 마이크로서비스 아키텍처(MSA)에서 서비스 간 통신을 관리하고, 보안, 관찰 가능성, 트래픽 관리를 지원하는 오픈소스 서비스 메쉬 플랫폼https://istio.io/latest/about/service-mesh/ 왜?Kubernetes 오브젝트만으로의 한계 트래픽 라우팅Service, Ingress버전별 분기, 트래픽 비율 분배 불가능보안 (mTLS)없음 (직접 구현 필요)Pod 간 통신 암호화가 기본 미지원인증/인가RBAC 위주서비스 간 세밀한 정책 적용 어려움트래픽 제어없음Retry, Timeout, Circuit Breaker 구현 어려움모니터링Metrics 수집 별도 구현세부 트래픽 분석 어려움정책 관리분산된 설정전역적으로 통제하기 어려움 Istio를 사용하면 가능한 기능들..

여기서 중요한 것은 ExternalDNS임 만약 public 이 필요 없다면 CoreDNS + Traefik 로 사용  정의external dns란 쿠버네티스 클러스터 내부 리소스를 외부 DNS 서비스와 연동하여 DNS 레코드를 자동으로 생성하고 관리할 수 있게 해주는 오픈소스  목적클러스터 내 서비스와 외부 도메인을 연결DNS 레코드 자동 생성 및 업데이트쿠버네티스의 Service 또는 Ingress 리소스를 기반으로 외부 DNS 제공자에 A 레코드 또는 TXT 레코드를 생성하고 삭제-> 주로 Ingress로 사용됨다양한 DNS 제공자와 연동, AWS Route53, Google Cloud DNS, Azure DNS 등 여러 퍼블릭 도메인 공급자와 호환 작동ExternalDNS를 배포하면 인그레스 리소..