There are two ways to set up your k8s cluster up and running, declarative and imperative. In this blog, we are focusing on how to using YAML file to set up k8s containers declaratively. And for imperatively we do it through
kubectl in next blog.
YAML is a human-readable text-based format for specifying configuration-type information. YAML is a superset of JSON, which means that any valid JSON file is also a valid YAML file. In the context of k8s, we mainly use two data structures of YAML: list and map.
YAML lists are literally a sequence of objects. For example:
- containerPort: 5432//in json
}YAML map (map the key-value pairs)apiVersion: apps/v1
Kubernetes objects are persistent entities in the Kubernetes system. Specifically, they can describe:
- What containerized applications are running (and on which nodes)
- The resources available to those applications
- The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
Object Spec and Status
Almost every Kubernetes object includes two nested object fields that govern the object’s configuration: the object
spec and the object
status. For objects that have a
spec, you have to set this when you create the object. The
status describes the current state of the object, supplied and updated by the Kubernetes and its components. The Kubernetes control plane continually and actively manages every object’s actual state to match the desired state you supplied.
.yaml file for the Kubernetes object you want to create, you’ll need to set values for the following fields:
apiVersion- Which version of the Kubernetes API you’re using to create this object
kind- What kind of object you want to create
metadata- Data that helps uniquely identify the object, including a
UID, and optional
spec- What state you desire for the object.
Pod, Deployment and Service
- A Pod is the most basic unit that Kubernetes deals with. It wraps containers inside it. Containers inside a pod containers share a life cycle, and their environment, volumes, and IP space. Usually, pods consist of a primary container and optionally some support containers.
- A Deployment is an object that lets you manage a set of identical pods using Replication sets. It eases the life cycle management of replicated pods. Deployments can be modified easily by changing the configuration and Kubernetes will adjust accordingly.
- a Service defines a logical set of Pods and a policy by which to access them. A service’s IP address remains stable regardless of changes to the pods it routes to. Any time you need to provide access to one or more pods to another application or to external consumers, you should configure a service. Although services, by default, are only available using an internally routable IP address, they can be made available outside of the cluster by choosing one of several strategies.
A Pod is the smallest unit of work which can be scheduled in Kubernetes. A Pod encapsulates an application containers, storage resources, unique network IP. Normally, higher level abstractions are used to deploy pods such as Deployments, Replica Sets, Daemon Sets, Stateful Sets, or Jobs.
Now let’s use some examples to look into how these objects work.
- name: client
- containerPort: 3000//client-deployment.yml
- name: client
- containerPort: 3000//client-node-port.yml
- port: 3050
There are some keys worth mentioning from above:
- apiVersion:Which version of the Kubernetes API you’re using to create this object.
- Metadata: The metadata contains information of the object. The information in the metadata usually contains the name you want to give the object , the labels, and the annotation.
- Spec: is about the desired status of our object.
- Container: Here you specify:the name of the container that you’ll run in your pod (
clientin our first example); the image of the application you want to run in your pods (
elfiy/multi-worker); the containerPort is the port your application in your container is listening to (
You may notice there are some differences in each object, for example in Deployment yml, we have something extra:
- Replicas sets the number of instances of the pod that the deployment should run.
- Label selector is to match the pods to the deployment. This is equivalent of “all the pods matching these labels are included in the deployment.” (in our case it’s the pod with name “
- Template is added by the deployment controller to every ReplicaSet that a Deployment creates or adopts. It is just a pod spec. When the deployment creates pods, it will create them using this template.
Lastly on the Service object, notice the 3 different ports:
- ClusterIP (default) — Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster. There may be other pods that need access to this pod.(
- NodePort — Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using
31515) Note that if we go to localhost:31515 we won’t get anything. Since k8s has a VM and we need the IP assigns to this VM instead using
192.168.64.2So visit to go to http://192.168.64.2/31515
- TargetPort — This is the port on the pod that the request gets sent to. (
- Additionally, note that there are some use cases with Services that involve not defining
selectorin the spec. A Service created without
selectorwill also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Apart from these ports, there’s also Loadbalancer port and Ingress which we will touch later.
Cool. That’s so much of it! Happy Reading!
🛥 🚤 ⛴ 🛳 ⛵ ⚓️ 🌊🛥 🚤 ⛴ 🛳 ⛵ ⚓️ 🌊🛥 🚤 ⛴ 🛳 ⛵ ⚓️ 🌊🛥 🚤 ⛴ 🛳 ⛵ ⚓️ 🌊🛥 🚤 ⛴ 🛳 ⛵ ⚓️ 🌊🛥 🚤 ⛴ 🛳 ⛵ ⚓️ 🌊🛥 🚤 ⛴ 🛳 ⛵ ⚓️ 🌊🚤