스킬 service-mesh-expert
📦

service-mesh-expert

안전

Istio 및 Linkerd로 서비스 메시 아키텍처 설계

마이크로서비스는 복잡성 없이 안전하고 관찰 가능한 통신이 필요합니다. 이 스킬은 제로 트러스트 네트워킹 및 트래픽 관리를 포함한 Istio 및 Linkerd 배포에 대한 전문적인 안내를 제공합니다.

지원: Claude Codex Code(CC)
📊 70 적절함
1

스킬 ZIP 다운로드

2

Claude에서 업로드

설정 → 기능 → 스킬 → 스킬 업로드로 이동

3

토글을 켜고 사용 시작

테스트해 보기

"service-mesh-expert" 사용 중입니다. undefined

예상 결과:

순환 모드 마igration 경로로 시작하여 암호화를 확인하는 검증 명령과 함께 클러스터 전체에 엄격한 mTLS를 적용하기 위한 단계별 PeerAuthentication 및 DestinationRule 구성

"service-mesh-expert" 사용 중입니다. undefined

예상 결과:

사이드카 주입 검증, VirtualService 라우팅 분석, 권한 부여 정책 충돌, 예상 출력과 함께 istioctl 디버그 명령을 포함한 체계적인 트러블슈팅 체크리스트

보안 감사

안전
v1 • 2/25/2026

Static analysis flagged 4 patterns that are all false positives. Line 22 uses Markdown backticks for documentation reference, not shell execution. Lines 3, 46, and 60 contain no cryptographic code - they reference mTLS conceptually in documentation. This is a markdown-only skill with no executable code, external commands, or security risks.

1
스캔된 파일
61
분석된 줄 수
0
발견 사항
1
총 감사 수
보안 문제를 찾지 못했습니다
감사자: claude

품질 점수

38
아키텍처
100
유지보수성
87
콘텐츠
25
커뮤니티
100
보안
91
사양 준수

만들 수 있는 것

Kubernetes 플랫폼 엔지니어

고가용성 요구사항을 처리하는 프로덕션 마이크로서비스 플랫폼에 mTLS 적용 및 트래픽 정책이 포함된 Istio 서비스 메시를 배포합니다.

DevOps 팀 리더

Istio VirtualService 및 DestinationRule 구성을 사용하여 트래픽 스플릿팅이 포함된 카나리 배포 및 자동 롤백을 구현합니다.

보안 아키텍트

모든 네임스페이스에서 mTLS 및 AuthorizationPolicy 적용을 사용하여 서비스 간 인증을 위한 제로 트러스트 네트워크 아키텍처를 설계합니다.

이 프롬프트를 사용해 보세요

기본 서비스 메시 설정 
Kubernetes 클러스터에 Istio 서비스 메시를 설정하는 것을 도와주세요. 3개의 네임스페이스(dev, staging, prod)가 있고 서비스 간 기본 mTLS가 필요합니다. 설치 단계와 초기 구성은 무엇인가요?
트래픽 라우팅 구성 
서킷 브레이커 구현 
 
다중 클러스터 페더레이션 
 
 
 
모범 사례
 
  •  모든 서비스가 올바르게 통신하는지 확인한 후 PERMISSIVE mTLS 모드로 시작하여 점차 STRICT로 마이그레이션
  •  프로덕션 배포 전에 실패 후가 아닌 서킷 브레이커 및 재시도 정책 구현
  •  네임스페이스 수준 정책 격리를 사용하여 환경별로 다른 보안 및 트래픽 규칙 적용
 
 
피하기
 
  •  처음에 순환 모드에서 테스트하지 않고 클러스터 전체에 엄격한 mTLS 활성화 - 즉각적인 서비스 중단 발생
  •  서비스가 안정적이라고 가정하여 서킷 브레이커 구성 건너뛰기 - 부하 하에서 연쇄 실패 발생
  •  실제 CPU 및 메모리 사용량 모니터링 없이 사이드카 리소스 과도 프로비저닝 - 불필요한 비용 증가
 
 
자주 묻는 질문
 
Istio와 Linkerd의 사용 사례 차이점은 무엇인가요?  
Istio는 더 높은 복잡성과 함께 종합적인 트래픽 관리, 보안 및 관찰 가능성을 제공합니다. Linkerd는 더 낮은 리소스 오버헤드로 더 간단한 mTLS 및 기본 관찰 가능성을 제공합니다. 복잡한 라우팅 요구사항에는 Istio, 최소한의 운영 부담에는 Linkerd를 선택하세요.
서비스 메시가 내 서비스에 상당한 지연 시간을 추가하나요?  
전형적인 사이드카 프록시 오버헤드는 mTLS 및 라우팅 시 요청당 3-10ms입니다. Linkerd는 Istio(5-10ms)보다 일반적으로 더 낮은 오버헤드(2-5ms)를 가집니다. 보안 및 관찰 가능성 이점은 일반적으로 지연 시간 비용을 상쇄하지만, 프로덕션 배포 전에 특정 워크로드를 측정하세요.
비 Kubernetes 워크로드와 함께 서비스 메시를 사용할 수 있나요?  
Istio는 istio-vm 통합을 통해 VM을 지원하여 하이브리드 배포를 허용합니다. Linkerd는 Kubernetes가 필요합니다. 혼합 환경의 경우 적절한 VM 사이드카 프록시 구성을 가진 Istio가 더 나은 선택입니다.
서비스 메시를 통해 데이터베이스 연결을 어떻게 처리하나요?  
데이터베이스 트래픽은 일반적으로 트래픽 제외 규칙을 사용하여 메시를 우회합니다. 데이터베이스 포트의 사이드카 가로채기 제외를 구성하거나, 적절한 TLS 발신으로 제어된 외부 액세스를 위한 egress 게이트웨이를 사용하세요.
서비스 메시에 어떤 모니터링을 설정해야 하나요?  
사이드카 프록시 CPU 및 메모리, 요청 지연 백분위수(p50, p95, p99), 오류율, mTLS 연결 상태 및 구성 동기화 상태를 모니터링하세요. 기본 제공 Istio 또는 Linkerd 대시보드를 사용하여 Prometheus 및 Grafana와 통합하세요.
문제のある 메시 구성을 어떻게 롤백하나요?  
버전 관리된 Istio 구성을 Git에 유지합니다. kubectl apply와 함께 이전 매니페스트 버전을 사용하여 즉시 롤백합니다. 중요한 문제의 경우 네임스페이스 수준에서 사이드카 주입을 비활성화하고 메시를 일시적으로 우회하기 위해 포드를 다시 배포하세요.
 
 
개발자 세부 정보
 
작성자
 sickn33
 
라이선스
 
MIT
 
리포지토리
 https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/service-mesh-expert
 
참조
 
main
 
파일 구조
 
📄 SKILL.md