<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Kubernetes - 태그 - lee's blog</title><link>https://ken-0913.github.io/myblog/tags/kubernetes/</link><description>Kubernetes - 태그 - lee's blog</description><generator>Hugo -- gohugo.io</generator><language>ko-kr</language><managingEditor>hyeonjae0913@gmail.com (ken-0913)</managingEditor><webMaster>hyeonjae0913@gmail.com (ken-0913)</webMaster><lastBuildDate>Tue, 11 Aug 2026 20:00:00 +0900</lastBuildDate><atom:link href="https://ken-0913.github.io/myblog/tags/kubernetes/" rel="self" type="application/rss+xml"/><item><title>kind + RTX 3050 6GB에서 Ray Serve LLM으로 vLLM 서빙하기 — RayService 실습 매뉴얼</title><link>https://ken-0913.github.io/myblog/posts/llm/llm-ray-serving-result/</link><pubDate>Tue, 11 Aug 2026 20:00:00 +0900</pubDate><author><name>ken-0913</name></author><guid>https://ken-0913.github.io/myblog/posts/llm/llm-ray-serving-result/</guid><description><![CDATA[<div class="featured-image">
                <img src="images/banners/llm-ray-serving-result-15513a3c.png" referrerpolicy="no-referrer">
            </div><p><a href="../llm-serving-single-model-lab/" rel="">앞선 두 실습</a>은 서버 한 대에서 프로세스를 직접 띄웠다. 이번에는 <strong>Kubernetes 위에 얹는다.</strong> KubeRay Operator가 Ray 클러스터를 관리하고, 그 위에서 Ray Serve LLM이 vLLM 엔진을 감싸 <strong>OpenAI 호환 엔드포인트</strong>를 노출하는 구조를 만든다.</p>
<p>최종 목표는 하나다. <code>kubectl apply</code> 한 번으로 LLM 서빙이 뜨고, 모델을 바꾸려면 매니페스트만 고치면 되는 상태다.</p>
<p><strong>이 글의 모든 명령과 결과는 RTX 3050 6GB 한 장이 달린 리눅스 데스크톱에서 실제로 실행한 것이다.</strong> 6GB는 LLM 서빙에 넉넉한 크기가 아니라서, 모델과 설정을 어디까지 줄여야 하는지가 이 실습의 절반을 차지한다.</p>]]></description></item><item><title>KubeCon + CloudNativeCon Japan 요코하마 2026 세션 정리 — AI 시대의 Kubernetes와 클라우드 네이티브</title><link>https://ken-0913.github.io/myblog/posts/kubecon-yokohama-2026-review/</link><pubDate>Wed, 29 Jul 2026 21:00:00 +0900</pubDate><author><name>ken-0913</name></author><guid>https://ken-0913.github.io/myblog/posts/kubecon-yokohama-2026-review/</guid><description><![CDATA[<div class="featured-image">
                <img src="images/banners/kubecon-yokohama-2026-review-a6abe5c0.png" referrerpolicy="no-referrer">
            </div><p>2026년 7월 말, KubeCon + CloudNativeCon Japan이 요코하마에서 열렸다. 이번 행사의 공통된 주제는 AI 워크로드를 기존 클라우드 네이티브 생태계 위에 어떻게 통합하느냐였다. 아래는 현장에서 다룬 세션 여섯 개를 정리한 내용이다.</p>
<h2 id="1-키노트-cncf-현황과-ai-시대의-클라우드-네이티브" class="headerLink">
    <a href="#1-%ed%82%a4%eb%85%b8%ed%8a%b8-cncf-%ed%98%84%ed%99%a9%ea%b3%bc-ai-%ec%8b%9c%eb%8c%80%ec%9d%98-%ed%81%b4%eb%9d%bc%ec%9a%b0%eb%93%9c-%eb%84%a4%ec%9d%b4%ed%8b%b0%eb%b8%8c" class="header-mark"></a>1. 키노트: CNCF 현황과 AI 시대의 클라우드 네이티브</h2><h3 id="cncf-생태계-현황" class="headerLink">
    <a href="#cncf-%ec%83%9d%ed%83%9c%ea%b3%84-%ed%98%84%ed%99%a9" class="header-mark"></a>CNCF 생태계 현황</h3><p>Linux Foundation의 Jonathan Bryce(Executive Director)와 Chris Aniszczyk(CTO)가 키노트를 진행했다. KubeCon EU 기준 참석자 13,500명 이상, 100개국 3,500개 조직이 참여했다고 밝혔다. CNCF 프로젝트는 230개를 넘었고 전 세계 기여자는 30만 명, 개발자 수는 6개월 만에 1,500만 명에서 약 2,000만 명으로 늘었다.</p>]]></description></item><item><title>CNPA 시험 정리 (4) Platform APIs — 조정 루프, CRD, Operator, 오토스케일링</title><link>https://ken-0913.github.io/myblog/posts/cnpa/cnpa-04-platform-apis-provisioning/</link><pubDate>Fri, 17 Jul 2026 08:00:00 +0900</pubDate><author><name>ken-0913</name></author><guid>https://ken-0913.github.io/myblog/posts/cnpa/cnpa-04-platform-apis-provisioning/</guid><description><![CDATA[<div class="featured-image">
                <img src="images/banners/cnpa-04-platform-apis-provisioning-6018cc5d.png" referrerpolicy="no-referrer">
            </div><p>이번 편은 <strong>Domain 4: Platform APIs and Provisioning Infrastructure (12%)</strong> 를 정리한다.
핵심은 Kubernetes의 <strong>API + 조정 루프(reconciliation loop)</strong> 가 플랫폼 엔지니어링의 엔진이라는 것이다.
CRD·Operator·프로비저닝 도구로 Kubernetes를 확장해 셀프서비스 API를 만든다.</p>
<h2 id="kubernetes-api와-조정-루프" class="headerLink">
    <a href="#kubernetes-api%ec%99%80-%ec%a1%b0%ec%a0%95-%eb%a3%a8%ed%94%84" class="header-mark"></a>Kubernetes API와 조정 루프</h2><p>모든 도구(kubectl, 대시보드, 커스텀 훅)가 동일한 API와 상호작용한다.
오브젝트는 <strong>spec(원하는 상태)</strong> 과 <strong>status(Kubernetes가 채우는 관측 상태)</strong> 로 구성된다.</p>
<p>조정 루프의 4단계는 핵심이다.</p>
<p><strong>Observe(관찰) → Compare(원하는 상태와 비교) → Act(차이가 있으면 조치) → Repeat(반복)</strong></p>
<p>이 루프는 <strong>폴링이 아니라 이벤트 기반(event-driven)</strong> 이다.
컨트롤러는 변경 이벤트에 반응하며, <strong>Informer</strong>가 watch로 감시하고 캐싱한다.</p>]]></description></item><item><title>ICA 시험 정리 (1) 서비스 메시 기초: Kubernetes Service, Sidecar, Envoy</title><link>https://ken-0913.github.io/myblog/posts/istio-ica/istio-ica-01-prerequisites/</link><pubDate>Thu, 16 Jul 2026 08:00:00 +0900</pubDate><author><name>ken-0913</name></author><guid>https://ken-0913.github.io/myblog/posts/istio-ica/istio-ica-01-prerequisites/</guid><description><![CDATA[<div class="featured-image">
                <img src="images/banners/istio-ica-01-prerequisites-76560b35.png" referrerpolicy="no-referrer">
            </div><p>ICA(Istio Certified Associate) 시험을 준비하기 위한 정리 시리즈의 첫 편이다.
이번 편은 Service Mesh를 이해하기 위한 전제 개념인 <strong>Kubernetes Service</strong>, <strong>Sidecar</strong>, <strong>Envoy</strong>를 다룬다.
세 개념은 결국 Istio 아키텍처로 이어지는 밑바탕이 된다.</p>
<h2 id="kubernetes-service" class="headerLink">
    <a href="#kubernetes-service" class="header-mark"></a>Kubernetes Service</h2><p><strong>Pod</strong>는 Kubernetes의 가장 작은 배포 단위이지만 **일시적(ephemeral)**이다.
Deployment의 의도 상태를 유지하는 과정에서 Pod가 동적으로 생성·종료되며, 이때 Pod의 IP가 계속 변경된다.
그래서 프론트엔드가 개별 Pod IP를 직접 추적하는 방식은 현실적이지 않다.</p>
<p>Service는 **안정적인 IP(stable IP)**를 가지고 Pod 집합으로 트래픽을 라우팅하는 추상화 계층이다.
대상 Pod는 보통 <strong>label</strong>로 선택되므로, Pod에 올바른 label이 지정되어 있어야 Service가 정상 동작한다.</p>]]></description></item><item><title>CNPA 시험 정리 (1) Platform Engineering Core Fundamentals — 선언적 관리, GitOps, 8대 역량</title><link>https://ken-0913.github.io/myblog/posts/cnpa/cnpa-01-platform-engineering-fundamentals/</link><pubDate>Tue, 14 Jul 2026 08:00:00 +0900</pubDate><author><name>ken-0913</name></author><guid>https://ken-0913.github.io/myblog/posts/cnpa/cnpa-01-platform-engineering-fundamentals/</guid><description><![CDATA[<div class="featured-image">
                <img src="images/banners/cnpa-01-platform-engineering-fundamentals-ca73458d.png" referrerpolicy="no-referrer">
            </div><h2 id="선언적-vs-명령적-declarative-vs-imperative" class="headerLink">
    <a href="#%ec%84%a0%ec%96%b8%ec%a0%81-vs-%eb%aa%85%eb%a0%b9%ec%a0%81-declarative-vs-imperative" class="header-mark"></a>선언적 vs 명령적 (Declarative vs Imperative)</h2><p><strong>Imperative(명령적)</strong> 는 레시피처럼 단계별로 <strong>How</strong>를 지시한다.
<strong>Declarative(선언적)</strong> 는 메뉴 주문처럼 원하는 결과, 즉 <strong>desired state(원하는 상태)</strong> 만 선언한다.</p>
<p>플랫폼 엔지니어링은 <strong>선언적 접근을 선호(preferred)</strong> 한다.
선언된 상태는 <strong>control loop(제어 루프)</strong> 가 감시하며 실제 상태를 원하는 상태로 <strong>reconcile(조정)</strong> 한다.</p>
<table>
	<thead>
			<tr>
					<th>구분</th>
					<th>Imperative</th>
					<th>Declarative</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>초점</td>
					<td>How (어떻게)</td>
					<td>What (원하는 상태)</td>
			</tr>
			<tr>
					<td>재실행</td>
					<td>중복 생성 위험</td>
					<td>멱등성(idempotency)</td>
			</tr>
			<tr>
					<td>예시</td>
					<td><code>kubectl create deployment</code></td>
					<td>Kubernetes YAML, Terraform HCL</td>
			</tr>
			<tr>
					<td>장점</td>
					<td>직접 제어, 빠른 실험</td>
					<td>버전 관리, 반복 가능, 감사 가능</td>
			</tr>
	</tbody>
</table>
<p>Imperative가 여전히 유효한 경우는 <strong>디버깅, 긴급 핫픽스(emergency hotfix), 긴급 스케일링, 실험</strong> 정도다.
단, 이후 반드시 선언적 정의로 반영(backfill)해야 한다.</p>]]></description></item></channel></rss>