พ็อด การติดตั้งใช้งาน และบริการสำหรับโมเดล

Kubernetes never runs a bare container. The smallest thing it schedules is a Pod, a wrapper holding one container (your model server) plus its shared network. 📦

For ML serving you usually put one model API container in each Pod. That keeps scaling, restarts, and resource limits simple to reason about per model.

A Pod can die at any moment, on a node failure or an upgrade. You never name or nurse one; you let the cluster replace it for you.

A Deployment is the controller you actually create. It says how many identical model Pods you want and rebuilds any that crash or vanish.

Set replicas to 3 and you instantly run three copies of your model server. Bump the number and Kubernetes spins up more to share the load.

Inside a Deployment, the template is the blueprint for every Pod: which image to pull, what port the model API listens on, and its resource needs.

Ship a new model image and the Deployment does a rolling update, replacing old Pods a few at a time so predictions keep flowing with no downtime.

Every new Pod gets a fresh internal IP. Clients cannot chase moving targets, so you need a stable front door that does not change. 🔀

A Service gives your model Pods one steady name and virtual IP, then load-balances requests across whichever replicas are currently healthy.

A Service finds its Pods by matching labels, not IPs. The selector app=model-api links the Service to every Pod carrying that same label.

A ClusterIP Service is reachable only inside the cluster, fine for internal calls. Use LoadBalancer or an Ingress when external users need the model.

Which object should you create to run and self-heal model Pods?

Pods run your model, a Deployment keeps the right number alive, and a Service gives clients one stable address. That trio is the core of serving on Kubernetes. ✅