Sign upSign InSign upSign InMember-only storyHarry@StartQuick TechFollowLevel Up Coding--ListenSharePrevious: Kubernetes From Zero to Hero — 3 . Prepare Your Kubernetes Cluster and Learn Kubernetes Command line toolFinally, we have everything ready for building our first application on Kubernetes Cluster.Let’s have a look at the diagram for the application architecture.The application we are going to build is a Two-Tier Wordpress website with MySQL database.OK. Let’s start!Note: For all of the resources we create, we use yaml file instead of stdin. You can create these files in the same folder, which is easy for us to manage.Namespace is like a separate virtual cluster within a single Kubernetes cluster. It helps organise and isolate resources, such as pods, services, and deployments, into distinct group. It enable access control and permissions management for teams or users. It also prevents naming conflicts by allowing resources with the same names in different namespaces.In order to create the namespace [demo-app-ns], we create namespace.yaml.Then we run kubectl create command.In order to persistently retain the data in the database, which means that even if the container is deleted, the data remains preserved. This is where I would utilise a Persistent Volume.So we need to create a yaml file for PV and PVC.We need to create the resources within the namespace we created, we need to add namespace in metadata;AccessModes:With RWO access mode, the PV can be mounted as read-write by a single node (or a pod running on a single node) at a time.This mode is typically used for scenarios where a single pod needs exclusive read-write access to the PV, such as a database running on a single node.With ROX access mode, the PV can be mounted as read-only by multiple nodes (or multiple pods running on different nodes) simultaneously.This mode allows multiple pods to concurrently read data from the PV but does not support write operations. It is useful for scenarios where you need to share data across multiple read-only pods, such as serving static content or logs.With RWX access mode, the PV can be mounted as read-write by multiple nodes (or multiple pods running on different nodes) simultaneously.This mode supports both read and write operations from multiple pods across different nodes. It is useful for scenarios where you need multiple pods to read from and write to the same PV concurrently, such as shared file systems or distributed applications.So, Secrets are similar to ConfigMaps but are specifically intended to hold confidential data.Now, we create our ConfigMap and Secret objects to store database related information. As we explained, we store database name and database username in ConfigMap and database root password and user password in Secret.From above yaml config, we can see we stored plain text in ConfigMap but encoded data in Secret. I would say it is not 100% secured for just use base64 encode but compared with ConfigMap, it is much better…The way to encode the “mysecretpassword” string is as below:Now we are ready to create our MySQL DB container.We have explained the concept of Pod in the previous article about Kubernetes Architecture. And we also created pod in last part about how to use kubectl.In this article, we are going to use Deployment. So what is Deployment in Kubernetes?A Deployment is a higher-level object that provides a declarative way to manage and scale a set of identical pods. It ensures that the desired number of replicas of an application are running and provides mechanisms for rolling updates and rollbacks.Within a Deployment, a Pod Template needs to be created which includes container image, resource requirements, environment variables, etc.A Replica Set is also defined which maintains a set of identical replica of pods defined in the template.Deployments enable your application with Self-Healing capability. It can perform health checks on pods to ensure they are running correctly. If a pod fails the health check, the Deployment controller automatically restarts or replaces the pod to maintain the desired replica count.Now let’s create the Deployment for MySQL DB.Here, we set replicas to 1 which mean there will be only one pod created.Within the template spec, you can see containers and volumes. We use the PersistentVolumeClaim we created in the previous step and within the container template, you should see volumeMounts where we mount the volume and set the monthPath.With the container template, we set environment variables for the database connection. We use valueFrom to retrieve the data from ConfigMap and Secret we created.For resource requirement, you could see limits and requests. What is the difference?A Service is an abstraction that provides a stable network endpoint for accessing a set of pods. Service enables communication and load balancing between pods, allowing applications to be accessed reliably.A Service is assigned a unique IP address and a DNS name within the cluster, providing a stable network endpoint.It acts as a single entry point to access a group of pods that are part of the ServiceKubernetes supports different types of Services based on the networking requirements and the most commonly used includes:We will use ClusterIP for our MySQL DB Deployment as it is for internal and NodePort for WordPress Application Deployment.See the yaml file we created for DB Service.Once it is created, the service can be accessed via the service name which is mysql-service. You will see the example in the following parts.Now we are building the application layer with WordPress image.It should be easy for you to understand above Yaml file including both deployment and service. Just two more things to mention:Now we just need to create the resource and getting the NodePort using the minikube service command.You will get the URL for accessing the application.We did not cover Ingress, Role related in this article, although they are shown in the diagram. Don’t worry and we will learn them in the following articles.Congratulations to you for building your first Kubernetes application. This is the first milestone for learning Kubernetes.In this article, we learned Namespace, Pod, Deployment, ReplicaSet, Persistent Volume, ConfigMap, Secrets, Service, etc, but Kubernetes is obviously much stronger that these. We will learn them in details in the following sessions.Hope this is a good start for you and make sure you can follow me if you want to learn more.Next: Kubernetes From Zero to Hero — 5 . Pod Controller: ReplicaSet, Deployment, StatefulSet, DaemonSet, Job and CronJobThank you.Harry@NZ----Level Up CodingAWS Community Builder, Tech Enthusiast, DevOps, ArchitectHarry@StartQuick Tech--2Arslan MirzainLevel Up Coding--5Arslan AhmadinLevel Up Coding--13Harry@StartQuick Tech--Love SharmainDev Genius--30routerhan--Ahmed Elfakharany--3Flavius Dinu--2Oleksandr Rozdolskyi--1Flavius Dinu--1HelpStatusWritersBlogCareersPrivacyTermsAboutText to speechTeams