바코더의 블로그

1. JenkinsJenkins Deploy 순서최신 코드 가져오기 : 개발을 위해 중앙 코드 리포지터리에서 로컬 시스템으로 애플리케이션의 최신 코드를 가져옴단위 테스트 구현과 실행 : 코드 작성 전 단위 테스트 케이스를 먼저 작성코드 개발 : 실패한 테스트 케이스를 성공으로 바꾸면서 코드 개발단위 테스트 케이스 재실행 : 단위 테스트 케이스 실행 시 통과(성공!)코드 푸시와 병합 : 개발 소스 코드를 중앙 리포지터리로 푸시하고, 코드 병합코드 병합 후 컴파일 : 변경 함수 코드가 병함되면 전체 애플리케이션이 컴파일된다병합된 코드에서 테스트 실행 : 개별 테스트뿐만 아니라 전체 통합 테스트를 실행하여 문제 없는지 확인아티팩트 배포 : 애플리케이션을 빌드하고, 애플리케이션 서버의 프로덕션 환경에 배포배포 ..

HelmHelm 소개Helm은 템플릿 기반 쿠버네티스 패키지 관리자로, 버전 관리와 공유, 배포 가능한 아티팩트를 생성함YAML 파일에 Go 템플릿을 적용해 쿠버네티스 애플리케이션을 설치·관리하는 도구핵심 포인트Helm은 Kustomize와 유사하지만 템플릿 기반으로 더 유연함**차트(chart)**는 재사용·공유 가능한 쿠버네티스 패키지 단위ConfigMap 변경 시 자동으로 애플리케이션 재배포를 지원해 관리 효율성 향상 Helm 프로젝트 만들기helm은 관련 매니페스트 파일을 번들로 묶어 하나의 논리적 배포 단위인 차트로 패키징차트 만들기Chart.yaml 파일 작성cat Chart.yamlapiVersion: v2name: pacmandescription: A Helm chart for Pacma..

GitOps란 ? 1. GitOps 정의Git을 단일 진실 소스로 사용모든 것을 코드로 관리모든 작업은 Git 워크플로(PR, Merge 등)로 수행2. GitOps 원칙 (OpenGitOps 기준)선언형(Declarative)버전 관리 + 불변성자동 반영(Pull 기반)지속적 조정(상태 동기화)3. GitOps 도입 효과익숙한 Git 기반 워크플로변경 이력 검토 + 보안 강화모든 변경 내역 감사 가능다중 클러스터 운영 일관성 확보4. Kubernetes에서의 CI/CD 흐름CI: 코드 → 컨테이너 이미지 생성 → 레지스트리 저장CD: 매니페스트 변경(PR) → GitOps 엔진이 동기화5. GitOps 동작 루프배포모니터링차이 감지반영(동기화 / 롤백)6. GitOps 구성요소애플리케이션 소스 저장소C..

Cilium Security보안 계층L3 (Identity 기반): Pod/엔드포인트의 Security Identity를 기반으로 통신 제어L4 (Port 레벨): 특정 포트 단위 접근 제어L7 (애플리케이션 프로토콜): Envoy Proxy 활용, HTTP/gRPC/Kafka 등 프로토콜 인식 기반 정책보안 정책 특징상태 저장 정책 (stateful)세션 기반 프로토콜에 대해 요청 패킷 허용 시, 응답 패킷은 자동 허용적용 방향: Ingress(수신) / Egress(송신) 구분 적용기본 정책 동작정책 없음 → 기본적으로 모든 통신 허용첫 정책이 로드되면 → 허용 기반(whitelist) 모드로 전환, 명시되지 않은 트래픽은 차단L4 정책 없음 → 모든 포트 허용L4 정책 존재 → 지정되지 않은 포트는..

Kube-burner대규모 Kubernetes 리소스 작업Create, delete, read, patch 지원대규모 배포/삭제 시뮬레이션Prometheus 메트릭 통합테스트 중 Prometheus에서 메트릭 수집 및 인덱싱성능 지표 자동 기록Measurements다양한 성능 측정 (API latency, scheduling delay 등)커스텀 메트릭 정의 가능Alerting사전 정의된 SLA/SLI 위반 시 알람Prometheus 규칙 기반kube-burner 설치curl -LO https://github.com/kube-burner/kube-burner/releases/download/v1.17.3/kube-burner-V1.17.3-darwin-arm64.tar.gz # mac Mtar -xvf ..

1. ServiceMesh서비스 메시는 애플리케이션 공통 네트워킹 관심사(보안, 트래픽 제어, 관측)를 앱 외부 인프라에서 투명하게 처리했음.마이크로서비스 운영 도전과제(불신 네트워크, 가용성, 트래픽 가시성, 암호화, 상태, 성능 등)를 앱 코드 대신 인프라로 오프로드했음.기존엔 각 서비스에 라이브러리/패턴(서비스 디스커버리 등)과 메트릭·트레이싱 도구를 직접 포함해야 했으나, 서비스 메시가 이를 일관되게 제공했음.Istio는 서비스 메시 구현체로,데이터 플레인: 애플리케이션 옆에 주입되는 프록시(Envoy) 로 정책 집행, 트래픽 제어, mTLS, 메트릭/트레이싱 생성 수행했음.컨트롤 플레인: 운영자가 데이터 플레인의 동작을 API로 관리/구성했음.Istio가 Envoy를 쓰는 이유는 기능 다양성과 ..

Cilium 에 BGP 설정BGP 동작을 위한 노드 라벨 설정# BGP 동작할 노드를 위한 label 설정kubectl label nodes k8s-ctr k8s-w0 k8s-w1 enable-bgp=truekubectl get node -l enable-bgp=trueCilium 설정cat BGP 연결 확인# BGP 연결 확인ss -tnlp | grep 179ss -tnp | grep 179 Cilium bgp 정보 확인cilium bgp peerscilium bgp routes available ipv4 unicast ip -c route | grep bgptermshark 로 BPG 확인termshark -r /tmp/bgp.pcap노드 유지보수모니터링을 위한 반복 호출kubectl exec -it..

1. OverlayNetwork (Encapsulation) modeVXLAN 설정커널설정, 커널로드grep -E 'CONFIG_VXLAN=y|CONFIG_VXLAN=m|CONFIG_GENEVE=y|CONFIG_GENEVE=m|CONFIG_FIB_RULES=y' /boot/config-$(uname -r)CONFIG_FIB_RULES=y # 커널에 내장됨CONFIG_VXLAN=m # 모듈로 컴파일됨 → 커널에 로드해서 사용CONFIG_GENEVE=m # 모듈로 컴파일됨 → 커널에 로드해서 사용lsmod | grep -E 'vxlan|geneve'modprobe vxlan # modprobe genevelsmod | grep -E 'vxlan|geneve' HelmUpgradehelm upgrade cil..

IPAM ( IP AddreessMnagement )FeatureKubernetes Host ScopeCluster Scope (default)Multi-Pool (Beta)CRD-backedAWS ENI…Tunnel routing✅✅❌❌❌Direct routing✅✅✅✅✅CIDR ConfigurationKubernetesCiliumCiliumExternalExternal (AWS)Multiple CIDRs per cluster❌✅✅N/AN/AMultiple CIDRs per node❌❌✅N/AN/ADynamic CIDR/IP allocation❌❌✅✅✅Kubernetes 호스트 범위 IPAM 모드는ipam: Kubernetes 에서 활성화되며 클러스터의 각 개별 노드에 주소 할당을 위임IP는 Kuber..

1. Network Observability with HubbleHubble의 역할과 구조Cilium과 eBPF 위에 구축된 완전 분산형 네트워킹·보안 관측 플랫폼서비스 간 통신, Pod → 호스트, 호스트 간 네트워크 동작을 투명하게 가시화eBPF 기반 동적 관측커널 레벨 BPF 훅을 활용해 필요한 지점에서 프로그래밍 가능한 추적·필터링오버헤드를 최소화하면서 세밀한 정보(패킷, 커넥션, 메트릭 등) 수집관측 범위: 단일 노드에서 다중 클러스터까지기본 Hubble API는 로컬 Cilium 에이전트가 설치된 노드에 한정된 트래픽 인사이트 제공Hubble Relay를 추가 배포하면 클러스터 메시 환경에서 노드·클러스터·클러스터 간 통합 가시성 확보Hubble API와 CLIHubble API는 노드 내 U..