VMware AVI
면책 조항: 이는 커뮤니티 유지 관리 오픈 소스 프로젝트로, VMware, Inc. 또는 Broadcom Inc.와 제휴, 보증, 후원 관계가 아닙니다. "VMware", "NSX", "AVI"는 Broadcom의 상표입니다. 소스 코드는 MIT 라이선스 하에 github.com/vmware-skills/VMware-AVI에서 공개 감사 가능합니다.
AVI(NSX Advanced Load Balancer) 애플리케이션 전달 및 AKO Kubernetes 운영 — 28개의 MCP 도구.
이중 모드: 전통적인 AVI 컨트롤러 관리 + AKO K8s 운영을 하나의 스킬에 통합했습니다. 계열: vmware-aiops(VM 라이프사이클), vmware-monitor(인벤토리/상태), vmware-storage(iSCSI/vSAN), vmware-vks(Tanzu Kubernetes), vmware-nsx(NSX 네트워킹), vmware-nsx-security(DFW/방화벽), vmware-aria(메트릭/알림/용량), vmware-harden(규정 준수 기준). | vmware-pilot(워크플로 오케스트레이션) | vmware-policy(감사/정책)
이 스킬이 하는 일
| 카테고리 | 도구 | 개수 | 읽기 또는 쓰기 |
|---|---|---|---|
| 가상 서비스 | 목록, 상태, 활성화/비활성화 | 3 | 2R / 1W |
| 풀 멤버 | 풀 검색, 멤버 목록, 멤버 활성화/비활성화(드레인/복원 트래픽) | 4 | 2R / 2W |
| SSL 인증서 | 목록, 만료 확인 | 2 | 2R |
| 애널리틱스 | VS 메트릭 개요, 요청 오류 로그 | 2 | 2R |
| 서비스 엔진 | 목록, 상태 점검 | 2 | 2R |
| AKO 팟 작업 | 상태, 로그, 재시작, 버전 정보 | 4 | 3R / 1W |
| AKO 구성 | values.yaml 보기, Helm diff, Helm 업그레이드 | 3 | 2R / 1W |
| 인그레스 진단 | 어노테이션 검증, VS 매핑, 오류 진단(수정 권장 사항 포함) | 3 | 3R |
| 동기화 진단 | K8s-컨트롤러 비교, 불일치 목록, 강제 재동기화 | 3 | 2R / 1W |
| 멀티 클러스터 | 클러스터 간 AKO 클러스터 목록, AMKO 상태 | 2 | 2R |
총계: 28개 도구 (22 읽기 + 6 쓰기)
빠른 설치
uv tool install vmware-avi
vmware-avi doctor # 컨트롤러 연결 + kubeconfig + avisdk 확인
이 스킬을 사용해야 할 때
- AVI 컨트롤러에서 가상 서비스 목록 확인, 활성화 또는 비활성화
- 풀 멤버 추가, 제거, 드레인 또는 복원 (유지보수 윈도우, 롤링 배포)
- 모든 가상 서비스의 SSL 인증서 만료 확인
- VS 애널리틱스 조회 — 처리량, 지연 시간, 오류율, 요청 로그
- 서비스 엔진 상태 확인 (인벤토리 기반) 및 SE별 VS 배치 개수 확인
- AKO 팟 문제 해결 — 상태, 로그, 재시작
- AKO Helm 구성 관리 — values.yaml 보기, diff, 업그레이드
- 인그레스 어노테이션 검증 및 VS가 예상대로 생성되지 않은 이유 진단
- K8s 리소스와 AVI 컨트롤러 객체 간 동기화 이격 감지
- AKO 배포 및 AMKO 상태의 클러스터 간 보기
함께 사용할 보조 스킬:
- VM 라이프사이클, 배포, 게스트 작업 →
vmware-aiops - NSX 세그먼트, 게이트웨이, NAT →
vmware-nsx - DFW 방화벽 규칙, 보안 그룹 →
vmware-nsx-security - K8s 클러스터 라이프사이클 (Supervisor, TKC) →
vmware-vks - 읽기 전용 vSphere 모니터링 →
vmware-monitor
관련 스킬 — 스킬 라우팅
| 사용자 의도 | 권장 스킬 |
|---|---|
| 로드 밸런서, VS, 풀, AVI, ALB, AKO | vmware-avi ← 이 스킬 |
| VM 라이프사이클, 배포, 게스트 작업 | vmware-aiops (uv tool install vmware-aiops) |
| 읽기 전용 vSphere 모니터링 | vmware-monitor (uv tool install vmware-monitor) |
| 스토리지: iSCSI, vSAN, 데이터스토어 | vmware-storage (uv tool install vmware-storage) |
| NSX 네트워킹: 세그먼트, 게이트웨이, NAT | vmware-nsx (uv tool install vmware-nsx-mgmt) |
| NSX 보안: DFW 규칙, 보안 그룹 | vmware-nsx-security (uv tool install vmware-nsx-security) |
| Tanzu Kubernetes (Supervisor/TKC) | vmware-vks (uv tool install vmware-vks) |
| Aria Ops: 메트릭, 알림, 용량 | vmware-aria (uv tool install vmware-aria) |
| 승인 포함 다중 단계 워크플로 | vmware-pilot |
| 규정 준수 기준 (CIS / 等保 / PCI-DSS), 이격 감지, LLM 수정 권장 어드바이저 | vmware-harden (uv tool install vmware-harden) |
| 감사 로그 쿼리 | vmware-policy (vmware-audit CLI) |
일반 워크플로
유지보수 윈도우 — 풀 멤버 드레인
사전 점검 (판단 — 실제 트래픽에 영향):
- 용량 확인: 풀에 ≥ 2개의 정상 멤버가 있어야 합니다. 유일하게 정상인 다른 멤버를 비활성화하면 자체 DoS가 발생합니다. 먼저
pool members my-pool로 확인하세요. - 연결 지속성: VS가 세션 지속성(쿠키/소스 IP)을 사용하는 경우, 기존 세션은 만료될 때까지 비활성화된 멤버에 고정됩니다. "드레인"은 즉시 이루어지지 않으며, 지속성 TTL에 따라 5-30분이 소요됩니다.
- 장기 연결: WebSocket/스트리밍 세션은 몇 시간 동안 유지될 수 있습니다. 사전에 결정하세요: 강제 연결 해제(빠르지만 사용자에게 보임) 또는 대기(느리지만 투명).
- 관찰 가능성: 비활성화 전에 VS에서 애널리틱스를 활성화하세요 — 성능 저하를 감지하려면 기준선이 필요합니다.
단계:
pool members my-pool→ ≥ 2개의 정상 멤버 확인 및 세션 지속성 구성 식별pool disable my-pool <server-ip>(정상 드레인 — 새 연결 중단, 기존 연결 완료)analytics my-vs --duration 15m→ 드레인된 멤버에 대한 활성 연결 수가 0에 가까워지는지 모니터링- 활성 연결 = 0이 된 후에만 유지보수 수행 (또는 강제 연결 해제를 결정한 경우)
pool enable my-pool <server-ip>→ 다시 활성화- 성공 선언 전 확인: 상태 모니터 통과(일반적으로 30-90초) 및 새 연결이 멤버에 도달하는지 확인(애널리틱스 드릴다운)
AKO 인그레스가 VS를 생성하지 않음
판단: 이는 계층적 장애입니다 — 무작위로 조사하기 전에 어떤 계층이 고장 났는지 파악하세요. AKO는 컨트롤러입니다. 다른 모든 K8s 컨트롤러와 마찬가지로 장애 모드는 다음과 같습니다: (a) 컨트롤러 다운, (b) 컨트롤러가 실행 중이지만 잘못된 입력을 보고 있음, (c) 컨트롤러가 작동 중이지만 Avi가 출력을 거부함.
ako status→ 컨트롤러 실행 중, 최근 재조정, 패닉 로그 없음? 그렇지 않다면 여기서 먼저 수정ako ingress check <namespace>→ 필요한 어노테이션이 있는가? 일반적인 누락:kubernetes.io/ingress.class,aviinfrasetting.ako.vmware.com/nameako sync status→ K8s 상태와 Avi 상태 간 이격. 몇 분 이상의 이격은 일반적으로 컨트롤러 오류를 의미ako ingress diagnose <ingress-name>→ AKO 자체 진단; 종종 문제를 정확히 짚어냄- 동기화가 이격된 경우:
ako sync diff→ Avi 측에서 누락된 항목 검토. 이격이 발생한 이유를 이해한 후에만 강제 재동기화 — 맹목적 재동기화는 재발할 버그를 숨깁니다
SSL 인증서 만료 감사
판단: 인증서 만료는 LB 세계에서 가장 예방 가능한 중단입니다. 정기적으로 실행하되, 반응적으로 실행하지 마세요. 30일 기간은 최소입니다 — 프로덕션의 경우 갱신 리드 타임을 허용하려면 60일 이상으로 설정하세요.
ssl expiry --days 60→ 60일 이내에 만료되는 인증서 포착, 30일이 아님; 엔터프라이즈 갱신 주기는 2-4주 소요- VS 매핑(출력에서)과 교차 참조 → 위험에 처한 앱 식별; 일부 인증서는 사용되지 않을 수 있음(고아, 정리 대상)
- 결정:
unused(VS 없음)로 표시된 인증서 → 감사 일부로 삭제 제안;in_use인증서 → VS 목록 및 정확한 만료 날짜와 함께 인증서 팀에 에스컬레이션 - 갱신 후 후속 재검사 예약 (인증서 팀 확인에만 의존하지 않음)
사용 모드
| 시나리오 | 권장 | 이유 |
|---|---|---|
| 로컬/소형 모델 (Ollama, Qwen) | CLI | MCP의 ~8K 토큰 대비 ~2K 토큰 |
| 클라우드 모델 (Claude, GPT-4o) | 둘 다 | MCP는 구조화된 JSON I/O 제공 |
| 자동화된 파이프라인 | MCP | 타입 안전 파라미터, 구조화된 출력 |
| AKO 문제 해결 | CLI | 대화형 로그 테일링, Helm diff 출력 |
MCP 도구 (28 — 22 읽기, 6 쓰기)
| 카테고리 | 도구 | R/W |
|---|---|---|
| 가상 서비스 (3) | vs_list, vs_status | 읽기 |
vs_toggle | 쓰기 | |
| 풀 멤버 (4) | pool_list, pool_members | 읽기 |
pool_member_enable, pool_member_disable | 쓰기 | |
| SSL 인증서 (2) | ssl_list, ssl_expiry_check | 읽기 |
| 애널리틱스 (2) | vs_analytics, vs_error_logs | 읽기 |
| 서비스 엔진 (2) | se_list, se_health | 읽기 |
| AKO 팟 (4) | ako_status, ako_logs, ako_version | 읽기 |
ako_restart | 쓰기 | |
| AKO 구성 (3) | ako_config_show, ako_config_diff | 읽기 |
ako_config_upgrade | 쓰기 | |
| 인그레스 진단 (3) | ako_ingress_check, ako_ingress_map, ako_ingress_diagnose | 읽기 |
| 동기화 진단 (3) | ako_sync_status, ako_sync_diff | 읽기 |
ako_sync_force | 쓰기 | |
| 멀티 클러스터 (2) | ako_clusters, ako_amko_status | 읽기 |
읽기/쓰기 분할: 22개 도구는 읽기 전용이며, 6개는 상태를 수정합니다. 쓰기 도구는 이중 확인이 필요하며 감사 로깅됩니다.
CLI 빠른 참조
# === 전통 모드 (AVI 컨트롤러) ===
vmware-avi vs list [--controller <이름>]
vmware-avi vs status <vs-name>
vmware-avi vs enable <vs-name>
vmware-avi vs disable <vs-name> # 이중 확인
vmware-avi pool members <pool-name>
vmware-avi pool enable <pool> <server-ip>
vmware-avi pool disable <pool> <server-ip> # 이중 확인 (정상 드레인)
vmware-avi ssl list
vmware-avi ssl expiry [--days 30]
vmware-avi analytics <vs-name>
vmware-avi logs <vs-name> [--since 1h]
vmware-avi se list
vmware-avi se health
# === AKO 모드 (K8s) ===
vmware-avi ako status [--context <k8s-context>]
vmware-avi ako logs [--tail 100] [--since 30m]
vmware-avi ako restart # 이중 확인
vmware-avi ako config show
vmware-avi ako config diff
vmware-avi ako config upgrade # 이중 확인 + --dry-run 기본값
vmware-avi ako ingress check <namespace>
vmware-avi ako ingress map
vmware-avi ako ingress diagnose <ingress-name>
vmware-avi ako sync status
vmware-avi ako sync diff
vmware-avi ako sync force # 이중 확인
vmware-avi ako clusters
vmware-avi ako amko status
전체 CLI 참조:
references/cli-reference.md참조
문제 해결
"컨트롤러에 연결할 수 없음" 오류
vmware-avi doctor를 실행하여 연결 확인~/.vmware-avi/config.yaml에서 컨트롤러 주소와 포트가 올바른지 확인- 자체 서명 인증서의 경우: config.yaml에서
verify_ssl: false설정 (실험실 환경에서만)
AKO 팟 CrashLoopBackOff
- 로그 확인 →
vmware-avi ako logs --tail 50 - 일반적인 원인: values.yaml의 잘못된 컨트롤러 IP, 네트워크 정책이 AKO→컨트롤러를 차단함, 자격 증명 만료
- 구성 수정 →
vmware-avi ako config show로 검사한 다음, 수정된 값으로vmware-avi ako config upgrade실행 (릴리스 자동 검색 — 공식 설치는--generate-name사용; 공식 Broadcom OCI 차트oci://projects.packages.broadcom.com/ako/helm-charts/ako를 가져옴)
인그레스가 생성되었지만 컨트롤러에 VS가 없음
- 어노테이션 검증 →
vmware-avi ako ingress check <namespace> - AKO 로그에서 거부 이유 확인 →
vmware-avi ako logs --since 5m - 동기화 diff 실행 →
vmware-avi ako sync diff하여 객체가 멈췄는지 확인
풀 멤버 활성화 후 "down" 표시
상태 모니터가 여전히 실패 중일 수 있습니다. 컨트롤러 측에서 실제 상태를 확인하세요 — 멤버는 활성화되었지만 비정상입니다. 먼저 백엔드 서비스를 수정하면 상태가 자동으로 복구됩니다.
SSL 만료 확인 시 인증서 0개 표시
컨트롤러 연결에 테넌트 수준 액세스 권한이 있는지 확인하세요. AVI에서 인증서는 테넌트 범위입니다 — 구성된 사용자는 자신의 테넌트에 있는 인증서만 볼 수 있습니다.
AKO 강제 재동기화 효과 없음
강제 재동기화는 AKO가 모든 K8s 객체를 다시 조정하도록 트리거합니다. 이격이 지속되면 문제는 K8s 리소스 정의 자체(잘못된 어노테이션, 누락된 시크릿)에 있을 가능성이 높습니다. vmware-avi ako ingress diagnose를 사용하여 근본 원인을 정확히 찾아내세요.
설정
uv tool install vmware-avi
mkdir -p ~/.vmware-avi
vmware-avi init # config.yaml 및 .env 템플릿 생성
chmod 600 ~/.vmware-avi/.env
vmware-avi doctor # 컨트롤러 + K8s 연결 확인
모든 도구는 vmware-policy를 통해 자동 감사됩니다. 감사 로그:
vmware-audit log --last 20
지원 버전: AVI 컨트롤러 22.1.x (v1.5.11에서 수정된 애널리틱스 엔드포인트 문제) 및 30.x. VCF 9.0 / 9.1 호환 선언 (avisdk >=22.1,<31.0가 번들 AVI 포함). Python 3.11+. 전체 표: references/capabilities.md → 버전 호환성.
전체 설정 가이드, 보안 세부 사항, AI 플랫폼 호환성 및 컨테이너/Smithery 배포:
references/setup-guide.md참조
감사 및 안전
모든 작업은 vmware-policy(@vmware_tool 데코레이터)를 통해 자동 감사됩니다:
- 모든 도구 호출이
~/.vmware/audit.db(SQLite, 프레임워크 독립적)에 기록됨 - 정책 규칙이
~/.vmware/rules.yaml(거부 규칙, 유지보수 윈도우, 위험 수준)을 통해 적용됨 - 각 컨트롤러는 선택적 레이블로
config.yaml에environment:(production/staging/lab)을 선언할 수 있으며,~/.vmware/rules.yaml의 환경 범위deny규칙이 이를 일치시켜 쓰기를 차단할 수 있음 (예:production고정). 레이블이 없는 컨트롤러는 해당 규칙의 영향을 받지 않음. 읽기는 절대 영향을 받지 않음 - 파괴적 작업(
vs_toggle비활성화,pool_member_disable,ako_restart,ako_config_upgrade,ako_sync_force)은 이중 확인 필요 ako_config_upgrade는 기본적으로--dry-run모드 — 사용자가 명시적으로 확인해야 적용됨- 최근 작업 보기:
vmware-audit log --last 20