86

I would like to deploy an application cluster by managing my deployment via k8s Deployment object. The documentation has me extremely confused. My basic layout has the following components that scale independently:

  1. API server
  2. UI server
  3. Redis cache
  4. Timer/Scheduled task server

Technically, all 4 above belong in separate pods that are scaled independently.

My questions are:

  1. Do I need to create pod.yml files and then somehow reference them in deployment.yml file or can a deployment file also embed pod definitions?
  2. K8s documentation seems to imply that the spec portion of Deployment is equivalent to defining one pod. Is that correct? What if I want to declaratively describe multi-pod deployments? Do I do need multiple deployment.yml files?
Oswin Noetzelmann
  • 9,166
  • 1
  • 33
  • 46
Raj
  • 2,852
  • 4
  • 29
  • 48
  • From my understanding, you cannot have different Pods in the same deployment. I was wondering how I could add 2 different Pods (1 container each) to the same Deployment. I don't think this is possible. – Ben Butterworth Aug 05 '22 at 16:04

3 Answers3

77

Pagid's answer has most of the basics. You should create 4 Deployments for your scenario. Each deployment will create a ReplicaSet that schedules and supervises the collection of Pods for the Deployment.

Each Deployment will most likely also require a Service in front of it for access. I usually create a single yaml file that has a Deployment and the corresponding Service in it. Here is an example for an nginx.yaml that I use:

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.alpha.kubernetes.io/tolerate-unready-endpoints: "true"
  name: nginx
  labels:
    app: nginx
spec:
  type: NodePort
  ports:
  - port: 80
    name: nginx
    targetPort: 80
    nodePort: 32756
  selector:
    app: nginx
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginxdeployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginxcontainer
        image: nginx:latest
        imagePullPolicy: Always
        ports:
        - containerPort: 80

Here some additional information for clarification:

  • A Pod is not a scalable unit. A Deployment that schedules pods is.
  • A Deployment is meant to represent a single group of pods fulfilling a single purpose together.
  • You can have many Deployments work together in the virtual network of the cluster.
  • For accessing a Deployment that may consist of many Pods running on different nodes you have to create a Service.
  • Deployments are meant to contain stateless services. If you need to store a state you need to create StatefulSet instead (e.g. for a database service).
crb
  • 8,132
  • 6
  • 37
  • 48
Oswin Noetzelmann
  • 9,166
  • 1
  • 33
  • 46
  • 1
    Thanks Oswin. Your syntax example combining `Deployment` and `Service` in one is extremely helpful! – Raj Apr 05 '17 at 06:20
  • 2
    i'm confused about the use of `port: 80` and also `nodePort: 32756` in the same service. Can you please explain why they are both needed? – AIon May 13 '17 at 17:58
  • 5
    The `port: 80` says that if you address the service as an entity, e.g. through the DNS entry for its name or the service IP, the port 80 will forward to the PODS supplying the actual service. `nodePort: 32xxx` says that if you address the cluster nodes, e.g. from the outside via a loadbalancer or node IP, the port 32xxx will forward to the PODS supplying the actual service. – Oswin Noetzelmann May 13 '17 at 19:11
  • 2
    I thought the point of a deployment was to monitor a group of pods? I don't understand why I need to create a deployment for each pod. – Matt Corby Nov 22 '17 at 20:07
  • How do you ensure multiple deployments/services get deployed together & come online together, and should one fail, that the other deployments don't deploy? – fionbio Jul 24 '18 at 12:50
  • @fionbio: Check out Readiness Probes: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes – Oswin Noetzelmann Jul 25 '18 at 20:39
  • @OswinNoetzelmann Thanks - I've taken this to mean that having multiple deployments in a file, or running apply against a directory of files, does not mean the whole operation is treated atomically, and some deployments may succeed and others may fail. True? – fionbio Jul 26 '18 at 06:37
  • 1
    @fionbio: Yes, you can influence what constitutes success with defining probes and there is no boundary on what you can come up with. You are free to create indirect dependencies between deployments and so on. So you should carefully design a solution for your domain that makes sense and is easy to use/upgrade. Complicated designs are easy - Simple is hard. – Oswin Noetzelmann Jul 27 '18 at 07:10
  • 1
    How do you connect the different deployments together? For instance if I have 2 deployments, one for node and one for postgres, how do I let node know how to connect to postgres? In docker-compose the name becomes the dns hostname, but I don't understand how that's accomplished across deployments. – Fmstrat May 09 '19 at 20:59
  • @Fmstrat : Typically service DNS is used. Please refer to the following link: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ – Oswin Noetzelmann May 10 '19 at 08:59
  • 1
    @OswinNoetzelmann Is there an example yaml that shows this working with Deployments instead of pods? – Fmstrat May 10 '19 at 13:47
21

You can use the Kubernetes API reference for the Deployment and you'll find that the spec->template field is of type PodTemplateSpec along with the related comment (Template describes the pods that will be created.) it answers you questions. A longer description can of course be found in the Deployment user guide.

To answer your questions...

1) The Pods are managed by the Deployment and defining them separately doesn't make sense as they are created on demand by the Deployment. Keep in mind that there might be more replicas of the same pod type.

2) For each of the applications in your list, you'd have to define one Deployment - which also makes sense when it comes to difference replica counts and application rollouts.

3) you haven't asked that but it's related - along with separate Deployments each of your applications will also need a dedicated Service so the others can access it.

pagid
  • 13,559
  • 11
  • 78
  • 104
  • 2
    Thanks @pagid. To be clear, while `spec` -> `template` is indeed a `PodTemplateSpec`, it is still the spec for a *single* pod. Is that right? – Raj Apr 04 '17 at 21:12
  • Also, regarding #1, I am sensing there are two options: 1) inline pod spec or 2) external reference via labels. For my initial project, for the sake of my sanity I'll stick to inline pod spec. – Raj Apr 04 '17 at 21:15
  • We'll a deployment can have a `replica` definition - therefore the `PodTemplateSpec` accounts for a group of Pods and the `replica` config, defines how big that group is. The external definition is something which I'm not able to "see" as an option when using the API definition along. – pagid Apr 05 '17 at 07:33
  • 2
    "it is still the spec for a single pod. Is that right?" YES, a single pod template spec that might cause multiple pods to be instantiated. – lucid_dreamer May 26 '19 at 20:29
  • do you recommend having seperate service for seperate deployments? I guess using same service and having different ports would be easy to maintain as there are small number of services right? This is just my assumption, please let me know if you have different thoughts on this. – Tushar Seth Oct 06 '19 at 11:56
  • One Service for multiple Deployments is the way which is nowadays used most often. – pagid Oct 25 '19 at 11:54
0

additional information:
API server use deployment
UI server use deployment
Redis cache use statefulset
Timer/Scheduled task server maybe use a statefulset (If your service has some state in)

Miffa Young
  • 107
  • 4