💻
DevOps Cookbook
  • Home
    • Meiko DevOps Cookbook
  • Gitlab
    • Tips
      • 사전 정의된 CI/CD 변수의 기본 세트
    • 딥다이브 Gitlab CI/CD
      • GitLab CI/CD 시작하기
        • .gitlab-ci.yml 파일
        • Runner
        • 파이프라인
        • CI/CD 변수
        • CI/CD 컴포넌트
      • CI/CD YAML 구문 참조
    • CI/CD Notifications
      • CI/CD slack notifiaction 구축작업 결과
  • Kubernetes
    • Persistence Volume
      • play-cluster
    • Ingress
      • Ingress란
      • 수동으로 ingress 배포하기
    • Security
    • HPA
      • hpa troubleshooting history
        • 1. HELM_UPGRADE_VALUES_FILE로 hpa가 추가되지 않는 원인
        • 2. targetCPUUtilizationPercentage 계산은 어떻게 되는가
        • 3. helm values에 cpu resource 단위를 1로 했을 때 실제 파드에 1m( 0.001 ) 코어가 부여된 것
        • 4. pod cpu resources가 할당받은 것을 나타내는 것인 지 현재 사용량을 나타내는 것인지 검증
        • 5. 설정한 hpa를 기반으로 pod auto scaling이 동작하는 지 검증
      • HorizontalPodAutoscaler의 behavior 필드 중 stabilizationWindowSeconds 값이 Kubernetes 코드에서 어떻게 사용되는지 분석
  • prometheus
    • prometheus 리소스 alert 세팅
      • 슬랙 채널 구성
      • alert 환경 구성 가이드
  • Loki
    • loki-grafana alert 세팅
      • 1차 검증 결과
      • Alert 환경 구성 가이드
  • load test
    • nGrinder
      • nGrinder Test Configuration 값들
      • 질문리스트
        • groovy는 JUnit 스타일에 포함되지 않는건가 ? + GTest가 뭔지 좀 헷갈린다
      • Script
        • Groovy Script Structure
          • reference
          • Groovy script deep dive
          • Groovy Script 실행 구조 분석
      • Test
        • [nGrinder] single endpoint load test 하기
          • [nGrinder] single endpoint load test script 기반 cpu 사용량 테스트
          • [nGrinder] single endpoint load test script 기반 pod autoscaling 테스트
        • [nGrinder] multi endpoint load test 하기
          • [nGrinder] multi endpoint load test script에 정의한 test들이 실행 순서를 보장 받는가?
  • AWS
    • aws-cli
      • eks cluster vpc 스펙보기
    • aws-vpc
  • EKS
    • youtube links
    • EKS best practice
    • 질문 정리
  • Istio
    • Istio Basic
      • Istio 컴포넌트 별 역할
      • Kubernetes Ingress와 Istio VirtualService의 관계
    • Gateway
      • Gateway 주요 특징
      • Istio Gateway와 Kubernetes Ingress의 주요 차이점
  • IAC
    • Terraform
      • 테라폼 설치
      • 테라폼 문서
      • 테라폼 개념
        • 언어 구조
        • 사용 순서
        • 상태파일 (tfstate)
        • 변수 정의 방법
      • Terraform - AWS VPC
    • Ansible
      • Ansible 초기 학습 내용
      • Ansible Playbook
      • Ansible Study
        • Inventory
        • Playbook
          • Module
        • Variable
  • etc
    • Toss SLASH24
    • Elastic Load Balancing
    • 낙서장
      • IRSA
    • deep dive
      • Istio 공식문서 번역
        • Overview
          • What is Istio?
          • Why choose Istio?
          • Sidecar or ambient?
        • Concepts
          • Traffic Management
        • Page
      • eks 에서 control plane < - > data plane 통신 원리
Powered by GitBook
On this page
Edit on GitHub
  1. EKS

질문 정리

질문에 대한 답변

  1. NAT 게이트웨이는 무조건 퍼블릭 서브넷에 위치시키는거지?

    • 맞습니다. NAT 게이트웨이는 퍼블릭 서브넷에 위치해야 합니다. NAT 게이트웨이는 프라이빗 서브넷의 인스턴스들이 인터넷에 접근할 수 있도록 하는 역할을 합니다. 퍼블릭 서브넷에 위치함으로써 인터넷 게이트웨이와 연결되어 외부 네트워크와의 통신이 가능해집니다.

  2. 각 서브넷에 할당된 CIDR 블록 만큼 IP를 할당할 수 있는거지?

    • 맞습니다. 각 서브넷은 할당된 CIDR 블록 내에서 IP 주소를 할당받습니다. 예를 들어, /24 블록은 256개의 IP 주소를 제공하며, 이 중 일부는 AWS 리소스(예: 워커 노드, NAT 게이트웨이, 로드 밸런서 등)와 연결됩니다.

  3. Kubernetes에서 할당하는 IP는 상관 없고 AWS 리소스를 할당하는 IP만 사용되는거지?

    • 부분적으로 맞습니다. Kubernetes에서는 각 파드(Pod)에 VPC의 서브넷에서 IP를 할당합니다. 그러나 이는 AWS 리소스와 마찬가지로 VPC의 IP 주소 공간을 소모합니다. 즉, Kubernetes 파드와 AWS 리소스 모두 VPC의 IP 주소를 공유하게 됩니다.

  4. EKS 서브넷 IP 범위를 지정할 때 워커 노드가 확장되거나 NAT 게이트웨이가 확장되는 한계를 고려해야 하는거지?

    • 맞습니다. 서브넷의 IP 주소 공간이 한정되어 있기 때문에, 워커 노드와 NAT 게이트웨이의 확장을 고려하여 충분한 IP 주소를 할당해야 합니다. 서브넷 내 IP 주소가 부족할 경우 새로운 노드나 파드를 추가할 수 없게 됩니다.

PreviousEKS best practiceNextIstio Basic

Last updated 1 year ago