Hello. Welcome to this Oracle Container Runtime for
Kata Deployment video. Here we will show how to deploy Kata containers
to worker nodes in your Oracle supported Kubernetes cluster.
In this video we will be looking at deploying single and multiple Kata container pods to
worker nodes. We will see how to create and delete the pods
and how to verify Kata containers were deployed on the nodes.
Controlling Kata container deployment with Kubernetes enhances your container and orchestration
environment for the delivery of microservices and next-generation application development.
After viewing this video you should be able to verify from the master node that the worker
nodes are configured to support Kata container deployment.
How to deploy a Kata container to a worker node using a deployment file.
How to deploy a replica set, to create multiple Kata container pods on multiple worker nodes.
CRI-O instructs for containers to be launched with either kata-runtime or runc.
This enables containers to be either launched as Kata container lightweight VMs or as other
non kata containers types. When setting up the pod or creating with a
deployment file, the annotation trusted or untrusted is used to define whether a container
will be a kata container other container type. Containers defined with untrusted are built
as kata containers using the kata-runtime. Containers defined with trusted are built
using the runc runtime. To start off, from the master node, lets use
the kubectl get nodes -o wide command to view details for the nodes in the cluster.
The –o wide option allows us to see which container runtime information is listed for
each node. Here we can see that for all three worker
nodes, we can see the names on the left under the column NAME.
All three have listed crio under the container runtime, which means all three have been configured
to use crio to determine how kata containers or containers will be run on those nodes.
So they are ready to support kata containers. Displaying crio in this column doesn't guarantee
that Kata containers will correctly be deployed. It is only that CRI-O and the Kubernetes services
on the worker nodes are configured to use CRI-O and to inform how containers are deployed.
Next, we will launch a Kata container pod to a single worker node.
We are using a preconfigured YAML file called untrusted-nginx.yaml, to deploy a single Kata
container pod on one node. We use command cat untrusted-nginx.yaml to
view the file. Using the annotation io.kubernetes.cri-o.TrustedSandbox:
"false" indicates to the worker node that the container is to be launched using kata-runtime
instead of runc. Now we run kubectl create –f and the filename
command to use the YAML file to deploy the container pod on a worker node.
And here we can see the pod is created. And in order to see the status of the pod
we use the kubectl get pods. And we can see that under the name we have
the name of our pod untrusted-nginx, and under status we have running.
Use the kubectl describe pods command to see more details of the deployed pod.
And if I go up to the top here is were we typed in our command.
And looking at the information we can see the name of our pod, we can see the node that
the pod was deployed to, in this case mo-worker02, we can see the status is running.
And here we can see that using this crio indicator for container id, tells us that it was launched
as a kata container. Down the bottom here we can see the events,
which give us information about the setup of this pod.
And to delete the pod we use the kubectl delete pod and the pod name command.
And this can take a few seconds or a few minutes depending on your cluster.
Now, there we have it our pod is deleted. Now we will deploy a replica set of kata containers
to all three worker nodes. To start lets clear some space.
This time we will use a file called untrusted-nginx-multi.yaml. So lets have a look at this with the cat command.
And here we can see like before, the trusted sandbox annotation is false, indicating that
we want a kata container created. And down here we can see under the spec section,
replicas is three. So this is the indicator that we want three
copies or a replica set of three pods, one across each node.
Lets go ahead and create this replica set of pods.
We are using the same command as before, kubectl create -f and then the name of the yaml file
to be used. And now we can see that they have been created,
and you will note that it says deployment instead of pods on the left side.
And again we can use the kubectl get pods command to show the pods that have been created.
And we can see that there now three pods created, and all three are running under the status
column. To get details of the pods we use the kubectl
describe pods command again. And this will give us an output listing all
three pods in turn. So lets scroll back up to where it starts.
And here's where we use the command so we start looking at it from here.
We can see the first one, here's the name of it, untrusted-nginx-multi.
We can see that this pod has been created on mo-worker01.
Its running, and in the Controlled By section we can see that it is part of a replica set.
Its a kata container as we can see beside container id crio.
And if we scroll down past the events section, we now get to see the second pod.
Here we can see untrusted-nginx-multi again. This time this pod has been created on worker03,
its running and we can see that its part of the replica set.
And again, its a kata container because the container id indicates crio.
Scroll down even further to the third pod, and here we can see again the name and this
third one has been created on the node mo-worker02. Again it's running, and part of the replica
set. A kata container has been created, the container
id indicates crio, and thats all three pods created, one on each of the worker nodes.
In order to delete these pods, where before when we created a single pod we used the command
kubectl delete pod, this time we need to use the command kubectl delete deployment to get
rid of all three. And we need to give the name of the deployment.
And after a few seconds we can see that the deployment has been deleted.
We can check that by using the kubectl get pods command.
And with no resources found all the pods are now deleted.
Oracle provides an extensive number of resources which you can use to find out more about this
subject and others. For further information about Kubernetes and
CRI-O, you can visit their Open Source Project sites at the links shown here.
Extensive training videos, content and solutions covering Cloud related topics like Kubernetes
as well as administrative and advanced subjects for Oracle Linux can be found in the Linux
Learning Subscription and Oracle Linux curriculum path.
In this video, you learned about how to verify from the master node that the worker nodes
are configured to support Kata container deployment. You saw how to deploy a Kata container to
a worker node using a deployment file. You saw how to deploy a replica set, to create
multiple Kata container pods on multiple worker nodes.
That's the end of this video, Thanks for watching.