Kubernetes | The .NET Blog

Aspire 13.3: Kubernetes 지원, 브라우저 로그 및 Aspireify 스킬

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

5주는 릴리스로서 긴 시간이 아니지만 Aspire 13.3은 그렇게 느껴지지 않습니다. 주요 항목들은 의미 있습니다: Helm을 사용한 Kubernetes 및 AKS 퍼스트클래스 배포, Aspireify라는 에이전트 지원 온보딩 스킬, 대시보드에서 직접 브라우저 로그 캡처, 구조화된 명령 결과. 여기에 45개의 새 기능, 134개의 개선 사항, 93개의 버그 수정도 포함됩니다.

하이라이트를 살펴보겠습니다.

Aspireify: 에이전트 지원 온보딩

기존 프로젝트에 Aspire를 추가하는 것은 간단해 보입니다 — AppHost를 추가하면 끝. 실제로는 많은 조사가 필요합니다: 어떤 포트가 중요한지, 어떤 환경 변수가 실제 의존성인지, 어떤 Docker Compose 서비스를 Aspire 통합에 매핑해야 하는지.

새로운 Aspireify 스킬은 코딩 에이전트에게 정확히 이를 위한 가이드 워크플로우를 제공합니다. aspire init이 스켈레톤 AppHost를 만들 때, Aspireify 스킬은 에이전트가 저장소를 검사하고, 이미 어떻게 작동하는지 이해하고, 앱에 맞게 AppHost를 연결하는 데 도움을 줍니다 — 반대가 아닙니다.

기본 입장은 “코드 변경을 최소화"입니다. 앱이 이미 DATABASE_URL을 읽는다면, 에이전트는 구성을 다시 작성하도록 요청하는 대신 WithEnvironment()로 매핑합니다. 포트가 하드코딩된 경우 스킬은 에이전트에게 언제 보존해야 하는지 알려줍니다.

이것이 검토할 작업을 더 생성하는 것이 아니라 실제로 시간을 절약하는 AI 툴링의 유형입니다.

퍼스트클래스 Kubernetes 및 AKS 배포

이것은 한동안 위시리스트에 있었습니다. Aspire 13.3은 Helm을 사용한 Kubernetes 및 AKS 퍼스트클래스 배포 지원을 제공합니다. 이제 Aspire 도구에서 직접 AKS를 배포 대상으로 지정할 수 있습니다.

AKS에서 이미 프로덕션 워크로드를 실행 중인 팀에게 이것은 중요한 격차를 메웁니다. Aspire 앱 모델은 이제 Helm 차트를 수동으로 작성할 필요 없이 로컬 개발에서 Kubernetes로의 깔끔한 경로를 갖게 됩니다.

대시보드의 브라우저 로그

이것은 프론트엔드 문제를 디버깅하기 전까지는 작아 보이는 기능 중 하나입니다.

새로운 WithBrowserLogs() API는 엔드포인트를 지원하는 모든 리소스에 추적된 브라우저 리소스를 첨부합니다. Aspire는 개인 CDP 파이프를 사용하여 Chromium을 시작하고 콘솔 로그, 네트워크 요청 및 오류를 리소스의 로그 스트림으로 직접 스트리밍합니다:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

TypeScript AppHost도 동일하게 지원합니다:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

콘솔 오류, 실패한 네트워크 요청, 클라이언트 측 예외 — 이미 트레이스와 메트릭을 관찰하고 있는 동일한 대시보드에서 모두 볼 수 있습니다. 기본적인 것들을 위해 브라우저 DevTools로 탭을 전환할 필요가 없습니다.

구조화된 명령 결과

리소스 명령이 중요한 업그레이드를 받았습니다. 이전에는 명령이 성공/실패를 반환했습니다. 이제 구조화된 결과를 반환합니다: 모델, 대시보드 UI, CLI 및 MCP 도구를 통해 흐르는 텍스트, JSON 또는 Markdown입니다.

대시보드는 헤더의 새로운 알림 센터로 이 모든 것을 묶습니다. 명령 결과는 Markdown 렌더링과 “응답 보기” 작업이 있는 타임스탬프된 알림으로 나타납니다.

이는 리소스 명령을 진정으로 조합 가능하게 만듭니다. 이제 통합은 단순히 어딘가의 상태를 변경하는 것이 아니라 터널 URL과 같은 의미 있는 출력을 반환하는 명령을 노출할 수 있습니다.

결론

Aspire 13.3은 Kubernetes 지원만으로도 업데이트할 가치가 있습니다. 브라우저 로그와 구조화된 명령 결과는 일상적인 개발 워크플로우에서 빠르게 쌓이는 삶의 질 향상 유형입니다.

전체 릴리스 노트: What’s New in Aspire 13.3

KubeCon Europe 2026: .NET 개발자가 실제로 알아야 할 것

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

이 게시물은 자동 번역되었습니다. 원본은 여기를 클릭하세요.

거대한 발표 글이 올라오고 스크롤하면서 “멋지긴 한데, 이게 실제로 나한테 뭘 바꿔주는 거지?“라고 생각하는 그 느낌 아시죠? 매 KubeCon 시즌마다 저한테 벌어지는 일입니다.

Microsoft가 방금 KubeCon Europe 2026 전체 요약을 발표했는데요 — Brendan Burns 본인이 직접 작성했습니다 — 솔직히? 진짜 내용이 있습니다. 기능 체크리스트가 아니라, 프로덕션에서 운영하는 방식을 바꿔주는 운영 개선 사항들입니다.

.NET 개발자로서 진짜 중요한 것만 정리해 보겠습니다.

서비스 메시 세금 없는 mTLS

서비스 메시의 문제점: 모두가 보안 보장을 원하지만, 운영 오버헤드는 아무도 원하지 않습니다. AKS가 드디어 이 격차를 메우고 있습니다.

Azure Kubernetes Application Network은 상호 TLS, 애플리케이션 인식 인가, 트래픽 텔레메트리를 제공합니다 — 사이드카가 무거운 풀 메시를 배포할 필요 없이요. Advanced Container Networking Services의 Cilium mTLS와 결합하면, X.509 인증서와 SPIRE 신원 관리를 사용한 암호화된 pod 간 통신을 얻을 수 있습니다.

실제로 의미하는 것: ASP.NET Core API가 백그라운드 워커와 통신하고, gRPC 서비스가 서로 호출하는 것 — 모두 네트워크 수준에서 암호화되고 신원 검증되며, 애플리케이션 코드 변경은 제로. 이건 큽니다.

ingress-nginx에서 마이그레이션하는 팀을 위해, Meshless Istio를 사용한 Application Routing도 있으며 Kubernetes Gateway API를 완전히 지원합니다. 사이드카 없음. 표준 기반. 점진적 마이그레이션을 위한 ingress2gateway 도구도 함께 출시되었습니다.

뒤늦은 생각이 아닌 GPU 관측성

.NET 서비스와 함께 AI 추론을 실행하고 있다면(솔직히, 누가 시작하지 않고 있겠어요?), GPU 모니터링 사각지대를 경험했을 겁니다. CPU/메모리 대시보드는 훌륭했는데, GPU는… 수동 익스포터 설정 없이는 아무것도 없었죠.

AKS가 이제 GPU 메트릭을 네이티브로 노출합니다 — 관리형 Prometheus와 Grafana에서. 같은 스택, 같은 대시보드, 같은 알림 파이프라인. 커스텀 익스포터도 서드파티 에이전트도 불필요.

네트워크 측에서는, HTTP, gRPC, Kafka 트래픽에 대한 플로우별 가시성이 원클릭 Azure Monitor 경험과 함께 추가되었습니다. IP, 포트, 워크로드, 플로우 방향, 정책 결정 — 모두 내장 대시보드에서.

그리고 두 번 쳐다보게 만든 것: agentic container networking이 자연어로 클러스터의 네트워크 상태에 대해 질문할 수 있는 웹 UI를 추가합니다. “Pod X가 서비스 Y에 도달하지 못하는 이유는?” → 라이브 텔레메트리에서 읽기 전용 진단. 새벽 2시에 진짜 유용합니다.

박사 학위 필요 없는 크로스 클러스터 네트워킹

멀티 클러스터 Kubernetes는 역사적으로 “자체 네트워크 접착제를 가져오세요” 경험이었습니다. Azure Kubernetes Fleet Manager가 이제 관리형 Cilium 클러스터 메시를 통한 크로스 클러스터 네트워킹을 제공합니다:

AKS 클러스터 간 통합 연결
크로스 클러스터 디스커버리를 위한 글로벌 서비스 레지스트리
클러스터마다 반복하지 않고 중앙에서 관리되는 설정

복원력이나 컴플라이언스를 위해 여러 리전에서 .NET 마이크로서비스를 실행하고 있다면, 많은 취약한 커스텀 접착제를 대체합니다. West Europe의 서비스 A가 메시를 통해 East US의 서비스 B를 발견하고 호출할 수 있으며, 일관된 라우팅과 보안 정책이 적용됩니다.

용기가 필요 없는 업그레이드

솔직히 — 프로덕션에서의 Kubernetes 업그레이드는 스트레스입니다. “업그레이드하고 기도하기"가 너무 많은 팀의 사실상 전략이었고, 클러스터가 버전에서 뒤처지는 주된 이유입니다.

두 가지 새로운 기능이 이것을 바꿉니다:

Blue-green 에이전트 풀 업그레이드는 새 설정으로 병렬 노드 풀을 생성합니다. 동작을 검증하고, 트래픽을 점진적으로 이동하고, 깨끗한 롤백 경로를 유지하세요. 프로덕션 노드에서의 인플레이스 변경은 이제 끝.

에이전트 풀 롤백은 업그레이드가 잘못된 후 클러스터를 재구축하지 않고 노드 풀을 이전 Kubernetes 버전과 노드 이미지로 되돌릴 수 있게 합니다.

함께 사용하면, 운영자에게 업그레이드 생명주기에 대한 진정한 통제력을 제공합니다. .NET 팀에게 중요한 이유는 플랫폼 속도가 새로운 런タ임, 보안 패치, 네트워크 기능을 얼마나 빨리 채택하는지를 직접 제어하기 때문입니다.

AI 워크로드가 Kubernetes의 일급 시민이 되다

업스트림 오픈소스 작업도 마찬가지로 중요합니다. Dynamic Resource Allocation (DRA)이 Kubernetes 1.36에서 GA가 되어, GPU 스케줄링이 우회 방법이 아닌 진정한 일급 기능이 되었습니다.

주목할 프로젝트들:

프로젝트	하는 일
AI Runway	추론을 위한 공통 Kubernetes API — K8s를 몰라도 모델 배포 가능, HuggingFace 검색과 비용 추정 포함
HolmesGPT	클라우드 네이티브를 위한 에이전트 문제 해결 — CNCF Sandbox 프로젝트로 합류
Dalec	SBOM 생성을 포함한 선언적 컨테이너 이미지 빌드 — 빌드 단계에서 CVE 감소

방향은 명확합니다: 여러분의 .NET API, Semantic Kernel 오케스트레이션 레이어, 추론 워크로드 모두 하나의 일관된 플랫폼 모델에서 실행되어야 합니다. 거기에 도달하고 있습니다.

이번 주부터 시작한다면

팀에서 이러한 변경 사항을 평가하고 있다면, 제 솔직한 우선순위 목록:

관측성 먼저 — 비프로덕션 클러스터에서 GPU 메트릭과 네트워크 플로우 로그를 활성화하세요. 놓치고 있던 것을 확인하세요.
Blue-green 업그레이드 테스트 — 다음 프로덕션 클러스터 업그레이드 전에 롤백 워크플로우를 테스트하세요. 프로세스에 대한 신뢰를 구축하세요.
신원 인식 네트워킹 파일럿 — 내부 서비스 경로 하나를 선택해서 Cilium으로 mTLS를 활성화하세요. 오버헤드를 측정하세요 (스포일러: 최소).
Fleet Manager 평가 — 두 개 이상의 클러스터를 운영한다면, 크로스 클러스터 네트워킹은 커스텀 접착제 감소만으로도 투자 대비 이득.

작은 실험, 빠른 피드백. 항상 정답인 방법입니다.

마무리

KubeCon 발표는 압도적일 수 있지만, 이번 배치는 AKS의 .NET 팀에게 진정으로 바늘을 움직입니다. 메시 오버헤드 없는 더 나은 네트워크 보안, 진짜 GPU 관측성, 더 안전한 업그레이드, 그리고 더 강력한 AI 인프라 기반.

이미 AKS를 사용하고 있다면, 운영 기준선을 강화할 좋은 시점입니다. .NET 워크로드를 Kubernetes로 이동할 계획이라면 — 플랫폼이 훨씬 더 프로덕션에 준비되었습니다.