Rancher'daki K3S Pods için Ağ Erişim Sorunlarını Çözme

K3S'de POD Ağ Sınırlamalarını Anlama 🛜

Rancher ve K3'lerle bir Kubernetes kümesi kurarken, ağ oluşturma büyük bir zorluk haline gelebilir. İşçi düğümleri harici ağlara ulaşabildiğinde yaygın bir sorun ortaya çıkar, ancak bu düğümlerde çalışan kapsüller kısıtlanır. Bu, özellikle düğümleriniz yapılandırılmış uygun yollara sahip olduğunda sinir bozucu olabilir, ancak baklalarınız izole kalır.

Bu senaryo, işçi düğümlerinin daha geniş bir ağ mimarisinin bir parçası olduğu ortamlarda genellikle karşılaşılır. Örneğin, işçi düğümleriniz 192.168.1.x alt ağına ait olabilir ve statik yollar aracılığıyla 192.168.2.x gibi başka bir alt ağa erişebilir. Ancak, bu düğümlerde çalışan kapsüller 192.168.2.x'de makinelerle iletişim kuramaz.

Buradaki zorluk, Kubernetes'in ağ oluşturmayı nasıl yönettiği ve trafiğin kapsüllerden dış hedeflere nasıl aktığını. Uygun yapılandırma olmadan, POD'lar yalnızca kendi düğümlerinin ağındaki kaynaklara erişebilir ve harici makineleri erişilemez bırakabilir. Bunun neden olduğunu anlamak bir çözüm bulmak için çok önemlidir.

Bu makalede, bölmelerin neden bu ağ kısıtlamalarıyla karşılaştıklarını ve harici alt ağlara erişmelerini nasıl sağlayacaklarını araştıracağız. Pratik adımlar ve gerçek dünya örnekleri sayesinde, bu bağlantı boşluğunu kapatmanıza yardımcı olacağız. Hadi dalalım! 🚀

K3S Pods için ağlar arası bağlantının sağlanması

Dağıtırken K3S Rancher ile, bölmelerin hemen alt ağının dışındaki makinelerle iletişim kurması gerektiğinde ağ oluşturma sorunları ortaya çıkabilir. Komut dosyaları, yönlendirme kurallarını değiştirerek ve NAT (Ağ Adresi Çevirisi) yapılandırarak bu sorunu ele alır. Bir anahtar komut dosyası kullanır iptables Maskeli bir kural uygulamak için, bölme trafiğinin işçi düğümünün kendisinden gelmesini sağlamak. Bu, harici makinelerin varsayılan ağ izolasyonunun üstesinden gelerek kapsüllere yanıt vermesini sağlar.

Başka bir yaklaşım, statik yolların manuel olarak eklenmesini içerir. İşçi düğümleri genellikle statik yollar aracılığıyla diğer ağlara erişebilir, ancak Kubernetes Pods bu rotaları varsayılan olarak devralmaz. Düğüm ağ geçidi aracılığıyla 192.168.2.x'e açıkça bir yol ekleyen bir komut dosyası çalıştırarak, bölmelerin bu makinelere ulaşabileceğinden emin oluruz. Bu, farklı departmanlar için ayrı VLAN'lara sahip şirketler gibi birden fazla dahili ağın iletişim kurması gereken ortamlarda gereklidir.

Süreci otomatikleştirmek için Kubernetes Daemonset dağıtılabilir. Bu, ağ yapılandırmalarının kümedeki tüm düğümlere tutarlı bir şekilde uygulanmasını sağlar. DaemonSet, ağ komutlarını yürüten ve onu ölçeklenebilir bir çözüm haline getiren ayrıcalıklı bir kap çalıştırır. Bu yöntem, her bir düğümü manuel olarak yapılandırmanın pratik olmayacağı büyük bir işçi düğümü filosunu yönetirken özellikle yararlıdır. Başka bir alt ağda barındırılan eski bir veritabanına erişim gerektiren bulut tabanlı bir uygulamayı düşünün-bu kurulum sorunsuz bağlantı sağlar.

Son olarak, test çok önemlidir. Sağlanan komut dosyası, harici bir makineye ping atmaya çalışan basit bir meşgul kutusu bölmesi dağıtır. Ping başarılı olursa, bağlantı düzeltmesinin çalıştığını doğrular. Bu tür gerçek dünya doğrulaması, kırık ağ yapılandırmalarının hizmet kesintilerine yol açabileceği üretim ortamlarında paha biçilmezdir. Bu yaklaşımları birleştirerek-NAT, statik rotalar, Kubernetes otomasyonu ve canlı testler-K3S kümelerinde net iş erişimi için sağlam bir çözüm oluştururuz. 🚀

#!/bin/bash
# Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
# Add NAT rule to allow pods to access external networks
iptables -t nat -A POSTROUTING -s 10.42.0.0/16 -o eth0 -j MASQUERADE
# Persist iptables rule
iptables-save > /etc/iptables/rules.v4
# Restart networking service
systemctl restart networking

#!/bin/bash
# Add a static route to allow pods to reach 192.168.2.x
ip route add 192.168.2.0/24 via 192.168.1.1 dev eth0
# Verify the route
ip route show
# Make the route persistent
echo "192.168.2.0/24 via 192.168.1.1 dev eth0" >> /etc/network/interfaces
# Restart networking
systemctl restart networking

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: k3s-network-fix
spec:
  selector:
    matchLabels:
      app: network-fix
  template:
    metadata:
      labels:
        app: network-fix
    spec:
      hostNetwork: true
      containers:
      - name: network-fix
        image: alpine
        command: ["/bin/sh", "-c"]
        args:
        - "ip route add 192.168.2.0/24 via 192.168.1.1"
        securityContext:
          privileged: true

apiVersion: v1
kind: Pod
metadata:
  name: network-test
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sh", "-c", "ping -c 4 192.168.2.10"]
  restartPolicy: Never

Çoklu-Subnet İletişim için K3S Ağı Optimize Etme

Önemli ama çoğu zaman gözden kaçan bir yönü K3S Networking kapsül ağı arayüzünün (CNI) POD bağlantısının yönetilmesinde rolüdür. Varsayılan olarak, K3S, ağ oluşturmayı basitleştiren ancak kutudan çıkmış gelişmiş yönlendirmeyi desteklemeyen CNI olarak pazen kullanır. POD'ların birincil alt ağının dışındaki kaynaklara erişmesi gereken durumlarda, pazelin patiska veya silium gibi daha zengin bir CNI ile değiştirilmesi ek esneklik ve özel yönlendirme seçenekleri sağlayabilir.

Bir diğer önemli faktör DNS çözünürlüğüdür. Yönlendirme düzgün bir şekilde yapılandırılmış olsa bile, POD'lar yanlış DNS ayarları nedeniyle harici hizmetlere bağlanmak için mücadele edebilir. Kubernetes genellikle harici ağlardan ana bilgisayar adlarını otomatik olarak çözemeyen Coredns'e dayanır. Özel DNS ayarlarını küme içinde yapılandırmak, diğer alt ağlardaki bakla ve makineler arasında sorunsuz iletişimi sağlamaya ve hem erişilebilirliği hem de performansı artırmaya yardımcı olabilir.

Güvenlik hususları da önemli bir rol oynamaktadır. POD erişimini yerel ağın ötesine genişletirken, hassas kaynakların ortaya çıkmasını önlemek için güvenlik duvarı kuralları ve ağ politikaları dikkatle ayarlanmalıdır. Kubernetes ağ politikalarının uygulanması, gerekli bağlantılara izin verirken gereksiz trafiği kısıtlayabilir. Örneğin, bir kapsül içinde çalışan bir web hizmetinin uzak bir veritabanına erişmesi gerekebilir, ancak tüm harici makinelere sınırsız erişime sahip olmamalıdır. Bu politikaları yönetmek, gerekli bağlantıyı korurken güvenliği etkin bir şekilde artırır. 🔐