The title was initially 'Bring Back the Node', but I didn't think people would get the reference. Applause if you did!
Making a deployment in the previous post made a POD for our application to be hosted in.
($POD_NAME variable)
Pods are an abstraction that represent 1 or more containers and shared resources for them, like Volumes, what the page describes as
and instructions on how to actually run the containers.
A Pod can hold the application and something that is closely coupled to it. The example given is a Node.js app and the data to be read by it.
Pods hold containers, and the containers share an IP address / Port space
Are co-located and scheduled, and
Run in a shared context on the same Node.
When we create a Deployment, that Deployment creates Pods with Containers inside of them.
The hierarchy reminds me a bit of Forests/Trees. Or Matryoshka dolls.
Pods run on Nodes, a virtual or physical worker machine in Kubernetes, and is managed by the Master.
Nodes = Multiple pods, Master schedules pods automatically across Nodes in the cluster.
Every Node runs at least a Kubelet and a container runtime, that pulls the container image from a registry, unpackets it, and runs it.
I’m just going to link to the image they provide. It looks like a cell.
So;
* Nodes hold pods and pods hold volumes and containerized apps.
* and there are some processes on the node.
Let’s troubleshoot with kubectl.
The syntax is kubectl [action]
- get [resource]; Lists resources
- describe; Show details about a resource
- logs; Print logs from a container
- exec; Execute a command on a podded container.
And those are what we’re going to be using in today’s tutorial!
Just putting in kubectl get with no specifics lists a lot of things.
adding pods gives us just the one.
But what’s in our pod? Describe it.
That’s not even all of the information!
Time to debug through a proxy in another terminal window.
We’re going to store this into the POD_NAME variable.
the curl request shows the output
{curl http://localhost:8001/api/vi/namespaces/default/pods/$POD_NAME/proxy}
The very long Pod name is in that variable, we don’t have to type it out, just $POD_NAME. Nice.
If there was more than one Pod, it wouldn't work.
What about our container logs? Let’s use
kubectl logs $POD_NAME
Cool, now let’s execute a command.
The pod should be up and running, and we use the exec variable instead of get.
(env = enviroment variables, I think. I looked it up.)
(using SSL port 443)
Let’s start a bash in the Pod container with kubectl exec -ti $POD_NAME bash
Oh, we’ve moved to the root of our container! See the prompt over there?
Now we can run the application with cat [where the source code is stored].
And check it again with a curl command. Close the container with an exit command.
Making a deployment in the previous post made a POD for our application to be hosted in.
($POD_NAME variable)
Pods are an abstraction that represent 1 or more containers and shared resources for them, like Volumes, what the page describes as
‘Networking, as a unique cluster IP address’ (Sounds exciting, like a distant relative of subnetting or vlans)
and instructions on how to actually run the containers.
A Pod can hold the application and something that is closely coupled to it. The example given is a Node.js app and the data to be read by it.
Pods hold containers, and the containers share an IP address / Port space
Are co-located and scheduled, and
Run in a shared context on the same Node.
When we create a Deployment, that Deployment creates Pods with Containers inside of them.
The hierarchy reminds me a bit of Forests/Trees. Or Matryoshka dolls.
Pods run on Nodes, a virtual or physical worker machine in Kubernetes, and is managed by the Master.
Nodes = Multiple pods, Master schedules pods automatically across Nodes in the cluster.
Every Node runs at least a Kubelet and a container runtime, that pulls the container image from a registry, unpackets it, and runs it.
I’m just going to link to the image they provide. It looks like a cell.
So;
* Nodes hold pods and pods hold volumes and containerized apps.
* and there are some processes on the node.
Let’s troubleshoot with kubectl.
The syntax is kubectl [action]
- get [resource]; Lists resources
- describe; Show details about a resource
- logs; Print logs from a container
- exec; Execute a command on a podded container.
And those are what we’re going to be using in today’s tutorial!
Just putting in kubectl get with no specifics lists a lot of things.
Whoa nelly.
But what’s in our pod? Describe it.
That’s not even all of the information!
Time to debug through a proxy in another terminal window.
We’re going to store this into the POD_NAME variable.
the curl request shows the output
{curl http://localhost:8001/api/vi/namespaces/default/pods/$POD_NAME/proxy}
The very long Pod name is in that variable, we don’t have to type it out, just $POD_NAME. Nice.
If there was more than one Pod, it wouldn't work.
What about our container logs? Let’s use
kubectl logs $POD_NAME
"Where are you running? WHERE are you running?"
The pod should be up and running, and we use the exec variable instead of get.
(env = enviroment variables, I think. I looked it up.)
(using SSL port 443)
Let’s start a bash in the Pod container with kubectl exec -ti $POD_NAME bash
Oh, we’ve moved to the root of our container! See the prompt over there?
Now we can run the application with cat [where the source code is stored].
And check it again with a curl command. Close the container with an exit command.
Comments
Post a Comment