1
00:00:00,101 --> 00:00:03,801
We have created WordPress application on Docker Compose

2
00:00:03,801 --> 00:00:06,567
and on bootstrapped Kubernetes cluster.

3
00:00:06,634 --> 00:00:09,767
Let's try it with GKE right now. But we are done

4
00:00:09,767 --> 00:00:12,801
with writing YAML files, we have written a lot of

5
00:00:12,801 --> 00:00:16,267
them. So this time, we will use Kubernetes engine

6
00:00:16,267 --> 00:00:18,867
samples provided by Google. And we'll directly

7
00:00:18,867 --> 00:00:23,267
clone them from GitHub. Use git clone, followed by this link.

8
00:00:23,834 --> 00:00:28,234
There we go, let's see if the repository is here.

9
00:00:28,234 --> 00:00:31,767
Well, it is. kubernetes-engine-samples

10
00:00:31,767 --> 00:00:34,234
directory is quite huge. So let's take

11
00:00:34,234 --> 00:00:37,367
k8s-samples out of it. Let's go to

12
00:00:37,434 --> 00:00:40,567
k8s-samples directory. Let's list out the

13
00:00:40,567 --> 00:00:44,134
components here and there are a lot of examples.

14
00:00:44,867 --> 00:00:49,267
But we want to focus on wordpress-persistent-disks example.

15
00:00:49,601 --> 00:00:54,801
Let's navigate to wordpress-persistent-disks directory,

16
00:00:55,101 --> 00:00:56,601
and when we look into it,

17
00:00:56,601 --> 00:00:58,834
we have a bunch of YAML files.

18
00:00:59,834 --> 00:01:05,834
A few of them seem quite friendly, mysql.yaml, mysql-service,

19
00:01:05,834 --> 00:01:09,867
wordpress.yaml, and wordpress-service.yaml.

20
00:01:10,067 --> 00:01:12,301
These are all the files which we

21
00:01:12,301 --> 00:01:15,767
have operated on previously. But we have a few new

22
00:01:15,767 --> 00:01:20,167
files as well, which are mysql-volumeclaim and

23
00:01:20,167 --> 00:01:23,901
wordpress-volumeclaim.yaml. What are those?

24
00:01:24,434 --> 00:01:25,801
Let's check them out.

25
00:01:26,234 --> 00:01:30,834
So it turns out that mysql-volumeclaim.yaml

26
00:01:30,834 --> 00:01:32,867
is a file for declaring

27
00:01:32,867 --> 00:01:36,701
a PersistentVolumeClaim. Persistent Volumes are

28
00:01:36,701 --> 00:01:39,567
storage objects in Kubernetes. And since they are

29
00:01:39,567 --> 00:01:42,867
persistent, even if the pod dies, the volume

30
00:01:42,867 --> 00:01:47,034
doesn't vanish. So there needs to be a mechanism

31
00:01:47,034 --> 00:01:50,801
through which the new born pod can mount itself

32
00:01:50,801 --> 00:01:53,401
with the volume. So just like sources with

33
00:01:53,401 --> 00:01:57,601
projected volume, Persistent Volumes have PVC or

34
00:01:57,601 --> 00:02:01,467
PersistentVolumeClaims. These objects are used

35
00:02:01,467 --> 00:02:04,967
by pods to claim a certain volume and use it

36
00:02:04,967 --> 00:02:09,001
afterwards. Starting from the top, our kind is

37
00:02:09,001 --> 00:02:11,734
PersistentVolumeClaim, which is using the same

38
00:02:11,734 --> 00:02:15,867
apiVersion as pod or ReplicaSet, which is v1.

39
00:02:16,267 --> 00:02:19,301
In the metadata section, we have given it its name.

40
00:02:20,134 --> 00:02:22,901
To understand PersistentVolumeClaims better,

41
00:02:23,101 --> 00:02:26,101
compare them with pods, they're actually pretty

42
00:02:26,101 --> 00:02:29,867
similar to pods. Pods consume Node resources,

43
00:02:29,867 --> 00:02:32,401
whereas PersistentVolumeClaims consume

44
00:02:32,401 --> 00:02:37,534
Persistent Volume resources. Pod asks for CPU and

45
00:02:37,534 --> 00:02:41,934
memory, whereas PersistentVolumeClaims ask for storage.

46
00:02:41,934 --> 00:02:45,201
In spec section, we have two fields,

47
00:02:45,201 --> 00:02:48,134
accessModes and resources. For different

48
00:02:48,134 --> 00:02:50,467
applications, PersistentVolumeClaims have

49
00:02:50,467 --> 00:02:57,101
different access mode, like ReadWriteOnces or ReadOnlyMany,etc.

50
00:02:57,101 --> 00:02:59,934
Finally, it is going to ask for a

51
00:02:59,934 --> 00:03:04,634
block of 200 gigabyte storage. Similarly, you can

52
00:03:04,634 --> 00:03:07,901
also look at wordpress-volume-claim. Apart from

53
00:03:07,901 --> 00:03:11,134
the name of the claim, nothing is different. So in

54
00:03:11,134 --> 00:03:14,901
total, we're asking for 400 gigs of storage.

55
00:03:14,901 --> 00:03:18,667
Let's apply both of these YAML files and create

56
00:03:18,667 --> 00:03:22,167
PersistentVolumeClaims. You might be wondering

57
00:03:22,167 --> 00:03:25,501
if PersistentVolumeClaims are a way to claim

58
00:03:25,501 --> 00:03:29,901
storage from GCP, who actually provides this storage?

59
00:03:30,001 --> 00:03:32,701
Well, if you remember a couple of demos

60
00:03:32,701 --> 00:03:36,867
ago, when we looked at the storage section of our GKE

61
00:03:36,867 --> 00:03:41,067
cluster, we found a storage class named standard.

62
00:03:41,934 --> 00:03:45,434
Storage class is responsible for provisioning

63
00:03:45,434 --> 00:03:47,934
storage to PersistentVolumeClaims.

64
00:03:47,934 --> 00:03:49,967
[No Audio]

65
00:03:49,967 --> 00:03:54,267
Now, let's create a secret for our mysql-password.

66
00:03:55,367 --> 00:03:59,834
Next up, let's take a look at our deployments and services.

67
00:04:00,334 --> 00:04:03,034
Let's start with mysql deployment.

68
00:04:03,334 --> 00:04:06,401
It is quite like what we had used previously.

69
00:04:06,401 --> 00:04:10,701
Apart from the fact that this time, it is not using an empty

70
00:04:10,701 --> 00:04:13,201
directory as a volume, but it is using a

71
00:04:13,201 --> 00:04:16,733
Persistent Volume. In Volumes field, we have the

72
00:04:16,733 --> 00:04:21,101
name of the volume which is mysql-persistent-storage,

73
00:04:21,101 --> 00:04:23,801
which means we are asking Kubernetes to

74
00:04:23,801 --> 00:04:27,834
create this volume called mysql-persistent-storage

75
00:04:27,834 --> 00:04:31,167
and our next lines will determine that this volume

76
00:04:31,167 --> 00:04:35,467
is going to be a Persistent Volume. Reason is, just

77
00:04:35,467 --> 00:04:37,734
like sources with projected volumes, we are

78
00:04:37,734 --> 00:04:40,534
providing PersistentVolumeClaims with this

79
00:04:40,534 --> 00:04:45,234
volume followed by the claim name which is mysql-volume-claim

80
00:04:45,234 --> 00:04:47,601
or mountPath is also same as

81
00:04:47,601 --> 00:04:50,901
what it was when we previously deployed wordpress.

82
00:04:51,034 --> 00:04:54,167
Let's exit this file and create this deployment.

83
00:04:54,401 --> 00:04:58,167
Next up, we have mysql-service of ClusterIP type.

84
00:04:58,167 --> 00:05:01,467
It is exactly like what we had used previously, so we

85
00:05:01,467 --> 00:05:04,601
can take a quick look at it and exit this file.

86
00:05:04,701 --> 00:05:07,867
Let's quickly create the service as well and

87
00:05:07,867 --> 00:05:11,834
check out our wordpress deployment, just like mysql-deployment.

88
00:05:11,834 --> 00:05:14,301
Here too, the only difference is the

89
00:05:14,301 --> 00:05:16,601
type of the volume, where we have provided

90
00:05:16,601 --> 00:05:19,967
persistentVolume and you also mentioned the

91
00:05:19,967 --> 00:05:23,101
claim, let's create this deployment as well.

92
00:05:23,167 --> 00:05:26,267
Let's check out our wordpress-service, which is also

93
00:05:26,267 --> 00:05:29,267
same as last time. But this time, we hope that its

94
00:05:29,267 --> 00:05:33,467
type being LoadBalancer makes a significant impact.

95
00:05:33,467 --> 00:05:36,601
Let's create the service and let's get a

96
00:05:36,601 --> 00:05:39,834
list of services. Till now everything was going

97
00:05:39,834 --> 00:05:42,367
just like how it went with our bootstrap

98
00:05:42,367 --> 00:05:46,367
Kubernetes. But from this step onwards, we can see

99
00:05:46,367 --> 00:05:50,934
the power of hosted or managed Kubernetes of GKE,

100
00:05:51,101 --> 00:05:54,267
or LoadBalancer service is working perfectly

101
00:05:54,267 --> 00:06:01,467
and we have an external IP 35.228.119.91

102
00:06:01,467 --> 00:06:04,767
dedicated to our WordPress application, which

103
00:06:04,767 --> 00:06:07,134
means that we don't have to reveal the external

104
00:06:07,134 --> 00:06:10,201
IPs of the nodes. And even if we host a few more

105
00:06:10,201 --> 00:06:12,901
applications on different ports, they will have

106
00:06:12,901 --> 00:06:15,967
their individual IPS so we will have no IP

107
00:06:15,967 --> 00:06:18,934
conflicts whatsoever. Furthermore, when you

108
00:06:18,934 --> 00:06:22,834
describe the service wordpress, take a look at the events.

109
00:06:23,167 --> 00:06:26,901
GKE is constantly making sure that the

110
00:06:26,901 --> 00:06:30,434
LoadBalancer is working properly. Now let's go to

111
00:06:30,434 --> 00:06:34,134
a new tab on our web browser and simply put the

112
00:06:34,134 --> 00:06:37,934
external IP or the LoadBalancer IP of our

113
00:06:37,934 --> 00:06:42,334
application. No curl, no combination of IP and

114
00:06:42,334 --> 00:06:46,001
port number nothing, just a simple IP.

115
00:06:46,267 --> 00:06:49,634
And there we go, our wordpress is up and running.