<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>migration on Oleksandr Kulbida</title>
    <link>https://okulbida.com/tags/migration/</link>
    <description>Recent content in migration on Oleksandr Kulbida</description>
    <generator>Hugo -- gohugo.io</generator>
    <lastBuildDate>Fri, 25 Sep 2026 00:00:00 +0300</lastBuildDate><atom:link href="https://okulbida.com/tags/migration/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Moving a Kubernetes service to another namespace without downtime</title>
      <link>https://okulbida.com/posts/kubernetes-namespace-migration-externalname/</link>
      <pubDate>Fri, 25 Sep 2026 00:00:00 +0300</pubDate>
      
      <guid>https://okulbida.com/posts/kubernetes-namespace-migration-externalname/</guid>
      <description>CNCF published a nice write-up by George Sims: Migrating a critical Kubernetes deployment from the default namespace without any downtime. The story is about an auth service that lived in default for years, but the approach works for moving any service from one namespace to another. default is just the example.
The main idea is simple. You keep the old DNS name alive as a compatibility point. In the old namespace you leave a Service of type ExternalName that points to the service in its new namespace, and callers keep working without changing anything.</description>
    </item>
    
  </channel>
</rss>
