Learn k8s (입문) - Githubissues

세팅 과정을 통해 알아보는 k8s A-Z

물리 서버 N + 3 대

== 노드 1 ~ N + 3
모든 노드에 기본 세팅
- 배포판 운영체제 설치 및 최신화
- 보안 설정
- "컨테이너 런타임 설치"
  
  Docker, containerd, cri-o ...
- cgroups 및 네임스페이스 설정
  
  컨테이너 환경에서 격리된 컨테이너의 영역에서 제공된 호스트의 리소스를 사용할 수 있게 해줃다 컨테이너 런타임에 맞게 설정
- 컨테이너 네트워크 설정
  
  IP Forwarding 활성화 브릿지 네트워크 활성화
- SwapOff 처리 ?
- 디스크 및 파일 시스템 설정
- 디스크 용량 확보
- OverlayFS (이미지 파일 공유)
- I/O 성능 최적화
- 로그 관리 및 모니터링 설정
- 로깅 및 모니터링 도구 설치
- 로그 디스크 사용량 관리
- 시간 동기화
- "kubelet, kubeadm, kubectl" 설치
  
  부팅 시 자동으로 실행되도록 설정
마스터 노드 3대
- kubeadm init 실행
  
  --control-plane-endpoint LB 주소 입력
- cm = 컨트롤러 매니져
  클러스터 상태를 관리하는 여러 컨트롤러(예: Deployment, ReplicaSet 컨트롤러 등)를 수행
  - 클러스터 내 리소스의 상태를 모니터링하고 조정하여 클러스터의 원하는 상태를 유지하는 역할
  - 리소스 상태 유지 "리소스"라는 것을 통해 선언적으로 현 상태를 정의한다 k8s는 정의된 상태가 유지 될 수 있도록 해준다 (정의된 상태가 보장됨)
  - 컨트롤러 매니저에는 여러 종류의 컨트롤러가 포함되어 있으며, 각각의 컨트롤러는 특정한 리소스를 관리한다 각 리소스에 맞게 클러스터 상태를 맞춰주는 역할을 실제로 수행하는 요소
  - 리소스 컨트롤러는 해당되는 리소스들을 계속 감시하며 desired spec이 될 수 있도록 역할을 수행
- etcd
  설정 저장소 - 고가용
  - 각 pod들의 주소 정보 등 클러스터 전반에 중요한 정보를 관리
- api 서버
  - 컨트롤 플레인 요소들을 제어하는 중앙 제어 서비스
  - 보통 LB로 분산하여 통신, 각 노드에서 개별 동작 (stateless)
- sched
  - 파드를 클러스터의 적절한 노드에 배치(scheduling)하는 역할을 주로 담당
  - 주기적으로 처리하는 작업(Job)보다는 특정 이벤트에 따라 실행되는 트리거 기반으로 동작
  - 컨트롤 플레인의 상태를 지속적으로 모니터링하고 필요에 따라 파드를 스케줄링
  - 파드 대기열 모니터링
  - 노드 상태 모니터링
  - 등등
- 나머지 2대에서 마스터로 조인
  
  kubeadm join --control-plane
- 마스터 노드로 조인되면서 일부 요소는 리더 선출
  - cm (Active-Standby)
  - 각 요소가 API 서버에 계속 자신의 상태를 보고한다 (health check)
  - 리더 자격을 임대 (lease)하는 경우 임대 정보에 ttl 정보가 있다
  - Standby 상태에 있는 요소들은 주기적으로 ttl이 갱신되는지 확인한다
  - 갱신되지 않으면 리더로 승격되기 위한 프로토콜을 진행한다
  - etcd (Leader-Follower)
    
    Raft (Leader, Candidate, Follower)
  - Leader = write, Follower = read / 일관성 유지
  - 분산 합의 구조로 HA 제공
  - 리더로 선출된 노드는 주기적으로 Heartbeat 메시지를 모든 팔로워에게 전송하여 자신이 아직 활성 상태임을 알린다
  - 일정 시간 동안 팔로워 노드들이 리더의 Heartbeat 메시지를 받지 못하면, 리더가 장애가 발생했다고 간주하고
  - 팔로워 중 하나가 Candidate로 전환되어 투표 진행 > 승격
  - sched (Active-Standby)
    
    cm 과 동일 하나의 리더 스케줄러만이 파드를 스케줄링하도록 보장하여 중복 스케줄링을 방지하고, 스케줄링 작업의 일관성을 유지 HA 제공
- 네트워크 플러그인 (CNI) 설치 (ex_ Flannel)
- 팟이 새로 생성되면 Kubelet가 CNI 플러그인 실행한다 (프로토콜 실행)
  
  CNI: 컨테이너 네트워크를 설정하고 관리하기 위한 표준 인터페이스 여기서는 Flannel 사용
- Flannel의 CNI 플러그인은 새로 생성된 Pod의 네트워크 정보를 etcd에 저장하여 네트워크 구성 정보가 전체 클러스터에 동기화
- Kubernetes API 서버와 통신하여 클러스터 내 노드와 Pod들의 네트워크 정보를 확인하면서 동기화
  
  주기적으로 네트워크 상태와 서브넷 정보를 etcd에서 조회 Flannel은 각 노드에서 개별적으로 동작
- 잘 구성되었다면 kubectl get nodes 에 3대가 ready로 노출됨
워커 노드
- 워커 노드로 조인
  
  kubeadm join
- 잘 조인 되었다면,
- 네트워크 플러그인은 일반적으로 마스터 노드에서 한 번 설치하면 DaemonSet 형태로 클러스터의 모든 노드에 배포됨
- kubectl get nodes 로 조회 가능
  
  kubectl을 사용하려면, kubeconfig 필요 /etc/kubernetes/admin.conf 마스터 노드의 admin.conf 를 워커 노드의 kubeconfig 경로로 복사

kubectl을 통해 kube API와 통신하여 여러가지 리소스를 등록해보자 ("apply")

리소스 정의
- Kubernetes 오브젝트의 desired state (원하는 상태) 를 정의
오브젝트
- 리소스 정의를 기반으로 Kubernetes 클러스터 내에 생성되는 실체
리소스 정의 필드
- apiVersion
- Kubernetes API 의 그룹/버전
- Kubernetes API 종류는 우선 그룹으로 나뉘고, 각자 버저닝
- kind
- 오브젝트 유형
- metadata
- name: 오브젝트 이름
  
  namespace 별로 유일
- namespace: 오브젝트가 속한 네임스페이스
- label: 오브젝트를 구분하고 분류하기 위해 사용
  
  특정 조건을 만족하는 오브젝트를 선택하고 그룹화 할 수 있다 특정 오브젝트 유형에서 label을 활용해서 오브젝트를 선택할 수 있다 (ex_ service-a label의 pod 들에 대한 로드밸런싱을 정의) ...
- annotation: 오브젝트에 추가 정보를 저장
  - Kubernetes 시스템 자체에서는 Annotation을 사용하지 않는다.
  - 배포 날짜, apply 한 담당자 정보, 빌드 정보 등
  - annotation = 주석
- spec (desired state)
- 리소스마다 필드가 다르다
- 오브젝트의 구체적인 desired state (이 상태를 유지시켜준다)
- status (actual state)
- 현재 오브젝트의 실제 상태 정보
- k8s 시스템에 의해 갱신됨
- cm의 컨트롤러가 주기적으로 리소스 정의를 확인해서 desired state 와 다르면 상태를 맞춰주기 위한 동작을 수행
리소스 종류
- Pod
  
  Kubernetes에서 가장 작은 배포 단위로, 하나 이상의 컨테이너가 함께 실행되는 환경을 제공 하나의 Pod 내에서 여러 컨테이너가 함께 실행되며, 같은 네트워크와 저장소 리소스를 공유 파드의 주요 용도는 애플리케이션을 컨테이너화하여 실행하는 것
- spec.name: 동일 pod 내에서 컨테이너를 참조할 때 필요 (namespace::pod-name::container-name)
  
  Prometheus와 같은 모니터링 도구가 로그 수집할 때 식별 정보로 사용 등
- 아래 상황은 애초에 label을 잘못 지정한 case 이긴 하나, 동작이 궁금해서 가정함
  
  Pod 리소스 정의 > name: pod-a, label: test-app, container.image: service-a apply >>> [pod-a] ReplicaSet 리소스 정의 > name: rp-b, replica: 3, label: test-app, container.image: service-b apply >>> [pod-a, rp-b-X, rp-b-Y] 이 상태에서 pod-a가 시스템 이슈로 down 되었고, ReplicaSet 컨트롤러가 먼저 이를 인지하고 동작하면
  
  [rp-b-X, rp-b-Y, rp-b-Z] 이후에 Pod 컨트롤러가 이를 인지하고 pod-a를 띄움 [rp-b-X, rp-b-Y, rp-b-Z, pod-a] ReplicaSet 컨트롤러가 replica 3을 유지하기 위해 하나를 다시 지움 가장 오래된 pod을 먼저 죽일 확률이 높을 "수도" 있음 아무튼 반복하다가 [pod-a, rp-b-?, rp-b-?] 가 될 떄까지 반복하게 된다 동작을 이해하기 위해 가정했지만, 애초에 다른 image의 컨테이너가 포함된 pod을 묶어서 replica set 으로 관리하지 않을테니, 정상 구성에서는 벌어지지 않는다
- ReplicaSet
- spec:replica: 지정된 수의 Pod을 유지
- spec.template: 적용할 Pod 리소스를 생성 & 적용 (필수값)
- spec.selector: 정의된 Pod 오브젝트 중 해당하는 label의 Pod에 적용
- replica set은 pod이 여러개 생기기 때문에 ReplicaSet의 'name-랜덤문자열' 형태로 생성된다
- "(!!)" 그래서 selector를 label로 해야 pod의 이름이 바뀌어도 참조할 수 있다
- 다만 위 Pod 에서 예시를 들었던 케이스와 같이, label을 잘 지정해 줘야 한다 "주의"
- "???????????"
  
  Pod 템플릿을 직접 수정해야 합니다 따라서, Pod를 업데이트하려면 기존 ReplicaSet을 삭제하고 새로운 템플릿으로 새 ReplicaSet을 생성해야 합니 이 과정에서 서비스 중단이 발생할 수 있습니다.
- Deployment
- 애플리케이션을 선언적으로 업데이트하기 위한 리소스
- ReplicaSet을 기반으로 하지만, 롤링 업데이트, 롤백, 스케일링 등 더욱 강력한 기능을 제공
- "???????????"
- StatefulSet
- DaemonSet
  
  클러스터 내 모든 노드에서 특정 파드를 하나씩 설치
- Job
  
  지정된 수의 파드가 완료될 때까지 실행
- CronJob
  
  주기적인 작업을 예약
- Service
  
  파드와 외부 트래픽 간의 인터페이스를 제공 클러스터 내에서 동적인 파드 IP를 관리하고, 로드 밸런싱을 통해 트래픽을 여러 파드에 분배 "아까 궁금했던거" ClusterIP, NodePort, LoadBalancer, ExternalName, ...
- ConfigMap
  
  애플리케이션에 필요한 구성 데이터를 저장하고 관리
- Secret
- PV
- PVC
- Namespace
  
  클러스터 내 리소스를 논리적으로 구분하는 단위 etcd 자체를 아마도 namespace 단위로 구성하겠지? > YES
- kubeconfig은 namespace 별로 파일이 존재하지 X
  - kubeconfig 파일은 Kubernetes 클러스터에 접속하기 위한 설정 정보를 담고 있는 파일이다
    
    클러스터 주소, 사용자 인증 정보, namespace 정보 등이 포함
  - 단순한 정보일뿐 인증 파일이 아니다 "!!!"
  - 인증은 kubeconfig에 명시된 방법에 의해 수행한다
    
    token, cert, id/pw 등 권한 검증은 Role-Based Access Control (RBAC)을 통해 수행
- Ingress
  
  클러스터 내 HTTP 및 HTTPS 트래픽을 외부로부터 받아들여 적절한 서비스로 라우팅 외부 >>> 클러스터
- NetworkPolicy
  
  클러스터 내에서 파드 간 네트워크 접근 제어하는 Pod-to-Pod 통신: 클러스터 내부의 Pod 간에 주고받는 네트워크 트래픽을 제어합니다. Namespace-to-Namespace 통신: Namespace 간의 Pod 통신을 제어합니다.
- HPA
- VPA
  
  파드에 할당된 CPU와 메모리 리소스를 자동으로 조정
- Pod의 requests 및 limits 값을 자동으로 조정합니다. VPA는 Pod의 리소스 사용량을 모니터링하고, 과거 사용량 데이터를 기반으로 최적의 requests 및 limits 값을 계산
- 사용자가 지정한 최소 및 최대 리소스 값을 준수
- request, limit 없이 약간 자동으로 해주는 느낌 (min max는 두고)
- ResourceQuota
  
  네임스페이스 수준에서 사용 가능한 리소스의 총량을 제한
- ...
- ServiceAccount 등을 활용하면 네트워크 요청에 대한 인증도 k8s에 의해 제공 받을 수 있다..! (인증 데이터는 오브젝트로 etcd에서 관리된다)

추가 궁금증

ReplicaSet ? Deployment ? 정확하게 차이점 이해 못함
"주의할 점은, k8s는 단일 pod의 재생성을 보장하지 않는다 > 맞는지 잘 모르겠다. 뭔가 LLM을 믿어도 되는지 혼선이 조금 있는 정보로 보인다"
- 문제가 생겨서 죽으면 다시 띄워주지만, 다시 뜨지 않을 수도 있다 ?
- 특히 replicaSet 등에 의해 처리되는 부분이 있다면, 이 설정이 우선되며, 이 방식이 권장된다 ?
하나의 마스터 노드에 컨트롤 플레인 요소 apiserver, etcd, cm, sched 등을 한 노드에 모두 설치했는데, 이것들도 각각 하나의 노드에 전용으로 설치해도 되는건가?

"LLM 신뢰 못하겠음"
request, limit 지정해도 약간 컨테이너 메모리는 10% 수준에서 쓰는 만큼 늘려가며 쓴다고 알고 있었는데 맞나?
- request를 고려해서 Pod을 배치
- limit 넘게 쓸 수 없음
- limit 내에서 어플리케이션이 쓰는 만큼 메모리를 먹는다는 의미
- 10% 줬다가 더 쓰면 추가로 할당해주고, 뭐 이런 식은 아닌것 같다
- 다만, VPA를 적용하면 얼추 비슷하게 가능한 것 같기도? "n2c에 VPA가 적용되어 있던건가?"
Pod 스케쥴링

Kubernetes에서 Pod을 "스케줄링"한다는 것은 Pod를 실행할 적절한 노드를 선택하고, 해당 노드에 Pod를 배치하는 일련의 과정 https://blog.kubesimplify.com/kubernetes-scheduling-the-complete-guide

CRI-O ?

https://chatgpt.com/c/672f34f6-fc14-8002-83a8-6e97209e1781

CRI-O는 Kubernetes와 컨테이너 오케스트레이션에서의 필요성을 충족시키기 위해 탄생했습니다. 그 배경에는 Kubernetes의 컨테이너 런타임에 대한 표준화와 간소화 요구가 있었으며, 이를 위해 CNCF(Cloud Native Computing Foundation)에서 2016년에 개발을 시작했습니다.

CRI-O의 탄생 배경과 발전 과정을 살펴보면 다음과 같습니다: Kubernetes의 성장과 Docker의 한계: Kubernetes는 초기부터 Docker를 기본 컨테이너 런타임으로 사용했지만, Docker는 범용 컨테이너 관리 도구로 설계되었기 때문에 Kubernetes에 불필요한 기능이 많았습니다. 이러한 기능은 Kubernetes에 필요한 컨테이너 관리를 위해선 과도하고, 성능과 보안에도 영향을 줄 수 있었습니다. CRI의 등장: Kubernetes는 다양한 컨테이너 런타임을 지원하기 위해 **Container Runtime Interface(CRI)**라는 표준을 제안했습니다. CRI는 컨테이너 런타임과 Kubernetes API 서버 간의 상호작용을 표준화하여, Kubernetes에서 다양한 런타임을 사용할 수 있도록 했습니다. OCI 표준과의 연계: 컨테이너 업계는 Open Container Initiative(OCI)를 통해 컨테이너 런타임과 이미지의 표준화를 추진하고 있었으며, CRI-O는 이 OCI 표준을 채택하여 OCI 호환 런타임(runc)과 컨테이너 이미지를 쉽게 사용할 수 있도록 설계되었습니다. CRI-O의 탄생: 이러한 필요성을 바탕으로 CRI-O 프로젝트가 시작되었으며, CNCF의 지원을 받아 빠르게 성장했습니다. CRI-O는 Docker 대신 Kubernetes에 최적화된, 가볍고 효율적인 컨테이너 런타임으로 자리 잡았습니다. Docker를 거치지 않고 Kubernetes와 직접 통신하면서 OCI 표준을 준수하는 컨테이너를 관리할 수 있는 기능을 제공하게 되었습니다. Kubernetes에서 Docker Shim의 제거: 2020년에는 Kubernetes가 Docker shim을 제거하기로 결정하면서, Docker 의존성을 줄이고자 하는 방향성이 더욱 뚜렷해졌습니다. 이로 인해 CRI-O와 같은 가벼운 CRI 준수 런타임이 더욱 주목받게 되었습니다. CRI-O는 Kubernetes에 특화된 환경에서 간소화된 컨테이너 런타임을 제공하기 위해 시작되었으며, Kubernetes와의 연동성과 보안성, 경량화를 목표로 발전했습니다.

Flannel

Overlay IP
pod 이 생성되면 overlay ip를 부여 > etcd에 저장
Flannel이 etcd에 저장하는 데이터는 subnet 정보와 lease 정보로 나뉘는데, lease 정보에 Pod의 IP 주소, MAC 주소, 노드 정보 등이 포함됨
key-value 형태로 데이터를 저장

클러스터 내부에서 Pod끼리의 통신

FQDN 라는 형식으로 domain name을 사용함

마지막 부분은 cluster domain인데 기본값이 cluster.local Service 도메인 :$serivce.$namespace.svc.cluster.local Pod 도메인: $pod-name.$namespace.svc.cluster.local

외부 >>> 내부 통신

Service, Ingress 등
kind:Service, type:LoadBalancer랑 kind: ingress 랑 어떻게 다른거지?
- ... 졸리다 -_-..

그러니까 노드 1에 pod 2개, 2에 4개, 3에 4개이면 로드 밸런서는 노드 밸런서는 노드1,2,3에 2:4:4 비율로 요청을 전달하고, 각 노드에서는 kube-proxy에 의해 pod으로 균등하게 나눠서 전달되는거지? > yes

clsuterIP 타입은 도저히 이해가 안감; > 이해됨 어라 생각했던거랑 약간 다르긴하네

Static Pod: Static Pod는 Kubernetes에서 관리되는 일반적인 Pod와는 다르게, Kubernetes API 서버에 의해 관리되지 않고 Kubelet에 의해 직접 관리되는 Pod입니다. Static Pod는 Kubernetes 클러스터의 노드에 직접적으로 설정되어 실행되며, Kubernetes API에 의해 생성되거나 조정되지 않습니다. 주로 클러스터의 중요한 컴포넌트 (예: kube-apiserver, kube-scheduler, kube-controller-manager 등) 를 실행할 때 사용됩니다.

Static Pod의 주요 특징은 다음과 같습니다:

Kubelet에 의해 관리: Static Pod는 각 노드의 Kubelet이 /etc/kubernetes/manifests 같은 특정 디렉토리에 있는 YAML 파일을 읽고 생성합니다.

Kubernetes API 서버와 무관하게 동작: API 서버가 다운되어도 Kubelet은 Static Pod를 계속 관리할 수 있습니다. 따라서 중요한 시스템 컴포넌트가 클러스터의 문제로 인해 중단되지 않도록 보장합니다.

API 서버에 의해 조회 가능: Static Pod는 직접 관리되지 않지만, Kubelet이 이 Pod 정보를 Kubernetes API 서버에 등록하여 kubectl get pods 명령으로 조회할 수는 있습니다.

자체적으로 유지 관리됨: Static Pod는 Kubelet이 실행되고 있는 한 계속 유지됩니다. 만약 Static Pod에 문제가 발생하면, Kubelet이 다시 시작하거나 재생성하여 항상 실행 상태를 유지합니다.

이를 통해 Static Pod는 클러스터 관리와 안정성에 중요한 역할을 하며, 특히 마스터 노드의 구성 요소로 자주 사용됩니다.

[x] ?? 외부에서 온 요청이랑 로드 밸런싱 아직 헷갈린다 이해된듯
- 로드 밸런서는 그냥 아무 노드에 접근 가능한 IP와 "NodePort"를 알고 있으면 된다
- 아무 노드로 요청을 보내고, NodePort가 열려있으니, 이 port로 요청이 들어가면
- kube-proxy가 이 nodePort로 들어온 요청을 어느 clusterIP로 보내야하는지 매핑 테이블을 확인 (ccm이 라우팅 테이블 관리함)
kube-proxy가 clusterIP로 요청을 프록시 해줄떄는 노드 안에 있는 팟에 한정해서 보내주는게 아니다

externalTrafficPolicy 가 local이면 그렇게 동작하나, cluster 이면 클러스터 전반에 걸쳐서 RR 등을 통해 결정한다 local로 처리하면 전체적으로 골고루 분산되지 않는다 ELB, ingress gateway도 유사하겠는데? (gateway는 클러스터 별 게이트웨이) 아니지, 어제 이해한게 맞는것 같다 kube-proxy로 들어오면, 모든 pod의 정보를 알아서, 이 pod에 균등하게 분배한다. 가 맞음 다만 여전히 A, B, C 노드에서 pod 5개 요청을 보내야하는데 A 5, B 3, C 2 번씩 요청이 들어왔고 pod1 ~ 5 순서대로 배분하면 pod1 ~ 5는 각각 3, 3, 2, 1, 1 번의 요청을 받는게 맞다 클러스터 차원에서의 균등 분산은 클라우드 로드 밸런서가 각 노드에 균등하게 트래픽을 분산해 주는지에 따라 달라질 수 있습니다.

[x] 그럼 분산해주거나 weight 주는건 어떻게 구현되는거지? 이해 완료

멀티 클러스터 환경에서만 가능하다 헬스 체크 자체는 각 pod 별로 probe 설정이 있으니, pod 에 대한 헬스 체크를 외적 요소가 할 필요는 없는거고, Node가 죽어도 보장해주니까 cm이 결국 네트워크 자체가 죽어서 컨트롤 플레인과 소통이 안되는 경우가 문제인데 우리는 이걸 IDC 단위로 클러스터를 잡고 있으니 IDC가 여러개로 이중화되면 멀티 클러스터 환경이 된다 멀티 클러스터 환경이라는건 로드 밸런서에 노드IP:NodePort 자체가 클러스터 별로 존재하는 것이니 외부 로드 밸런서에서 어떤 클러스터로 쏠지를 weight를 주어서 조절 할 수도 있고 여기서 health check 하면서 문제 생긴 클러스터에는 잠시 쏘지 않는다거나, 하는게 가능하다
ELB > ingress gateway로의 전달은 아마도 로컬리티 라우팅이 없지 않을까 싶은데
- 아 ELB에서 backend 정보까지 다 가져가고 있는건가?
- gateway로만 쏘는게 아니라 여기서 health 체크 해서 ingress gateway 의 backend 일부를 제외한다는건
- 그 클러스터로 안 쏜다는거잖아 ELB가 헬스 체크를 해서 어떤 클러슽터가 이상한지 알려면
- 각 clsuter:gateway:backend 로 직접 소통을 한다는건데
- ELB는 gateway.backend 단위로 요청을 처리하는 것 같다 (뭐지 왜지 cluster의 노드 포트 를 사용하는 방식이 아닌 것 같은데)
  
  아무래도 포트가 제한적이라 그럴 수도 있을 것 같다
istio는 ingress 기반이라, 이 상황에서의 로드밸런ㄷ스 - 서비스 요거는 구조를 따로 학습해야겠다

ingress ?
등장, 배경, 시기
- 초기에 등장하였으나, LoadBalancer, NodePort 만으로는 한계가 있었음
- 이전에는 특정 노드가 수신하고, kube-proxy가 다시 전달해주었음 각 서비스가 외부에 노출되고 설정이 복잡해지고 관리 부담이 커짐
- ingress controller가 있으면 모든 요청을 여기서 받고, 내부적으로 라우팅해줌 내부에서 관리할 수 있음 (중앙화된 트래픽 관리) 서비스별로 세부적인 라우팅 관리도 가능 (유연한 라우팅 규칙 & 보안 강화)
NGINX ingress Controller 설치
- Deployment 형태로 ingress-nginx Pod 추가
  
  replica N nginx 컨테이너
- Service 등록 (ClusterIP 타입)
  
  외부에서 접근 가능하게 하려면 (LoadBalancer or NodePort 타입)
- "Ingress" 타입 리소스 정의 apply
- "rule 규칙 - backend 매핑"
  
  backend 매핑 ex_ service.name = web-app (port 80)
- 요청 흐름
  
  LB 타입인 경우 LB > 임의의 노드의 NodePort 로 유입 (보통 NodePort(30080, 30443 등)를 사용) 80, 443으로 들어온건 모두 ingress controler pod으로 전달 ingress controller에 라우팅 규칙에 맞는 서비스로 전달
Envoy ingress Controller 설치
- HTTPProxy 리소스 와 연동

istio
일반적으로 ingress controller 쓰지 X
- istio ingress Gateway를 대신 사용
설치
- Istioctl 설치
- kubectl 사용 가능한 아무 노드에서나 실행
- Istio의 Control Plane 구성 요소를 클러스터에 설치
  
  istiod, Ingress Gateway, Egress Gateway (optional)
- istio-system 네임스페이스에 ingress gateway Pod이 뜬다 (보통 Deployment)
- Service도 추가됨 (LoadBalancer나 NodePort 타입)
- ingress controller랑 동일하게 istio ingress gateway 까지 들어오는 것으로 이해함
  
  여러개의 ingress gateway를 구성하기도 한다
- 근데 왜 ingress controller 구현체가 아니라 아예 새롭게 만든거지? (뭔가 한계가 있기 때문이겠지? 어쨌든 정해진 인터페이스 내에서 만들어야 하니까)
- istio-injection 레이블을 전체에 적용
  
  kubectl label namespace <네임스페이스명> istio-injection=enabled envoy 사이드카 추가
- Gateway, VirtualService 등 리소스 apply
- ingress Gateway는 외부 노출 IP로도 접근이 가능하다?
외부 LB
- 클러스터들의 gateway IP:NodePort 매핑 정보가 있음
  
  도메인:80 or 443 - Gateway (IP:NodePort) 분명 path 기반은 아닌것 같은데 ELB 설정에 path가 있는 걸 보면, 왜이지..?
- 아마도, ELB의 path 설정은 자체적인 라우팅 설정이다 (어쨌거나 path 별로 뭔가 다르게 적용 가능하니)
  health check 등
  - "결국 전달하는건 모두 같은 게이트웨이들" (이게 맞는지 확인하는게 중요함)
Gateway
"서비스"별로 생기는지 "클러스터"마다 생기는지 모르겠 > 클러스터마다. 가 맞는 것 같음 일단
- "클러스터 마다 생기는 것으로 일단 이해"
- 그러니까 실제로 Service 1,2,3,4 로의 모든 요청이 일단 하나의 게이트웨이로 들어온다
- 문제는 그 클러스터에 해당 서비스가 없을 수도 있다 일단 클러스터에 서비스가 하나라도 있으면 클러스터 게이트웨이가 생기니, 공용으로 써야 해서 모든 요청을 모두 나눠 받기는 한다 그래서 만약 앱이 없으면 옆 클러스터로 다시 보내줘야 한다 (여기서 외부 요소를 리소스로 등록해서 연결 가능하다. 로 이해) "정확하게 어떻게 흘러가는지는 좀 더 봐야함"
- ::gateway 설정으로 가서 backend에 클러스터를 추가하면
- 해당 클러스터에 Gateway가 없으면 일단 Gateway 추가
- 해당 gateway에 연결되는 VirtualService 등록 (아마 Resource 까지 등록해야 온전하게 등록될 것)
- health check
- 아.. LB에서 게이트웨이로 보낼때 후보가 여러 클러스터니까, 특정 클러스터 응답이 이상하면 특정 클러스터 게이트웨이를 제외하고 전송
- path 별로 나뉘어져 있기 때문에, 각 path 별로 헬스 체크에 의한 제외 정책이 적용됨
- ELB가 하는게 맞음

근데 왜 게이트웨이의 주소가 있지? 그건 좀 다른 게이트웨이인듯 (ELB의 분산된 게이트웨이) ELB 내에서도 N개의 게이트웨이로 나눠서 라우팅을 수행하는 것으로 이해 (확장 가능한 구조)

클러스터들이 서로 직접 네트워크 레벨에서 연결되지 않은 경우, Istio는 East-West Gateway를 사용하여 트래픽을 다른 클러스터로 라우팅합니다.

근데 East-West Gateway 방식은 아닐것 같은데. (맞나?) 아닐듯

ServiceEntry, ServiceExport, ServiceImport ...

멀티 네트워크 연결을 통한 서비스 디스커버리 (Primary-Primary 또는 Primary-Remote 방식):

각 클러스터에 네트워크 레벨에서 연결을 설정하여, Istio가 서로 다른 클러스터에 있는 서비스도 자동으로 디스커버리하고 트래픽을 라우팅할 수 있도록 구성합니다. 이 설정에서는 Istio가 여러 클러스터에 존재하는 동일한 이름의 서비스를 디스커버리하여, 한 클러스터에 서비스가 없을 때 다른 클러스터로 트래픽을 라우팅할 수 있습니다. 이를 위해서는 모든 클러스터에 East-West Gateway를 구성하여, 클러스터 간 트래픽이 내부적으로 전달될 수 있도록 해야 합니다. East-West Gateway를 통한 트래픽 라우팅:

클러스터 간 네트워크가 분리된 환경이라면, 각 클러스터에 East-West Gateway를 배포하여 다른 클러스터의 서비스를 프록시하는 방식으로 접근할 수 있습니다. 예를 들어, 한 클러스터에 해당 서비스가 없으면 East-West Gateway를 통해 다른 클러스터로 트래픽을 전달할 수 있습니다. 이때는 VirtualService와 DestinationRule을 사용하여, 특정 서비스가 없는 경우 다른 클러스터의 East-West Gateway로 트래픽을 라우팅하도록 설정할 수 있습니다.

VirtualService를 통해

muf / orion-doc-page

Learn k8s (입문) #1