VPS-ல் Single-node k3s பயன்படுத்துவது நல்லதா?

k3s என்றால் என்ன, அதன் ஒரு node உங்களுக்கு என்ன வழங்குகிறது

k3s என்பது ஒரே binary-ஆக தொகுக்கப்பட்ட முழுமையான Kubernetes விநியோகம் ஆகும். இதை ஒரு VPS-ல் இயக்குவதன் மூலம், மூன்று இயந்திரங்களைக் கொண்ட control plane இல்லாமலேயே உண்மையான Kubernetes API-ஐப் பெற முடியும். இது ஒரு சான்றளிக்கப்பட்ட (certified) Kubernetes விநியோகம் என்பதால், இதில் பயன்படுத்தப்படும் manifest-களைப் பிற்காலத்தில் ஒரு நிர்வகிக்கப்படும் (managed) cluster-லும் பயன்படுத்தலாம். இதன் நிறுவல் ஒரே கட்டளையில், சுமார் ஒரு நிமிடத்தில் முடிந்துவிடும். இதற்கு நீங்கள் கொடுக்கும் விலை, உங்கள் applications-க்கு கிடைக்காத memory மற்றும் Docker Compose-ல் ஏற்படாத சில தோல்வி நிலைகள் (failure modes) ஆகும்.

SUSE நிறுவனம் k3s-ஐ edge தளங்கள் மற்றும் சிறிய நிறுவல்களுக்காக உருவாக்குகிறது. இதற்கும் upstream Kubernetes-க்கும் உள்ள ஒவ்வொரு வித்தியாசமும், இதை அளவில் சிறியதாக வைத்திருப்பதற்காகவே செய்யப்பட்டுள்ளது. இதன் இயல்புநிலை datastore, etcd-க்கு பதிலாக kine எனப்படும் shim மூலம் இயங்கும் sqlite ஆகும்; எனவே etcd quorum-ஐ பராமரிக்க வேண்டிய அவசியமில்லை. containerd தனியாக நிறுவப்படாமல், binary-க்குள்ளேயே உட்பொதிக்கப்பட்டுள்ளது (embedded). அதே binary-ல் cluster DNS-க்காக CoreDNS, ingress controller-ஆக Traefik, cloud provider இல்லாமலேயே LoadBalancer சேவைகள் செயல்பட ServiceLB (இது klipper-lb என்றும் அழைக்கப்படுகிறது), persistent volumes-க்காக local-path provisioner, metrics-server மற்றும் pod networking-க்காக flannel ஆகியவையும் வழங்கப்படுகின்றன. இவை அனைத்தும் இயல்பாகவே (default) தொடங்குகின்றன. இதனால்தான், ஏற்கனவே ஏதேனும் ஒரு பணியைச் செய்து கொண்டிருக்கும் VPS-ல், கீழே விவரிக்கப்பட்டுள்ள port collision மிக பொதுவான முதல் சிக்கலாக உள்ளது.

ஒரே k3s node எப்போது பயனுள்ளது

Kubernetes API உங்களுக்குத் தேவைப்படும்போது k3s-ஐப் பயன்படுத்துங்கள்: நீங்கள் உங்கள் கட்டுப்பாட்டில் உள்ள ஒரு கணினியில் Kubernetes-ஐக் கற்றுக்கொள்கிறீர்கள் அல்லது உங்களுக்குத் தேவையான மென்பொருள் Helm chart-ஆக மட்டுமே கிடைக்கிறது. Manifest-களின் portability-ம் முக்கியமானது, ஏனெனில் நீங்கள் இங்கே எழுதும் Deployment-ஐ மாற்றமின்றி ஒரு managed cluster-க்கு நகர்த்த முடியும். உங்களுக்குத் தேவையானவை applications மட்டுமே என்றால் Docker Compose-ஐப் பயன்படுத்துங்கள். Compose அதே containers-ஐ மிகக் குறைவான பாகங்களுடன் தொடங்குகிறது, மேலும் ஒரு VPS-ல் உள்ள Compose file ஒரு வருடம் கழித்துப் பார்க்கும்போது, manifest-கள் அடங்கிய கோப்புறையை விட எளிதாகப் புரியும்.

ஒரு node உங்களுக்கு எதைத் தராது என்பதில் தெளிவாக இருங்கள்.

• High availability கிடையாது. VPS reboot ஆகும்போது, அனைத்து workload-களும் நின்றுவிடும். Kubernetes ஒரு pod-ஐ மற்றொரு node-க்கு மாற்ற முயலும், ஆனால் அங்கே வேறு node இருக்காது.
• ஒரு service-ஐத் தொடர்ந்து இயங்க வைக்கும் rolling update வசதி கிடையாது, அந்த application ஒரே கணினியில் ஒரே volume-ஐப் பகிரும் இரண்டு replicas-ஐ ஆதரித்தால் ஒழிய.
• கீழே உள்ள local-path பகுதியில் விவரிக்கப்பட்டுள்ள காரணத்தால், storage அந்த box-உடன் மட்டுமே இணைக்கப்பட்டிருக்கும்.
• நீங்கள் எதையும் deploy செய்தாலும் செய்யாவிட்டாலும், control plane-க்கு சுமார் ஒரு gigabyte RAM தேவைப்படும்.

இவை எவையும் k3s-ஐ ஒரு மோசமான தேர்வாக மாற்றாது. மக்கள் பொதுவாகக் கூறும் காரணத்திற்காக இது ஒரு மோசமான தேர்வாகிறது, அதுதான் நம்பகத்தன்மை (reliability). உங்களுக்கு உண்மையில் பல கணினிகள் தேவைப்பட்டு, அதன் மூலம் ஒரு உண்மையான multi-node cluster-ஐ உருவாக்க விரும்பினால், அந்த முடிவே முதலில் வர வேண்டும்: உங்கள் சொந்த வன்பொருளில் Proxmox அல்லது வாடகை VPS என்பது, k3s-ல் என்ன இயங்க வேண்டும் என்பதைத் தீர்மானிக்கும் முன்பே, node-கள் எங்கிருந்து வருகின்றன என்பதைத் தீர்மானிக்கிறது.

எந்தவொரு பயன்பாட்டையும் நிறுவும் முன் k3s-க்குத் தேவைப்படும் RAM மற்றும் CPU அளவு

k3s திட்டம் மதிப்பீடுகளை விட அளவிடப்பட்ட புள்ளிவிவரங்களையே வெளியிடுகிறது. அவற்றை கவனமாகப் படிக்கவும், ஏனெனில் மக்கள் குறிப்பிடும் எண்ணிக்கை k3s-ன் idle பயன்பாடு அல்ல.

[
  {
    "label": "Server, sqlite datastore",
    "ram_mb": "1,596",
    "cpu_percent_of_one_core": 6
  },
  {
    "label": "Server, embedded etcd",
    "ram_mb": "1,606",
    "cpu_percent_of_one_core": 6
  },
  {
    "label": "Agent node only",
    "ram_mb": "275",
    "cpu_percent_of_one_core": 3
  }
]

அந்தச் சோதனையில் பயன்படுத்தப்பட்ட ஒரு server node, 95-வது percentile அளவில் 1,596 MB RAM-ஐயும், ஒரு core-ன் சுமார் 6 சதவீதத்தையும் பயன்படுத்தியது. இவை வெளியிடப்பட்ட புள்ளிவிவரங்களே தவிர, இந்த வழிகாட்டியில் இருந்து எடுக்கப்பட்ட அளவீடுகள் அல்ல. மேலும், அந்தச் சோதனையானது k3s v1.26.5 பதிப்பில், அனைத்து தொகுக்கப்பட்ட கூறுகளும் (packaged components) இயக்கப்பட்ட நிலையில், Prometheus மற்றும் Grafana monitoring stack-உடன் நடத்தப்பட்டது. எனவே, இந்த எண்ணிக்கை வெறும் காலியான cluster-ஐக் குறிக்காமல், ஒரு உண்மையான பணிச்சுமையையும் உள்ளடக்கியது. sqlite-க்கு பதிலாக embedded etcd-ஐப் பயன்படுத்தியபோது, அதன் அளவு 1,606 MB ஆக மாறியது. control plane இல்லாமல் kubelet மற்றும் containerd-ஐ மட்டும் இயக்கும் ஒரு agent node, 275 MB-ஐப் பயன்படுத்தியது. ஒரு server-க்கான குறைந்தபட்சத் தேவையாக 2 cores மற்றும் 2 GB RAM பரிந்துரைக்கப்படுகிறது; இந்த குறைந்தபட்ச அளவு உங்கள் பணிச்சுமைகளுக்கு முன்பாகவே k3s மற்றும் அதன் தொகுக்கப்பட்ட கூறுகளுக்குத் தேவைப்படுகிறது.

நடைமுறை விளக்கம்: 2 GB VPS-ல், control plane மற்றும் அதன் கூடுதல் அம்சங்கள் இயங்கிய பிறகு, உங்கள் பயன்பாட்டிற்கு மிகக் குறைந்த இடமே மிஞ்சும். அழுத்தம் ஏற்படும்போது முதலில் நடப்பது kubelet மூலம் pods வெளியேற்றப்படுவதுதான் (evicting). சில சிறிய சேவைகளைக் கொண்ட ஒரு node-க்கு 4 GB என்பது ஒரு வசதியான தொடக்க அளவு. எந்தவொரு வெளியிடப்பட்ட புள்ளிவிவரத்தையும், இதையும் சேர்த்து, அப்படியே நம்புவதற்குப் பதிலாக, உங்கள் சொந்த server-ல் அளவீடு செய்யுங்கள்.

free -h
sudo k3s kubectl top node
sudo k3s kubectl get pods -A

நீங்கள் நிறுவுவதற்கு முன்பும், kube-system-ல் உள்ள அனைத்து pods-ம் Running நிலைக்கு வந்த பிறகும் free -h-ஐ இயக்கவும். இந்த இரண்டிற்கும் உள்ள வித்தியாசமே உங்கள் hardware-ல் control plane-க்குத் தேவைப்படும் செலவாகும். நிறுவிய முதல் ஒன்று அல்லது இரண்டு நிமிடங்களுக்கு k3s kubectl top node கட்டளை error: Metrics API not available-ஐத் தரும், ஏனெனில் metrics-server இன்னும் எதையும் சேகரிக்கத் தொடங்கியிருக்காது. இது ஒரு பிழை அல்ல. இதற்கும் பிற பணிகளுக்கும் ஒரே server-ஐப் பயன்படுத்தத் திட்டமிட்டால், VPS-க்கான RAM மற்றும் CPU அளவீடு பகுதியில் உள்ள கணக்கீடுகள் இதற்கும் பொருந்தும்.

k3s-ஐ சமீபத்திய பதிப்பிற்குப் பதிலாக, ஒரு குறிப்பிட்ட பதிப்பிற்கு (pinned) நிறுவுதல்

அனைவரும் பயன்படுத்தும் quick start கட்டளை, நீங்கள் இயக்கும் நாளில் stable channel எதைக் குறிக்கிறதோ அதையே நிறுவும். நீண்ட காலம் பயன்படுத்தப்போகும் ஒரு கணினியில், பதிப்பை முன்கூட்டியே தீர்மானித்து (pin) நிறுவுவது நல்லது. k3s ஒவ்வொரு Kubernetes minor பதிப்பிற்கும் ஒரு channel-ஐ வழங்குகிறது. எனவே, INSTALL_K3S_CHANNEL=v1.36 என்பது v1.36-க்குள் வரும் patch பதிப்புகளை மட்டுமே பின்பற்றும்; தானாகவே அடுத்த minor பதிப்பிற்கு மாறாது. ஆகஸ்ட் 2026 நிலவரப்படி, stable channel v1.36.3+k3s1-ஐக் குறிக்கிறது.

முதலில் configuration கோப்பை உருவாக்கிவிட்டு, பிறகு நிறுவவும். k3s தொடங்கும்போதே /etc/rancher/k3s/config.yaml கோப்பை வாசிக்கும், எனவே அதில் உள்ளவை முதல் boot மற்றும் அதற்குப் பிந்தைய அனைத்து boot-களுக்கும் பொருந்தும்.

sudo mkdir -p /etc/rancher/k3s
sudo tee /etc/rancher/k3s/config.yaml >/dev/null <<'EOF'
tls-san:
  - k3s.example.com
EOF
curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=v1.36 sh -

ஒரு channel-க்கு பதிலாக ஒரு குறிப்பிட்ட பதிப்பை மட்டும் பயன்படுத்த, INSTALL_K3S_VERSION=v1.36.3+k3s1-ஐப் பயன்படுத்தவும். பிளஸ் (+) குறியீடு அந்த tag-ன் ஒரு பகுதி என்பதை நினைவில் கொள்ளவும். பிறகு, அது சரியாக இயங்குகிறதா என்று சரிபார்க்கவும்.

k3s --version
sudo systemctl status k3s
sudo k3s kubectl get node
sudo k3s kubectl get pods -A

kubectl get node கட்டளையை இயக்கினால், சுமார் முப்பது வினாடிகளுக்குள் Ready நிலையில் ஒரு node காட்டப்பட வேண்டும். மேலும், kube-system-ல் உள்ள அனைத்து pod-களும் Running அல்லது Completed நிலையை அடைய வேண்டும். ஒரு node NotReady நிலையிலேயே இருந்தால், container runtime தொடங்கவில்லை என்று பொருள்; எனவே sudo journalctl -u k3s -n 100 --no-pager-ஐப் படிக்கவும். வழக்கத்திற்கு மாறான VPS image-களில், எதையும் சரிபார்க்கும் முன் sudo k3s check-config-ஐ இயக்கவும்: இது விடுபட்ட kernel அம்சங்களைப் பட்டியலிடும். இது logs-ஐப் படிப்பதைக் காட்டிலும் விரைவான தீர்வாகும்.

Port 80 ஏற்கனவே பயன்பாட்டில் இருப்பதற்கான காரணம் மற்றும் அதைச் சரிசெய்யும் முறைகள்

ஏற்கனவே ஏதேனும் ஒரு சேவையை வழங்கி வரும் VPS-ல் இந்தத் தோல்வி பொதுவாக ஏற்படும். நிறுவல் (install) வெற்றிகரமாக முடிந்துவிடும். ஆனால், Traefik-க்கு எந்த முகவரியும் கிடைக்காது. நீங்கள் ஏற்கனவே இயக்கி வரும் தளம் தொடர்ந்து செயல்படுவதால், ingress-ஐ அணுக முயற்சிக்கும் வரை எதுவும் பழுதடைந்ததாகத் தெரியாது.

இதன் பின்னணியில் உள்ள நுட்பம்: தொகுக்கப்பட்ட Traefik chart, 80 மற்றும் 443 ஆகிய ports-ல் LoadBalancer வகை Service-ஐ உருவாக்குகிறது. ServiceLB, svclb- முன்னொட்டுடன் கூடிய சிறிய pods-ன் DaemonSet-ஐ உருவாக்குவதன் மூலம் அந்த கோரிக்கைக்குப் பதிலளிக்கிறது. இவை ஒவ்வொரு node-லும் அந்த port எண்களை hostPort-ஆகக் கோருகின்றன. hostPort, container port-ஐ நேரடியாக node-ன் network namespace-ல் வெளியிடுகிறது; இது சரியாக docker run -p 80:80 செய்வது போன்றது. nginx, Caddy, Apache அல்லது வேறு ஏதேனும் container ஏற்கனவே port 80-ஐப் பயன்படுத்திக் கொண்டிருந்தால், kernel அதை மீண்டும் வழங்காது. எனவே, அந்த pod-ஐ வைப்பதற்கு scheduler-க்கு இடம் இருக்காது.

sudo k3s kubectl -n kube-system get pods
sudo k3s kubectl -n kube-system get svc traefik
sudo ss -lntp '( sport = :80 or sport = :443 )'

svclb pod 'Pending' நிலையிலும், service எந்த external முகவரியும் இல்லாமலும் இருப்பதை நீங்கள் காண்பீர்கள்:

svclb-traefik-8f2c1a-r6k9x   0/2   Pending   0   3m
traefik   LoadBalancer   10.43.62.11   <pending>   80:31480/TCP,443:30219/TCP

kubectl -n kube-system describe pod svclb-traefik-...-ஐ இயக்குவது தோல்விக்கான காரணத்தை நேரடியாகக் காட்டும்:

0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports.

ss -lntp எந்த process அந்த port-ஐப் பிடித்துள்ளது என்பதை உங்களுக்குத் தெரிவிக்கும். இதிலிருந்து வெளியேற ஒன்றுக்கும் மேற்பட்ட வழிகள் உள்ளன, ஒவ்வொன்றிற்கும் ஒரு விலை உண்டு.

ports-ஐ k3s-க்கு வழங்குதல். ஏற்கனவே உள்ள web server-ஐ நிறுத்தி, disable செய்யவும். பின்னர் Traefik-ஐ 80 மற்றும் 443-ன் உரிமையாளராக மாற்றவும். VPS ஒரு k3s box-ஆக மட்டுமே செயல்படப் போகிறது மற்றும் நீங்கள் வழங்கிய அனைத்தும் Ingress-க்கு பின்னால் மாறுகிறது என்றால், இதுவே சரியான தீர்வாகும்.

ServiceLB-ஐ disable செய்துவிட்டு, ஏற்கனவே உள்ள proxy-ஐத் தொடருதல். --disable=servicelb மூலம் நிறுவவும். LoadBalancer வகை Service இன்னும் NodePort-ஐ ஒதுக்கும், எனவே Traefik 31480 போன்ற உயர் port-களில் அணுகக்கூடியதாக இருக்கும். உங்கள் nginx அல்லது Caddy, 127.0.0.1:31480-க்கு proxy செய்யும். நீங்கள் இழப்பது external முகவரி மட்டுமே: service எப்போதும் <pending> என்றே காட்டும். இது நீங்கள் எடுத்த முடிவு என்பதால், இது ஒரு பிழையல்ல.

Traefik-ஐ disable செய்துவிட்டு, உங்கள் சொந்த proxy மூலம் வழிநடத்துதல் (route). --disable=traefik மூலம் நிறுவவும். இப்போது உங்களிடம் ingress controller இருக்காது, எனவே Ingress objects எதையும் செய்யாது: அவை எந்த controller-ம் கவனிக்காத நிலையில் API-ல் இருக்கும். host proxy-லிருந்து NodePorts-க்கு வழிநடத்தும்போது இது சரியாக இருக்கும். HTTP-ஐ எவ்வாறு கையாள வேண்டும் என்று உங்களுக்கு ஏற்கனவே தெரிந்திருந்தால், இதுவே சரியான தேர்வாகும். எதை முன்னால் வைப்பது என்பதில் உங்களுக்குத் தெளிவு இல்லையென்றால், எதையும் disable செய்வதற்கு முன் reverse proxy-ஆக nginx, Caddy மற்றும் Traefik-க்கு இடையிலான தேர்வை முடிவு செய்யவும்.

இந்த இரண்டு flags-ம் installer-ல் அல்லது config கோப்பில் இருக்க வேண்டும்:

tls-san:
  - k3s.example.com
disable:
  - traefik
  - servicelb

நிறுவிய பின் அந்த கோப்பைத் திருத்தி sudo systemctl restart k3s-ஐ இயக்குவதும் வேலை செய்யும். ஏனெனில் --disable, நிறுவலின் போது ஒரு பகுதியைத் தவிர்ப்பதை விட அதிக வேலைகளைச் செய்கிறது. இது ஏற்கனவே deployed செய்யப்பட்ட ஒரு பகுதியை நீக்குகிறது, எனவே இந்த மாற்றம் இயங்கும் cluster-ல் உடனடியாகச் செயல்படும்.

Traefik-ஐ வைத்துக்கொண்டு, அதன் chart எவ்வாறு கட்டமைக்கப்பட்டுள்ளது என்பதை மாற்ற, /var/lib/rancher/k3s/server/manifests/traefik.yaml-ஐத் திருத்த வேண்டாம். k3s ஒவ்வொரு முறை தொடங்கும்போதும் அந்த கோப்பை default மதிப்புகளுடன் மீண்டும் எழுதும். அதற்குப் பதிலாக, அதே கோப்பகத்தில் ஒரு தனி கோப்பைச் சேர்க்கவும். ஏனெனில் /var/lib/rancher/k3s/server/manifests-ல் உள்ள அனைத்தும் தொடக்கத்தின் போதும், வட்டில் மாற்றம் ஏற்படும்போதும் தானாகவே பயன்படுத்தப்படும்.

apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: traefik
  namespace: kube-system
spec:
  valuesContent: |-
    ports:
      web:
        forwardedHeaders:
          trustedIPs:
            - 10.0.0.0/8

அந்த உதாரணம் ஒரு Traefik chart மதிப்பை, அதாவது trusted proxy முகவரிகளை அமைக்கிறது. அதே நுட்பத்தைப் பயன்படுத்தி, அதன் ports உட்பட chart வெளிப்படுத்தும் வேறு எந்த மதிப்பையும் அமைக்கலாம்.

ஒரு node-ல் நிரந்தர சேமிப்பகம் (Persistent storage)

k3s, local-path என்ற இயல்புநிலை StorageClass-ஐ வழங்குகிறது. இது Rancher-ன் local-path provisioner மூலம் இயங்குகிறது. storageClassName குறிப்பிடப்படாத எந்தவொரு PersistentVolumeClaim-ம் இதைப் பயன்படுத்தும். Volumes அனைத்தும் /var/lib/rancher/k3s/storage பாதையில், ஒவ்வொரு volume-க்கும் ஒரு subdirectory வீதம், அந்த node-ன் சொந்த வட்டில் (disk) சேமிக்கப்படும்.

sudo k3s kubectl get storageclass
sudo k3s kubectl get pvc -A
sudo ls -l /var/lib/rancher/k3s/storage

"Node-ன் சொந்த வட்டில்" சேமிக்கப்படுவதால் இரண்டு விளைவுகள் ஏற்படுகின்றன. இவை இப்போதைக்குத் தெரியாது, ஆனால் பிற்காலத்தில் சிக்கலை உண்டாக்கும்.

இந்த StorageClass volumeBindingMode: WaitForFirstConsumer-ஐப் பயன்படுத்துவதால், ஒரு pod அந்த volume-ஐ mount செய்யும் வரை புதிய PVC ஆனது Pending நிலையிலேயே இருக்கும். kubectl describe pvc கட்டளையை இயக்கினால் இதைக் காணலாம்:

waiting for first consumer to be created before binding

இது இயல்பானது. எனவே, ஒரு PVC-ஐ மட்டும் உருவாக்கிவிட்டு அது தயாராகும் வரை காத்திருந்தால், அது எப்போதும் Pending நிலையிலேயே இருக்கும்.

ஒருமுறை bound ஆன பிறகு, அந்த volume-ஐ உருவாக்கிய node-க்கு உரிய node affinity அதற்கு வழங்கப்படுகிறது. இதனால், அந்த volume-ஐப் பயன்படுத்தும் அனைத்து pod-களும் அந்த node-லேயே நிலைநிறுத்தப்படும். ஒரே ஒரு node இருக்கும்போது இது தெரியாது. பிற்காலத்தில் இரண்டாவது node-ஐச் சேர்க்கும்போது, pod நகர மறுப்பது scheduler-ன் பிழை போலத் தோன்றும். ஆனால் kubectl get pv -o yaml கட்டளையை இயக்கி, nodeAffinity பகுதியில் உள்ள hostname-ஐப் பார்த்தால் உண்மை புரியும்.

Backups எடுப்பது உங்கள் பொறுப்பு. VPS-ஐ மீண்டும் கட்டமைத்தால் (rebuild) அந்த directory அழிந்துவிடும்; கீழே உள்ள uninstall script-ஐ இயக்கினாலும் அது அழிந்துவிடும். /var/lib/rancher/k3s/storage பாதையை backup எடுக்கவும். மேலும், /var/lib/rancher/k3s/server/db/state.db பாதையில் உள்ள sqlite datastore-ஐ backup எடுக்கும்போது, service-ஐ நிறுத்திவிட்டு நகலெடுக்கவும், ஏனெனில் அது ஒரு live database. இதற்கு மாற்றாக, cluster-ஐத் தற்காலிகமானதாகக் கருதி, அனைத்து manifest-களையும் git-ல் பராமரிக்கலாம்.

Ingress மற்றும் TLS

Traefik-ஐ enabled நிலையில் வைத்திருந்தால், ஒரு standard Ingress object மட்டுமே போதுமானது.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt
spec:
  ingressClassName: traefik
  tls:
    - hosts:
        - hello.example.com
      secretName: hello-tls
  rules:
    - host: hello.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: hello
                port:
                  number: 80

Certificates தானாகவே உருவாகாது. இதற்கு பொதுவாக cert-manager பயன்படுத்தப்படுகிறது; இது அதன் published manifest மூலம் நிறுவப்பட வேண்டும், அதனுடன் ஒரு ClusterIssuer-ம் தேவை. ஆகஸ்ட் 2026 நிலவரப்படி, v1.21.1 பதிப்பு தற்போதைய பதிப்பாகும்.

sudo k3s kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.21.1/cert-manager.yaml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    email: you@example.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-account-key
    solvers:
      - http01:
          ingress:
            ingressClassName: traefik

HTTP-01 challenge என்பது ACME (automatic certificate management environment) server பொது இணையத்திலிருந்து http://hello.example.com/.well-known/acme-challenge/...-ஐத் தொடர்பு கொள்வதைக் குறிக்கிறது. எனவே, DNS A record ஏற்கனவே VPS-ஐச் சுட்டிக்காட்ட வேண்டும், மேலும் port 80 Traefik-ஐ அடைய வேண்டும். நீங்கள் ServiceLB-ஐ முடக்கிவிட்டு, உங்கள் சொந்த proxy-ஐ முன்னால் வைத்திருந்தால், அந்த proxy-யும் challenge path-ஐ forward செய்ய வேண்டும். இல்லையெனில், cert-manager கீழே உள்ளவாறு Challenge object-ல் நின்றுவிடும்:

Waiting for HTTP-01 challenge propagation: wrong status code '404', expected '200'

sudo k3s kubectl describe certificate hello-tls மற்றும் sudo k3s kubectl get order,challenge -A மூலம் issuance செயல்பாட்டைக் கண்காணிக்கவும்.

kubeconfig மற்றும் API server ஏன் தனிப்பட்டதாக (private) இருக்க வேண்டும்

k3s நிர்வாகி சான்றுகளை (admin credentials) /etc/rancher/k3s/k3s.yaml-ல் எழுதுகிறது. இந்த கோப்பு root பயனருக்குச் சொந்தமானது மற்றும் இயல்பாக 600 என்ற mode-ல் எழுதப்படுகிறது. இது cluster-admin உரிமைகளைக் கொண்ட client certificate-ஐக் கொண்டுள்ளதால், இதை வாசிக்கக்கூடிய எவரும் cluster-ஐக் கட்டுப்படுத்த முடியும்.

sudo k3s kubectl get node
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
kubectl get node

KUBECONFIG அமைக்கப்படாத நிலையில், தனியாக நிறுவப்பட்ட kubectl, The connection to the server localhost:8080 was refused - did you specify the right host or port? பிழையுடன் தோல்வியடையும். ஏனெனில், அது k3s-உடன் தொடர்பில்லாத இயல்புநிலை (default) அமைப்பைப் பயன்படுத்த முயல்கிறது. KUBECONFIG-ஐ அமைக்கவும் அல்லது sudo k3s kubectl-ஐப் பயன்படுத்தவும்; இது சரியான கோப்பைத் தானாகவே வாசிக்கும்.

ஒரு சாதாரண பயனர் kubectl-ஐ இயக்க, --write-kubeconfig-mode 644 பரிந்துரைக்கப்படுவதைக் காண்பீர்கள். அது என்ன செய்கிறது என்பதைப் புரிந்துகொள்ளுங்கள்: இது cluster-admin சான்றுகளை அந்த கணினியில் உள்ள அனைத்து உள்ளூர் கணக்குகளும் வாசிக்கும்படி மாற்றுகிறது. ஒரே ஒரு நிர்வாகி மட்டுமே உள்ள கணினியில் இது ஏற்றுக்கொள்ளத்தக்கதாக இருக்கலாம். ஆனால், பகிரப்பட்ட கணினியில் இது பாதுகாப்பானது அல்ல. கோப்பை நகலெடுப்பது, மற்றவர்களுக்குத் தெரியாமல் ஒரு பயனருக்கு மட்டும் அணுகலை வழங்குகிறது:

mkdir -p ~/.kube
sudo install -o $USER -g $USER -m 600 /etc/rancher/k3s/k3s.yaml ~/.kube/config

அந்தக் கோப்பில் உள்ள server: வரி https://127.0.0.1:6443 என்று இருக்கும். உங்கள் மடிக்கணினியிலிருந்து kubectl-ஐப் பயன்படுத்த, 6443 port-ஐ இணையத்திற்குத் திறக்க வேண்டாம். பொதுவெளியில் இருக்கும் Kubernetes API ஒரு இலக்காக மாறும்; இது வெளிப்படும்போது, சிறிய cluster-கள் மற்றவர்களுக்காக cryptocurrency mining செய்யப் பயன்படுத்தப்படலாம். SSH மூலம் tunnel செய்யவும், கோப்பில் உள்ள முகவரியை மாற்றாமல் அப்படியே விடவும்:

ssh -N -L 6443:127.0.0.1:6443 user@your-vps
KUBECONFIG=./k3s.yaml kubectl get node

நீங்கள் ஒரு private network முகவரி மூலம் API-ஐ அணுக வேண்டியிருந்தால், அந்தப் பெயர் அல்லது முகவரியைக் குறிப்பிட்டு tls-san மூலம் நிறுவவும். பின்னர், நகலெடுக்கப்பட்ட கோப்பின் server: வரியை அதற்கேற்ப மாற்றவும். SAN (subject alternative name) உள்ளீடு இல்லையெனில், kubectl இணைப்பை நிராகரிக்கும்:

x509: certificate is valid for 127.0.0.1, 10.43.0.1, not 203.0.113.10

ஒரு cluster-க்கான உள்வரும் (inbound) ports: API-க்காக TCP 6443, nodes-க்கு இடையே flannel VXLAN-க்காக UDP 8472, மற்றும் kubelet metrics-க்காக TCP 10250. ஒரே ஒரு node-ல் இயங்கும்போது, இவற்றில் எதையும் இணையத்திற்குத் திறக்க வேண்டிய அவசியமில்லை.

containerd என்பது Docker அல்ல

k3s அதன் சொந்த உட்பொதிக்கப்பட்ட (embedded) containerd-ஐ இயக்குகிறது. இது Docker-உடன் image store-ஐப் பகிர்ந்துகொள்வதில்லை. docker build மூலம் நீங்கள் உருவாக்கிய ஒரு image, k3s-க்குத் தெரியாது. எனவே, docker images கட்டளையில் அந்த image தெரிந்தாலும், pod ErrImagePull பிழையுடன் தோல்வியடையும். அதை நேரடியாக import செய்யவும்:

docker save myapp:0.1 | sudo k3s ctr images import -
sudo k3s crictl images

அதன்பிறகு, அந்த container-க்கு :latest tag-ஐப் பயன்படுத்துவதைத் தவிர்க்கவும். ஏனெனில், :latest இயல்பாகவே Always என்ற imagePullPolicy-ஐப் பயன்படுத்தும், இதனால் kubelet பதிவேட்டிற்கு (registry) சென்று தேடும். வேறு எந்த tag-ஐப் பயன்படுத்தினாலும் அது இயல்பாகவே IfNotPresent-க்கு மாறும், இது நீங்கள் import செய்த image-ஐப் பயன்படுத்தும். ஒரே VPS-ல் இரண்டையும் இயக்குவது சாத்தியம். VPS-ல் ஒரு சாதாரண Docker நிறுவல் மற்றும் k3s ஆகிய இரண்டும் ஒரே கணினியில் தத்தமது சொந்த image store மற்றும் iptables விதிகளைப் பராமரிக்கின்றன என்பதைப் புரிந்துகொள்வது அவசியம்.

k3s-ஐ அகற்றுவது எப்படி

installer ஒரு uninstall script-ஐ உருவாக்குகிறது. இதில் பகுதியளவு அகற்றுதல் (partial removal) அல்லது மாற்றங்களை மீளப்பெறுதல் (undo) செய்ய முடியாது.

sudo /usr/local/bin/k3s-uninstall.sh

இது service-ஐ நிறுத்தி நீக்குகிறது, datastore-ஐ அழிக்கிறது, persistent volume தரவுகளை நீக்குகிறது, node configuration-ஐ அகற்றுகிறது, மேலும் installer சேர்த்த கருவிகளையும் நீக்குகிறது. ஒரு agent node-ல், இந்த script-க்கு பதிலாக k3s-agent-uninstall.sh பயன்படுத்தப்படுகிறது. /var/lib/rancher/k3s/storage-ன் கீழ் உள்ள எதையும் முதலில் server-லிருந்து நகலெடுத்து வைத்துக்கொள்ளுங்கள், ஏனெனில் அந்த directory-யும் சேர்த்து நீக்கப்படும். அதன் பிறகு, ip link show மற்றும் sudo ss -lntp மூலம் எந்தவொரு port-ம் அல்லது interface-ம் பயன்பாட்டில் இல்லை என்பதை உறுதிப்படுத்தவும். எஞ்சியிருக்கும் cni0 அல்லது flannel.1 interface அடுத்த முறை reboot செய்யும்போது தானாகவே நீங்கிவிடும்.

Kubernetes-ன் ஒரு node என்பது தேவைக்கு அதிகமான கட்டமைப்பு என்று முடிவெடுப்பது தோல்வியல்ல, அது ஒரு இயல்பான முடிவுதான். அந்த workloads-ஐ மீண்டும் Compose-க்கு மாற்றுவதற்கு பொதுவாக ஒரு மதிய நேரம் போதுமானது.

தோல்வி முறைகள் மற்றும் நீங்கள் காணும் சரங்கள் (strings)

Node NotReady, அல்லது k3s மீண்டும் மீண்டும் restart ஆகுதல். முதலில் sudo journalctl -u k3s -n 200 --no-pager-ஐ வாசிக்கவும். சிறிய VPS-களில், kernel-ன் out-of-memory killer செயல்முறையை நிறுத்துவதே பொதுவான காரணமாகும்; இது dmesg-ல் k3s-server என்று பெயரிடப்பட்ட வரியாகத் தோன்றும். ஆவணப்படுத்தப்பட்ட 2 GB குறைந்தபட்ச அளவு என்பது ஒரு உண்மையான எல்லையாகும்.

Pod Pending நிலையில் சிக்கிக்கொள்ளுதல். kubectl describe pod ஒவ்வொரு முறையும் இதைக் குறிப்பிடும். Insufficient memory அல்லது Insufficient cpu என்பது node-ல் இடவசதி இல்லை என்று பொருள். didn't have free ports என்பது மேலே குறிப்பிடப்பட்ட hostPort மோதலாகும். PVC-ல் waiting for first consumer என்பது WaitForFirstConsumer அதன் பணியைச் செய்கிறது என்று பொருள்.

ImagePullBackOff. node அணுகக்கூடிய எந்த registry-யிலும் அந்த tag இல்லை, அல்லது நீங்கள் Docker மூலம் image-ஐ உருவாக்கி அதை containerd-க்குள் import செய்யவில்லை என்று பொருள்.

Traefik பதிலளிக்கிறது, ஆனால் app பதிலளிக்கவில்லை. 404 page not found என்ற response body Traefik-லிருந்து வருகிறது; அதாவது கோரிக்கை வந்துவிட்டது, ஆனால் எந்த router-உம் பொருந்தவில்லை என்று பொருள். Ingress host நீங்கள் உள்ளிட்ட பெயருடன் பொருந்துகிறதா என்பதையும், ingressClassName என்பது traefik ஆக உள்ளதா என்பதையும் சரிபார்க்கவும்.

Host-ல் DNS சரியாக வேலை செய்கிறது, ஆனால் Cluster DNS தோல்வியடைகிறது. sudo k3s kubectl -n kube-system logs -l k8s-app=kube-dns மூலம் CoreDNS-ஐச் சரிபார்க்கவும். plugin/loop: Loop ... detected for zone "." போன்ற செய்தி CoreDNS தொடங்குவதைத் தடுக்கிறது. CoreDNS ஒரு resolver-க்கு கோரிக்கையை அனுப்பி, அது மீண்டும் அதற்கே திருப்பி அனுப்பப்படுவதால் (loopback) இது நிகழ்கிறது; /etc/resolv.conf-ல் உள்ள loopback முகவரி இதற்குக் காரணமாகும். --resolv-conf /run/systemd/resolve/resolv.conf மூலம் k3s-ஐ உண்மையான upstream கோப்பிற்குச் சுட்டிக்காட்டவும்.

FAQ

ஒரே ஒரு VPS-ல் k3s-ஐ இயக்குவது பயனுள்ளதா?

Kubernetes API உங்களுக்குத் தேவைப்படும்போது இது பயனுள்ளது: உங்கள் கட்டுப்பாட்டில் உள்ள ஒரு கணினியில் அதைக் கற்றுக்கொள்வது, deployments-ஐ manifests ஆக போர்ட்டபிளாக வைத்திருப்பது, Helm chart மூலம் மட்டுமே வெளியிடப்படும் மென்பொருளை இயக்குவது அல்லது பிற்காலத்தில் managed cluster-க்கு மாற்றக்கூடிய ஒன்றை உருவாக்குவது போன்றவற்றுக்கு இது உதவும். உங்களுக்கு containers-ஐ இயக்க மட்டுமே தேவை என்றால், இது பயனுள்ளதல்ல; ஏனெனில் Docker Compose மூலம் பராமரிப்புச் செலவு மிகக் குறைவாகவும், சுமார் ஒரு ஜிகாபைட் கூடுதல் RAM கிடைக்கவும் வாய்ப்புள்ளது. ஒரு node மட்டுமே இருக்கும்போது high availability கிடைக்காது, எனவே நம்பகத்தன்மைக்காக இதைத் தேர்வு செய்யக்கூடாது.

எனது k3s LoadBalancer service ஏன் Pending நிலையிலேயே உள்ளது?

ServiceLB ஆனது svclb- pods-ஐ உருவாக்குகிறது, அவை node-ல் உள்ள service-ன் ports-ஐ hostPort ஆகக் கோருகின்றன. எனவே, அந்த ports காலியாக இருக்கும் இடங்களில் மட்டுமே அவை schedule செய்யப்படும். Nginx அல்லது வேறு ஏதேனும் proxy ஏற்கனவே port 80-ஐப் பயன்படுத்திக்கொண்டிருந்தால், pod Pending நிலையிலேயே இருக்கும் மற்றும் service-க்கு external address கிடைக்காது. kubectl -n kube-system describe pod svclb-... ஆனது 0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports என்று தெரிவிக்கும். அந்த port-ஐ விடுவிக்கவும், அல்லது --disable=servicelb உடன் மீண்டும் நிறுவி, service ஒதுக்கும் NodePort-க்கு proxy செய்யவும்.

ஒரு VPS-ல் k3s-க்கு எவ்வளவு RAM தேவை?

server node-க்கான குறைந்தபட்சத் தேவை 2 cores மற்றும் 2 GB ஆகும். இது உங்கள் workloads-க்கு முன்பாக k3s மற்றும் அதன் தொகுக்கப்பட்ட கூறுகளை உள்ளடக்கியது. இந்தத் திட்டத்தின் சொந்த profiling, ஒரு server node-ல் monitoring stack இயங்கும்போது 1,596 MB தேவைப்படுவதாகக் கணக்கிட்டுள்ளது. எனவே, 2 GB-ஐ அடிப்படைத் தேவையாகவும், 4 GB-ஐ ஒரு node வசதியாக இயங்குவதற்கான முதல் அளவாகவும் கருதுங்கள். நிறுவலுக்கு முன்பும், kube-system-ல் உள்ள அனைத்து pods-ம் Running நிலைக்கு வந்த பிறகும் free -h மூலம் உங்கள் கணினியின் அளவீட்டைச் சரிபார்க்கவும்.

ஒரே VPS-ல் Docker மற்றும் k3s-ஐ இயக்க முடியுமா?

ஆம், அவை தனித்தனியாகவே இருக்கும். k3s அதன் சொந்த embedded containerd-ஐப் பயன்படுத்துகிறது, எனவே docker build மூலம் உருவாக்கப்பட்ட image, நீங்கள் docker save myapp:0.1 | sudo k3s ctr images import --ஐ இயக்கும் வரை அதற்குத் தெரியாது. ஒவ்வொன்றும் அதன் சொந்த iptables விதிகள் மற்றும் bridge networks-ஐ எழுதும். நினைவகத்தின் மொத்த அளவைக் கவனியுங்கள், ஏனெனில் Docker, k3s மற்றும் உங்கள் containers ஆகியவை 2 GB கணினியில் பொருந்தாது.

k3s-ஐ முழுமையாக எப்படி நீக்குவது?

server node-ல் sudo /usr/local/bin/k3s-uninstall.sh-ஐயும், agent-ல் sudo /usr/local/bin/k3s-agent-uninstall.sh-ஐயும் இயக்கவும். இது service-ஐ நிறுத்தி, datastore-ஐ நீக்கி, /var/lib/rancher/k3s/storage-ன் கீழ் உள்ள persistent volume தரவுகளை அழித்து, தொகுக்கப்பட்ட கருவிகளை நீக்கும். நீங்கள் வைத்திருக்க விரும்பும் தரவுகளை முதலில் கணினியிலிருந்து நகலெடுத்துக்கொள்ளுங்கள், ஏனெனில் இதைத் திரும்பப் பெற முடியாது. எஞ்சியிருக்கும் cni0 அல்லது flannel.1 network interface அடுத்த reboot-ன் போது மறைந்துவிடும்.