티스토리

검색하기내 프로필

블로그 홈

개발 노트

구독자
27

구독하기 방명록
신고

인기글

  • [오류 해결] 종속되어 있는 파일이나 어셈블리 중 하나를 로드할 수 없습니다공감수27댓글수9조회 89
  • [Docker] 컨테이너에서 sudo 사용하기공감수7댓글수2조회 16
  • Go언어로 웹 서버 개발 시 Swagger 문서 자동 생성하기공감수1댓글수0조회 8

주요 글 목록

  • [Cilium study] 5주차 - BGP Control Plane글 내용

    실습 환경 구성curl -O https://raw.githubusercontent.com/gasida/vagrant-lab/refs/heads/main/cilium-study/5w/Vagrantfilevagrant up기본 배포 가상 머신 : k8s-ctr, k8s-w1, k8s-w0, router (frr 라우팅)router : 192.168.10.0/24 ↔ 192.168.20.0/24 대역 라우팅 역할, k8s 에 join 되지 않은 서버, BGP 동작을 위한 frr 툴 설치됨 - FRRk8s-w0 : k8s-ctr/w1 노드와 다른 네트워크 대역에 배치실습 동작에 필요한 static routing 설정 됨 with vagrant script fileFRR은 서버에서 돌아가는 라우팅 도구(데몬)라고..

    좋아요0
    댓글0작성시간2025. 8. 15.
    게시글 이미지
  • [Cilium study] 4주차 - Networking - 노드에 파드들간 통신 및 외부 노출글 내용

    실습 환경 구성curl -O https://raw.githubusercontent.com/gasida/vagrant-lab/refs/heads/main/cilium-study/4w/Vagrantfilevagrant up기본 배포 가상 머신 : k8s-ctr, k8s-w1, k8s-w0, routerrouter : 192.168.10.0/24 ↔ 192.168.20.0/24 대역 라우팅 역할, k8s 에 join 되지 않은 서버, loop1/loop2 dump 인터페이스 배치k8s-w0 : k8s-ctr/w1 노드와 다른 네트워크 대역에 배치라우팅 테이블 살펴보기아래와 같이 Router에서 라우팅 테이블을 확인해보면 각 네트워크에 접근할 수 있는 네트워크 인터페이스가 구성되어 있습니다. 아래와 같이 각 쿠..

    좋아요0
    댓글2작성시간2025. 8. 9.
    게시글 이미지
  • [Cilium study] 3주차 - Cilium Neworking글 내용

    실습 환경 구성mkdir cilium-lab && cd cilium-labcurl -O https://raw.githubusercontent.com/gasida/vagrant-lab/refs/heads/main/cilium-study/3w/Vagrantfilevagrant up기본 배포 가상 머신 : k8s-ctr, k8s-w1, routerrouter : 사내망 10.10.0.0/16 대역 통신과 연결, k8s 에 join 되지 않은 서버, loop1/loop2 dump 인터페이스 배치Cilium CNI 설치 상태로 배포 완료됨IP Address Management (IPAM)IPAM은 네트워크상의 IP 주소를 체계적으로 계획, 추적, 관리하는 방법론과 도구를 말합니다. 단순히 IP 주소를 할당하는 것..

    좋아요3
    댓글3작성시간2025. 8. 2.
    게시글 이미지
  • [Cilium study] 2주차 - Observability글 내용

    들어가기 전 실습 환경 구성기본 배포 가상 머신 : k8s-ctr, k8s-w1, k8s-w2초기 프로비저닝으로 kubeadm init 과 join 실행됨Cilium CNI 설치 상태로 배포 완료됨Cilium을 설치 할 때 endpointHealthChecking.enabled 옵션을 통해 헬스체크 활성 여부를 선택할 수 있는데, 3~10대의 노드로 유지할 때는 헬스체크를 켜놓는 것이 유리하지만 11대 이상으로 노드 수가 많아질 경우에는 헬스 체크를 비활성화 하는 것을 권장합니다. 이는 아래 Cilium의 Scalability Report 문서에 명시되어 있으며, 노드 수가 10대를 넘어가는 경우 별도의 전문 모니터링 도구를 활용하는 것을 권장합니다. --set endpointHealthChecking...

    좋아요0
    댓글3작성시간2025. 7. 26.
    게시글 이미지
  • [Cilium study] 1주차 - Cilium 구축 환경 이해하기글 내용

    로컬 환경 설정Vagrant와 VirtualBox를 기반으로 실습 환경을 설정합니다. 구성된 쿠버네티스 클러스터는 아래와 같습니다. Vagrantfile을 기반으로 vagrant up 명령을 실행하여 아래와 같이 쿠버네티스 컨트롤 플레인 1대와 워커노드 2대로 구성된 클러스터를 생성합니다. 각 서버들은 독립적으로 실행된 가상머신들이기 때문에 아래와 같이 동일 IP를 가지고 있더라도 문제는 없습니다. 쿠버네티스 클러스터에서 Pod간 통신에 활용되는 IP는 아니고 vagrant ssh와 같이 호스트와 가상 서버간 통신을 위한 IP입니다. 위 네트워크 구성은 아래와 같습니다. 쿠버네티스 네트워킹쿠버네티스의 네트워킹은 CNI를 통해 이루어지며 이 CNI는 아래 4가지 문제를 해결해야 합니다. 1. 파드 내..

    좋아요2
    댓글0작성시간2025. 7. 18.
    게시글 이미지
  • [Istio 스터디] 9주차 - Ambient Mesh글 내용

    Ambient Mesh 개요Istio의 Ambient Mesh는 2022년 알파 버전으로 시작되어 2024년 GA(General Availability) 버전에 도달한 혁신적인 데이터 플레인 아키텍처입니다. Ambient Mesh는 한국어로 '주변 모드'로 번역되며, 기존 사이드카 프록시 없이 동작하는 Istio 데이터 플레인 모드를 의미합니다.사이드카 모드의 한계점:애플리케이션 간섭: 사이드카 설치나 업그레이드 시 애플리케이션 파드 재시작 필요리소스 활용도 저하: 각 파드마다 사이드카 컨테이너의 CPU/메모리 리소스 소비트래픽 차단: HTTP 구현에 맞지 않는 애플리케이션 중단 가능성컴퓨팅 비용 증가: 사이드카당 개별 리소스 할당으로 인한 비효율Ambient Mesh는 기존 사이드카 모델의 한계를 극복..

    좋아요3
    댓글3작성시간2025. 6. 8.
    게시글 이미지
  • [Istio 스터디] 8주차 - VM Support & Istio Traffic Flow글 내용

    레거시 워크로드의 정의와 통합 필요성레거시 워크로드는 Kubernetes의 파드가 아닌, VM(가상 머신) 또는 베어메탈 서버에 올라가 있는 애플리케이션을 의미레거시 워크로드를 Istio 서비스 메시에 통합 시 이점:트래픽 라우팅 관리인증 관련 기능(mTLS 통신)세밀한 권한 정책(Authorization policies)텔레메트리(Telemetry) 기능많은 기업 환경에서는 모든 워크로드를 Kubernetes로 마이그레이션하기 어려운 상황이 존재함:유지 관리하는 업체가 없어 히스토리가 불분명할 수 있음컨테이너화하려면 새로운 설계가 필요함다양한 추가 고려사항이 필요함Istio VM 지원의 주요 기법Istio의 VM 지원 기능을 통해 Kubernetes Pod와 VM 워크로드를 단일 서비스 메시로 통합할 ..

    좋아요2
    댓글0작성시간2025. 5. 31.
    게시글 이미지
  • [istio 스터디] 7주차 - 이스티오 스케일링, 데이터 플레인 확장글 내용

    이스티오 서비스 메시 스케일링 개요여러 클러스터를 사용해야 하는 다양한 이유:보안상 격리 필요: 클러스터 간 격리를 통해 보안 강화장애 영향도 최소화: 한 클러스터 문제가 다른 클러스터에 영향을 주지 않도록 함데이터 접근 제한: 민감한 데이터에 접근하는 서비스 분리가용성 향상: 여러 클러스터를 통한 고가용성 구현따라서 여러 개의 작은 클러스터를 사용하는 방식이 많은 환경에서 선호됩니다.다중 클러스터 서비스 메시의 유형다중 클러스터 서비스 메시는 크게 두 가지 모델로 구분됩니다.다중 클러스터 서비스 메시(Multi-cluster Service Mesh) : 다중 클러스터 서비스 메시에서는 컨트롤 플레인이 여러 Kubernetes 클러스터를 관리하고, 이 모델에서 하나의 컨트롤 플레인이 여러 클러스터의 서비..

    좋아요3
    댓글0작성시간2025. 5. 25.
    게시글 이미지
  • [istio 스터디] 6주차 - 운영 및 트러블슈팅글 내용

    이번 주차 스터디에서 다룰 내용 :데이터 플레인 관련 문제 확인 및 처리 방법워크로드 설정 오류 시 원인 파악 과정과 절차로그, 텔레메트리(Telemetry) 등의 확인 기법Istiod 컨트롤 플레인 파드 최적화성능 최적화를 위한 방법들실습 시 주의 사항 :11장에서는 컨트롤 플레인 튜닝 실습을 위해 약 200개 이상의 더미 서비스를 생성해야 하는데, 초기에 서비스 IP를 24비트로 설정하면 IP가 고갈되는 문제 있을 수 있음이를 해결하기 위해 CIDR를 22비트로 변경하여 약 1,000개 정도의 IP를 사용할 수 있도록 수정 필요데이터 플레인 트러블슈팅Istio API를 통해 설정을 하게 되면(예: VirtualService나 DestinationRule 선언), Istiod가 이를 Envoy 설정으로..

    좋아요0
    댓글0작성시간2025. 5. 17.
    게시글 이미지
  • [istio 스터디] 5주차 - 마이크로서비스 통신 보안글 내용

    애플리케이션 네트워크 보안의 필요성네트워크 보안에서는 인증, 인가, 전송 데이터 암호화와 같은 요소들이 중요함인증은 사용자나 서비스의 신원을 확인하는 과정인가는 인증된 사용자나 서비스가 특정 리소스나 작업에 접근할 수 있는 권한이 있는지 확인하는 절차 Istio에서는 서비스 간 인증과 최종 사용자 인증이라는 두 가지 유형의 인증이 존재함서비스 간 인증은 인프라 레벨에서 이루어지는 반면, 최종 사용자 인증은 사용자의 ID와 비밀번호 등을 통해 이루어짐테스트를 위해 Istio install 시 profile을 demo로 지정기본적으로 디버깅 레벨이 높고 샘플링이 100%로 설정되어 데모 테스트에 적합Istio 프록시 컨테이너에서 TCP 덤프를 직접 가능하게 하기 위해 privileges 권한을 부여하는 옵션..

    좋아요0
    댓글0작성시간2025. 5. 11.
    게시글 이미지
  • [istio study] 4주차 - Observability글 내용

    관찰 가능성(Observability)의 개념관찰 가능성이란 외부의 신호와 특성(시그널링)을 통해 내부 애플리케이션의 상태를 이해하고 추론할 수 있게 하는 시스템 특성시스템의 외부에서 내부 상태를 파악할 수 있는 능력을 의미Istio의 관찰 가능성 기능은 마이크로서비스 아키텍처의 복잡성을 관리하는 데 큰 도움을 주며, 데이터 플레인과 컨트롤 플레인에서 제공하는 다양한 메트릭을 통해 시스템 상태를 효과적으로 모니터링하고, 장애 발생 시 신속하게 대응할 수 있음. 특히 Istio는 서비스 간 통신을 중간에서 처리하기 때문에, 애플리케이션 수준의 메트릭을 효과적으로 수집할 수 있는 이상적인 위치에 있어 관찰 가능성 구현에 매우 적합함모니터링과의 차이모니터링: 시스템의 특정 상태와 메트릭을 추적하고 알림을 제공..

    좋아요0
    댓글0작성시간2025. 5. 3.
    게시글 이미지
  • [Istio 스터디] 3주차 - Traffic control, Resilience글 내용

    (참고) 배포와 릴리즈의 차이배포(Deployment): 새 버전의 애플리케이션을 인프라에 올리는 것릴리즈(Release): 실제 프로덕션 환경의 트래픽을 새 버전으로 전달하는 것배포 전략블루-그린 배포: 새 버전을 완전히 배포한 후 한 번에 전환카나리 배포: 일부 트래픽만 새 버전으로 점진적 전환다크 런치: 특정 사용자(예: 내부 QA 팀)만 새 버전에 접근 가능하게 함Istio API 리소스 핵심 개념VirtualService트래픽 라우팅 방법을 지정하는 리소스약어: vs트래픽 분배, 경로 지정, 헤더 기반 라우팅 등 설정DestinationRule트래픽 대상과 서브셋을 정의하는 리소스약어: dr서비스 내의 다양한 버전을 서브셋으로 정의카탈로그 서비스의 버전 관리 및 다크 런치초기 환경 구성1. 카탈..

    좋아요0
    댓글0작성시간2025. 4. 26.
  • [Istio 스터디] 2주차 - Envoy, Istio Gateway글 내용

    Envoy의 중요성Envoy는 Istio 서비스 메시(Service Mesh)의 데이터 플레인으로서 핵심적인 역할을 담당Kubernetes가 컨테이너 오케스트레이션 플랫폼이듯이, Istio 서비스 메시를 제대로 이해하고 운영하기 위해서는 Envoy에 대한 깊은 이해가 필수적Istio가 제공하는 다양한 기능(트래픽 라우팅, TLS 터미네이션 등)은 모두 Envoy의 기능을 기반으로 함Istio 컨트롤 플레인은 단지 Envoy의 설정을 관리하는 역할만 수행하며, 실제 모든 프록시 기능은 Envoy가 담당Envoy 프록시 소개와 핵심 원칙Envoy 프록시 배경2016년 9월에 오픈 소스로 공개CNCF(Cloud Native Computing Foundation)에 빠르게 합류C++로 작성되어 높은 성능 제공높..

    좋아요1
    댓글0작성시간2025. 4. 19.
    게시글 이미지
  • [Istio 스터디] 1주차 - Istio 소개, 첫걸음글 내용

    서비스 메시 소개클라우드가 확산되면서 애플리케이션 설계에 있어서도 고려할 사항들이 변화하고 있음컨테이너화 된 애플리케이션들은 언제든 삭제되고 재생성될 수 있음네트워크는 신뢰할 수 없으므로 더 크고 더 분산된 시스템을 구축할 때는 네트워크에 대해 재시도, 타임아웃, 서킷 브레이커와 같은 네트워크 복원력이나 관찰가능성, 애플리케이션 계층은 보안 등을 신경써야함네트워킹, 보안, 메트릭 수집은 애플리케이션 구현에 있어서 필수이지만 차별화 요소는 아님중요한 자원인 개발자들이 네트워크 단의 설계와 구현에 많은 시간을 투자하는 것보다는 더 가치있는 본연의 업무를 수행할 수 있도록 해야함서비스 메시는 이런 공통 관심사를 애플리케이션 대신 프로세스 외부에서 투명한 방식으로 구현하기 위함네트워킹, 보안, 메트릭 수집과 같..

    좋아요0
    댓글0작성시간2025. 4. 12.
    게시글 이미지
  • [KANS] 8주차 - Cilium CNI글 내용

    eBPF를 왜 사용할까?iptables의 단점을 보완하기 위함같은 NetworkPolicy를 할당받는 Pod가 무수히 많다면 Pod 수 만큼 iptables rule에 해당 NetworkPolicy가 반영되기 때문에 개수가 많아지고, 결과적으로 성능 저하로 이어짐contrack 테이블의 지속적으로 유지 관리해야함iptables의 규칙에 일치할 때까지 모든 규칙을 평가하기 때문에 비효율적임iptables는 iptables는 규칙을 변경할 때 개별 규칙만을 수정하는 것이 아니라, 전체 규칙 세트를 한 번에 교체하기 때문에 incremental update가 불가능함결과적으로 iptables를 사용하면 클러스터 규모가 커지면 커질 수록 성능 저하가 발생함eBPF는 iptables에서 kernel space와 ..

    좋아요1
    댓글0작성시간2024. 10. 26.
    게시글 이미지
  • [KANS] 6주차 - Ingress, Gateway API글 내용

    Ingress 개요Ingress를 이해하기 위해서는 Service의 각 유형들에 대한 이해도가 있어야 함Ingress는 클러스터 외부에서 클러스터 내부 서비스로 트래픽을 전달할 수 있도록 제공하고, Service와 달리 HTTP 및 HTTPS를 사용할 수 있도록 하는 Kubernetes의 오브젝트 Ingress는 다양한 환경과 요구사항에 맞춰 구현될 수 있어야 하고, SSL 인증서 관리, 고급 로드 밸런싱 알고리즘, 웹 애플리케이션 방화벽 등의 기능을 제공할 수 있어야 하기 때문에 Service 처럼 Built-in으로 제공되지 않고 별도로 설치해야함Ingress의 실제 동작 구현은 인그레스 컨트롤러가 처리함 (대표적으로 Nginx, Kong, AWS Loadbalancer Controller 등이 있음..

    좋아요1
    댓글0작성시간2024. 10. 13.
    게시글 이미지
  • [KANS] 5주차 - LoadBalancer(MetalLB, IPVS)글 내용

    로드밸런서 타입 개요쿠버네티스 클러스터 내 Pod로 외부에서 접속하기 위해서는 요청을 수신하기 위한 expose 설정을 해야하는데 방법 중 하나가 LoadBalancer 타입을 지정하는 것기본적으로 쿠버네티스는 로드밸런서 컴포턴트를 직접적으로 제공하지 않음public cloud를 사용하는 경우에는 CSP에서 제공하는 자체 로드밸런서를 사용온프레미스에서는 주로 MetalLB를 사용함 (MetalLB는 소프트웨어로 동작함)일반적으로 다수의 워커 노드로 트래픽을 분산하기 위해서 앞단에 로드밸런서를 두고, 로드밸런서가 수신한 요청을 대상 노드에 전달하면 수신받은 노드는 기존의 ClusterIP 타입의 동작과 동일하게 iptables rule을 통해 대상 Pod로 트래픽을 전달함이 때는 노드의 포트로 수신한 트래..

    좋아요1
    댓글0작성시간2024. 10. 6.
    게시글 이미지
  • [KANS] 4주차 - Service (ClusterIP, NodePort)글 내용

    개요Service는 쿠버네티스에서 동작하는 애플리케이션을 내/외부에서 유연하게 접속하기 위한 역할을 하며 ClusterIP, NodePort, LoadBalancer Type을 지원Service 동작에 중요한 부분을 차지하는 것이 kube-proxy 인데 kube-proxy의 ConfigMap을 보면 기본으로 iptables를 사용하는 것으로 설정되어 있음참고로 Amazon EKS는 kube-proxy의 ConfigMap이 간소화되어 설정되어 있고, 기본값이 iptables이기 때문에 굳이 명시되어 있지 않음Pod는 재생성 되면 매번 IP가 변경되기 때문에 클라이언트 입장에서는 매번 IP가 바뀌면 문제가 되기 때문에 Service 개념이 필요함고정 Virtual IP를 할당하고 Domain 주소를 생성해..

    좋아요1
    댓글1작성시간2024. 9. 28.
    게시글 이미지
  • [KANS] 3주차 - Calico CNI & Mode 정리글 내용

    Calico OverviewCalico 관련된 설정을 하게되면 calico datastore에 모든 정보가 저장됨. 이 정보를 기반으로 calico-node Pod가 동작함calicoctl로 Calico 관련 설정들에 대한 CRUD를 할 수 있음calico-node Pod는 데몬셋으로 동작함데몬셋 Pod는 호스트의 네트워크 인터페이스를 공유해서 사용calico-node는 bird, felix, confd로 구성됨노드가 신규로 생성되면 각 노드의 bird 간에 마치 명함을 교환하는 것처럼 BGP 라우팅 프로토콜을 통해 상호 정보를 교환함 (정보를 동적으로 광고)Felix는 Bird를 통해 BGP로 받은 정보를 호스트의 라우팅 테이블에 반영하는 역할과 iptables의 규칙을 수정하는 역할을 함iptable..

    좋아요0
    댓글0작성시간2024. 9. 21.
    게시글 이미지
  • [KANS] 2주차 - K8S Flannel CNI & Pause 정리글 내용

    Kind그림 출처: https://kind.sigs.k8s.io/ kubernetes in docker의 약자로컬환경에서 테스트용도로 사용하며 docker 기반으로 Kubernetes를 설치함docker 컨테이너 안에서 docker를 사용해서 Kubernetes 실행에 필요한 각 컴포넌트들을 컨테이너로 실행멀티 클러스터에 대한 테스트를 해보기 좋음아래 명령으로 설치 및 실행# Install Kindbrew install kindkind --version# Install kubectlbrew install kubernetes-clikubectl version --client=true# Install Helmbrew install helmhelm version# Install Wireshark : 캡처된 패..

    좋아요0
    댓글0작성시간2024. 9. 7.
    게시글 이미지
문의안내
  • 티스토리
  • 로그인
  • 고객센터
© Kakao Corp.