Let's go through the lab on persistent volumes
and persistent volume claims.
We have deployed a pod.
Inspect the pod and wait for it to start running.
Let's do that.
We have the webapp pod, and it's in running state.
The application stores logs at location, /log/app.log.
View the logs.
In order to view a file within the pod, we'll do a kubectl exec
and provide the pod name,
and then the command, so cat/log/app.log.
We're able to view the logs and we see some of the events
that are logged by the application.
Now, if the pod was to get deleted now, would you be able to view the logs?
Let's check out where those logs are.
Describe pod webapp.
There are no other volumes configured.
You have the kube-api-access, which is the default volume,
but there are no other volumes.
Anything that's stored in the logapp.log is stored within the container,
within the pod.
If the pod gets deleted, the logs get deleted as well.
Would you be able to view logs?
No, we're not going to be able to view the logs.
Now, configure a volume to store these logs at this path on the host.
Currently, all the logs are stored
at /log/app.log within the pod
or within the container.
Now, we'd like to use the volume to store those logs at var/log/webapp.
That's var/log/webapp on the host.
Currently, there's nothing here.
Let's try and set up a volume.
We're going to edit the pod, so we'll do a kubectl edit pod webapp.
There's a lot of information.
Here, we have the volumeMount, which is the default volumeMount
for accessing the kube API server.
Below we have the volumes, which is again, the default volume used for that.
We're just going to add our own volume here.
We'll call the volume log-volume because we're going to use this
to store the logs.
This is going to be a hostPath.
The path is going to be whatever path
is given here, which is var/log/webapp.
var/log/webapp.
We have the volume.
Basically, what's going to happen is when this pod is recreated,
it is going to mount this directory, and we're supposed to specify
where it's going to be mounted to.
It's going to create a volume out of that directory
and then we have to specify where it's going to mount it.
We're going to add a volumeMount,
and we'll call the mountPath
as it is above.
That would be a log,
and then we will have a name
for the volume, and the name of the volume is log-volume.
What's going to happen is when the pod is recreated,
is going to create a volume which will store all data in this path,
on the host, and it'll be called as log-volume.
Then we can mount this volume within any container on this pod.
Here, there's only one container.
Under volumeMounts, we have the mountPath, and we're going to specify
the name of the volume and it's going to mount that here.
Basically, this is going to be mount
to this path within the container. Okay.
Let's try and save that. Here's the pod.
It's not going to allow us to save there. We're going to do a kubectl replace force.
Okay. This part is now recreated.
Now, let's check the path at var/log/webapp.
We can see that the file that stores the logs called app.org is in this path.
We'll do app.log.
You see the logs of the pod are indeed here.
The logs of the pod are now available on the host of this particular path.
That indicates that that's working.
The next task is to create a persistent volume
with a given specification.
Let's go to the Kubernetes documentation pages
and find persistent volume.
We go to persistent volumes.
Here we have a template for a pod.
This is the volume claim.
Persistent volume.
This doesn't have enough information, so I'm just going to keep poking.
This is the persistent volume.
I'm going to get copy this much.
[?].
I'm going to create a file called pv.yaml
for persistent volume. Okay.
Then here we have pv-log.
There's the persistent volume name.
Then we have storage.
That's 100 mebibytes.
Then we have volume modes.
We don't need volume mode.
We have access mode.
Access mode is ReadWriteMany.
The persistent volume reclaim policy
is going to be retain.
Then the type is going to be hostPath, we're going to give the hostPath.
Then we specify the path.
That's going to be /pv/log.
That's the path.
Let's create the file.
That's created.
Let's check it out.
We have the pv-log, 100Mi capacity, ReadWriteMany,
so this indicates ReadWriteMany, and the reclaim policy is retain.
Let's check our work.
Okay.
Now, let us claim some of that storage for application.
Create a persistent volume claim with the given specification.
Let's find a persistent volume claim template.
We had one here.
Right here, I have persistent volume claims.
We'll use this template.
We don't need the advanced selectors.
Our use case is simple so we're just going to copy this much.
Let's do a pvc.yaml.
We have persistent volume claim.
The name is going to be claim-log-1.
Access mode is going to be
ReadWriteOnce.
We don't need a volume mode.
The storage is going to be 50Mi.
Now we're going to create -f pvc.
Let's check out the status.
That's created.
Let's go next.
What is the state of the persistent volume claim?
If you look at the state, it is in a pending state. That's that.
Now, what is the state of the persistent volume?
Still the persistent volume, it is available.
Let's try it now again.
It's in an unavailable state.
Why is the claim not bound
which has 100 mebibytes of capacity, and then we have the PVC
which requested about 50, but it's still in a pending state.
Why is that?
If you look at it, it's not a capacity mismatch
because we know that when you create a persistent volume claim,
if there's a volume
it's going to bind that volume to that persistent volume claim.
That's not the case here.
We have the reclaim policy set.
The name of these policy is the PV and PVC does not really matter.
The only other thing that it looks at is the access mode.
If you look at the PV that we created,
it had an access mode ReadWriteMany.
If you look at the PVC,
it has ReadWriteOnce.
That's the reason.
Access mode mismatch is the reason.
Now, the next question is update the access mode on the claim
to bind it to the PV.
We're going to do an update on the claim.
We want to change the access mode on the PVC to ReadWriteMany,
which is on the PV.
That's what is requested here.
Now we're going to do a replace force -f PVC.
Now, you requested for 50 mebibytes, how much capacity
is now available to the PVC?
Let's look at that.
Let's do a kubectl get PV, kubectl get PVC.
If you look at the PVC, the capacity that it has is 100 mebibytes.
Now, update the webapp pod to use the persistent volume claim
as its storage.
What we're going to do now is we're going to replace hostPath
with the persistent volume claim to use the persistent volume claim.
Before that we've created the PV to store
the logs, to use the hostPath at ls/pv/log.
Right now, there is nothing in there.
Let's go ahead and edit the pod webapp.
This is okay.
The MountPath, we're going to leave it as this.
We're going to go down and we're going to change this
from hostPath to persistent.
Let's see what that is.
If you look here,
we should be able to see how to use
a persistent volume in a pod.
You have claim as volumes.
Within volumes, you use the persistent volume claim.
That's what we're looking for.
You have claim name.
We don't need these lines.
Then the claim name is going to be claim-log-1.
You have persistent volume claim, claim name, and log-1.
That should be it.
Let's replace the file.
Let's replace the pod forcefully. Okay.
That is done.
Let's check our work. All right.
Now let's see if you look at /pv/log,
you see the logs there,
and if you look at log/app.log,
you can see lots of the application there.
Now, the PV is using a hostPath
as the location for storing data,
but then the PV is then claimed by the PVC,
and then the PVC is configured as a volume for the pod,
and then that's how it is mounted to the pod.
That's how this is working right now.
The next question is, what is the reclaim policy set
on the persistent volume pv-log.
Let's see.
Kubectl get pv pv-log.
We can see that it is retained, so retain is the answer.
Now, what would happen to the PV if the PVC was destroyed?
We know that with the reclaim policy set to retain, the pv is going to be retained,
so it's not going to be deleted along with the PVC.
The PV is greater as well. No.
The PV is made available again.
No, it's not made available again, that will be recycling.
The PV is scrubbed.
No, the PV is not deleted, but not available.
It's not deleted, but it's not available either.
That's the status.
Now, try deleting the PVC and notice what happens.
Let's do that. Get pvc.
Delete pvc claim-log-1.
Let's wait for that to be deleted.
It's not going to get deleted because it's actually going to be statless.
Let's look at the status in a new terminal.
Let's do a kubectl get pvc, and we see that it's in a terminating state,
so it's stuck in a terminating state.
Let's do a describe.
Yes, so you see it's stuck in a terminating state
for the last 30 seconds or so.
Why is the PVC stuck in a terminating state?
That's obviously because it is associated, has a volume with a pod,
so it is being used by a pod.
That's the reason it's stuck in a terminating state.
Now let's now delete the webapp pod.
Let's go ahead and do that.
Let's delete pod webapp,
and let's see what happens.
Okay, so that was deleted, and we see we're now unstuck
and the PV was deleted as well.
Let's check that out.
Yes, the pod was deleted and the PVC was deleted as well.
What is state of the PVC now?
It is deleted.
What is the state of the PV now?
Let's try that.
We see that it is in a released state.
Okay, so that's the end of this lab.