Pods
- Let's assume that the following have been set up already:
- The application is already developed and built into Docker images and it is available on a Docker repository like Docker Hub so Kubernetes can pull it down
- Kubernetes cluster has already been set up and is working
- this could be a single node setup or a multi node setup
- all the services need to be in a running state
- With Kubernetes, our ultimate aim is to deploy our application in the form of containers on a set of machines that are configured as worker nodes in a cluster
- Kubernetes does not deploy containers directly on the worker nodes. The containers are encapsulated into a Kubernetes object known as pods.
- A pod is:
- a single instance of an application
- the smallest object that you can create in Kubernetes
- the most basic and the smallest unit in Kubernetes
- The simplest case: a single node Kubernetes cluster with a single instance of the application running in a single Docker container encapsulated in a pod
- What if the number of users accessing your application increase and you need to scale your application?
- We need to add additional instances of your web application to share the load.
- Where would we spin up additional instances?
- We don't bring up new container instance within the same pod.
- We create new pod altogether with a new instance of the same application.
- We now have two instances of our web application running on two separate pods on the same Kubernetes system or node.
- What if the user base further increases and your current node has no sufficient capacity?
- We can always deploy additional pods on a new node in the cluster
- We will have a new node added to the cluster to expand the cluster's physical capacity
- Pods usually have a 1 to 1 relationship with containers running our application.
- To scale up, we create new pods
- To scale down we delete existing pods
- We do NOT add additional containers to an existing pod to scale our application.
- We can also achieve load balancing between the containers.
Multi-container pods
Pods usually have a 1 to 1 relationship with the containers, but we are NOT restricted to having a single container in a single pod. A single pod can have multiple containers except for the fact that they're usually not multiple containers of the same kind.To scale our application, we would need to create additional pods.
Sometimes we might have a scenario where we have a helper container that might be doing some kind of supporting task for our web application, such as processing a user entered data, processing a file uploaded by the user etc and we want these helper containers to live alongside our application container. In that case, we can have both of these containers part of the same pod so that:
- when a new application container is created, the helper is also created
- when it dies, the helper also dies since they are part of the same pod
- The two containers can also communicate with each other directly by referring to each other as local host since they share the same network space
- They can easily share the same storage space as well
My observation: Kubernetes pods seem to be doing a job very similar to docker-compose. What are the similarities and what are the differences between two?
How to deploy/create pods?
kubectl run command
How do we see the list of pods available?
- e.g. kubectl run nginx
- deploys a Docker container by creating a pod named nginx
- it first creates a pod automatically
- then deploys an instance of the Nginx Docker image
- we need to specify the application image name using the image parameter:
- kubectl run nginx --image nginx
- The application image, in this case, the nginx image is downloaded from the Docker Hub Repository. Docker Hub is a public repository where latest Docker images of various applications are stored.
- We can configure Kubernetes to pull the image from the public Docker hub or a private repository within the organization.
- in the current state, we haven't made the web server accessible to external users but we can access it internally from the node
$ kubectl run --help
Create and run a particular image in a pod.
Examples:
# Start a nginx pod
kubectl run nginx --image=nginx
# Start a hazelcast pod and let the container expose port 5701
kubectl run hazelcast --image=hazelcast/hazelcast --port=5701
# Start a hazelcast pod and set environment variables "DNS_DOMAIN=cluster" and
"POD_NAMESPACE=default" in the container
kubectl run hazelcast --image=hazelcast/hazelcast --env="DNS_DOMAIN=cluster"
--env="POD_NAMESPACE=default"
# Start a hazelcast pod and set labels "app=hazelcast" and "env=prod" in the container
kubectl run hazelcast --image=hazelcast/hazelcast --labels="app=hazelcast,env=prod"
# Dry run; print the corresponding API objects without creating them
kubectl run nginx --image=nginx --dry-run=client
# Start a nginx pod, but overload the spec with a partial set of values parsed from JSON
kubectl run nginx --image=nginx --overrides='{ "apiVersion": "v1", "spec": { ... } }'
# Start a busybox pod and keep it in the foreground, don't restart it if it exits
kubectl run -i -t busybox --image=busybox --restart=Never
# Start the nginx pod using the default command, but use custom arguments (arg1 .. argN) for that
command
kubectl run nginx --image=nginx -- <arg1> <arg2> ... <argN>
# Start the nginx pod using a different command and custom arguments
kubectl run nginx --image=nginx --command -- <cmd> <arg1> ... <argN>
Options:
--allow-missing-template-keys=true:
If true, ignore any errors in templates when a field or map key is missing in the
template. Only applies to golang and jsonpath output formats.
--annotations=[]:
Annotations to apply to the pod.
--attach=false:
If true, wait for the Pod to start running, and then attach to the Pod as if 'kubectl
attach ...' were called. Default false, unless '-i/--stdin' is set, in which case the
default is true. With '--restart=Never' the exit code of the container process is
returned.
--command=false:
If true and extra arguments are present, use them as the 'command' field in the container,
rather than the 'args' field which is the default.
--dry-run='none':
Must be "none", "server", or "client". If client strategy, only print the object that
would be sent, without sending it. If server strategy, submit server-side request without
persisting the resource.
--env=[]:
Environment variables to set in the container.
--expose=false:
If true, create a ClusterIP service associated with the pod. Requires `--port`.
--field-manager='kubectl-run':
Name of the manager used to track field ownership.
--image='':
The image for the container to run.
--image-pull-policy='':
The image pull policy for the container. If left empty, this value will not be specified
by the client and defaulted by the server.
-l, --labels='':
Comma separated labels to apply to the pod. Will override previous values.
--leave-stdin-open=false:
If the pod is started in interactive mode or with stdin, leave stdin open after the first
attach completes. By default, stdin will be closed after the first attach completes.
-o, --output='':
Output format. One of: (json, yaml, name, go-template, go-template-file, template,
templatefile, jsonpath, jsonpath-as-json, jsonpath-file).
--override-type='merge':
The method used to override the generated object: json, merge, or strategic.
--overrides='':
An inline JSON override for the generated object. If this is non-empty, it is used to
override the generated object. Requires that the object supply a valid apiVersion field.
--pod-running-timeout=1m0s:
The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod
is running
--port='':
The port that this container exposes.
--privileged=false:
If true, run the container in privileged mode.
-q, --quiet=false:
If true, suppress prompt messages.
--restart='Always':
The restart policy for this Pod. Legal values [Always, OnFailure, Never].
--rm=false:
If true, delete the pod after it exits. Only valid when attaching to the container, e.g.
with '--attach' or with '-i/--stdin'.
--save-config=false:
If true, the configuration of current object will be saved in its annotation. Otherwise,
the annotation will be unchanged. This flag is useful when you want to perform kubectl
apply on this object in the future.
--show-managed-fields=false:
If true, keep the managedFields when printing objects in JSON or YAML format.
-i, --stdin=false:
Keep stdin open on the container in the pod, even if nothing is attached.
--template='':
Template string or path to template file to use when -o=go-template, -o=go-template-file.
The template format is golang templates
[http://golang.org/pkg/text/template/#pkg-overview].
-t, --tty=false:
Allocate a TTY for the container in the pod.
Usage:
kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client]
[--overrides=inline-json] [--command] -- [COMMAND] [args...] [options]
Use "kubectl options" for a list of global command-line options (applies to all commands).
kubectl get pods command:
- lists all pods in our cluster
- also shows their current state e.g. pod can be in ContainerCreating state and soon changes to a Running state when it is actually running
$ kubectl get --help
Display one or many resources.
Prints a table of the most important information about the specified resources. You can filter the
list using a label selector and the --selector flag. If the desired resource type is namespaced you
will only see results in your current namespace unless you pass --all-namespaces.
By specifying the output as 'template' and providing a Go template as the value of the --template
flag, you can filter the attributes of the fetched resources.
Use "kubectl api-resources" for a complete list of supported resources.
Examples:
# List all pods in ps output format
kubectl get pods
# List all pods in ps output format with more information (such as node name)
kubectl get pods -o wide
# List a single replication controller with specified NAME in ps output format
kubectl get replicationcontroller web
# List deployments in JSON output format, in the "v1" version of the "apps" API group
kubectl get deployments.v1.apps -o json
# List a single pod in JSON output format
kubectl get -o json pod web-pod-13je7
# List a pod identified by type and name specified in "pod.yaml" in JSON output format
kubectl get -f pod.yaml -o json
# List resources from a directory with kustomization.yaml - e.g. dir/kustomization.yaml
kubectl get -k dir/
# Return only the phase value of the specified pod
kubectl get -o template pod/web-pod-13je7 --template={{.status.phase}}
# List resource information in custom columns
kubectl get pod test-pod -o
custom-columns=CONTAINER:.spec.containers[0].name,IMAGE:.spec.containers[0].image
# List all replication controllers and services together in ps output format
kubectl get rc,services
# List one or more resources by their type and names
kubectl get rc/web service/frontend pods/web-pod-13je7
# List the 'status' subresource for a single pod
kubectl get pod web-pod-13je7 --subresource status
Options:
-A, --all-namespaces=false:
If present, list the requested object(s) across all namespaces. Namespace in current
context is ignored even if specified with --namespace.
--allow-missing-template-keys=true:
If true, ignore any errors in templates when a field or map key is missing in the
template. Only applies to golang and jsonpath output formats.
--chunk-size=500:
Return large lists in chunks rather than all at once. Pass 0 to disable. This flag is beta
and may change in the future.
--field-selector='':
Selector (field query) to filter on, supports '=', '==', and '!='.(e.g. --field-selector
key1=value1,key2=value2). The server only supports a limited number of field queries per
type.
-f, --filename=[]:
Filename, directory, or URL to files identifying the resource to get from a server.
--ignore-not-found=false:
If the requested object does not exist the command will return exit code 0.
-k, --kustomize='':
Process the kustomization directory. This flag can't be used together with -f or -R.
-L, --label-columns=[]:
Accepts a comma separated list of labels that are going to be presented as columns. Names
are case-sensitive. You can also use multiple flag options like -L label1 -L label2...
--no-headers=false:
When using the default or custom-column output format, don't print headers (default print
headers).
-o, --output='':
Output format. One of: (json, yaml, name, go-template, go-template-file, template,
templatefile, jsonpath, jsonpath-as-json, jsonpath-file, custom-columns,
custom-columns-file, wide). See custom columns
[https://kubernetes.io/docs/reference/kubectl/#custom-columns], golang template
[http://golang.org/pkg/text/template/#pkg-overview] and jsonpath template
[https://kubernetes.io/docs/reference/kubectl/jsonpath/].
--output-watch-events=false:
Output watch event objects when --watch or --watch-only is used. Existing objects are
output as initial ADDED events.
--raw='':
Raw URI to request from the server. Uses the transport specified by the kubeconfig file.
-R, --recursive=false:
Process the directory used in -f, --filename recursively. Useful when you want to manage
related manifests organized within the same directory.
-l, --selector='':
Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l
key1=value1,key2=value2). Matching objects must satisfy all of the specified label
constraints.
--server-print=true:
If true, have the server return the appropriate table output. Supports extension APIs and
CRDs.
--show-kind=false:
If present, list the resource type for the requested object(s).
--show-labels=false:
When printing, show all labels as the last column (default hide labels column)
--show-managed-fields=false:
If true, keep the managedFields when printing objects in JSON or YAML format.
--sort-by='':
If non-empty, sort list types using this field specification. The field specification is
expressed as a JSONPath expression (e.g. '{.metadata.name}'). The field in the API
resource specified by this JSONPath expression must be an integer or a string.
--subresource='':
If specified, gets the subresource of the requested object. Must be one of [status scale].
This flag is beta and may change in the future.
--template='':
Template string or path to template file to use when -o=go-template, -o=go-template-file.
The template format is golang templates
[http://golang.org/pkg/text/template/#pkg-overview].
-w, --watch=false:
After listing/getting the requested object, watch for changes.
--watch-only=false:
Watch for changes to the requested object(s), without listing/getting first.
Usage:
kubectl get
[(-o|--output=)json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file|custom-columns|custom-columns-file|wide]
(TYPE[.VERSION][.GROUP] [NAME | -l label] | TYPE[.VERSION][.GROUP]/NAME ...) [flags] [options]
Use "kubectl options" for a list of global command-line options (applies to all commands).
We've now learned about the tool we'll be using to communicate with our cluster but how to create the Kubernetes cluster, which tools can we use? I'm covering that in the next article in this series: An overview of Kubernetes Distributions | My Public Notepad
No comments:
Post a Comment