In the last article running SAP UI5 application on Kubernetes (top), I introduced how to run a simple SAP UI5 application in Docker, and have successfully uploaded a Docker image containing this UI5 application to Docker Hub.
This article, the second half of this topic, will show you how to run the Docker image in Kubernetes.
The article directories
- Two important concepts in Kubernetes: POD and Deployment
- Kubernetes guarantees some of the experiences of high availability and scalability of applications
- Kubernetes Rolling Update feature experience
What are the benefits of running our application on Kubernetes? From what Jerry learned about Kubernetes in his limited time over ten days, I understand that Kubernetes helps application developers ensure that their applications are deployed and run in a highly available, scalable, and fault-tolerant manner. Application developers don’t have to spend a lot of time and effort learning the low-level details of Kubernetes.
In other words, Kubernetes environment construction, system configuration, can all be handed over to Kubernetes administrator, and application developers as Kubernetes consumers, just need to remember a few simple Kubectl commands, can easily complete the application to Kubernetes deployment, Kubernetes as a platform brings the above non-functional enhancements to applications for almost no extra cost.
Let’s continue with the UI5 application we used in the previous article.
Jerry was too poor to buy additional servers to build his own Kubernetes cluster environment. Fortunately, Kubernetes did not abandon us poor programmers, and there was an alternative solution, Kubernetes Clusters as a Service.
In my other article Newton on the Shoulders of Giants: Kubernetes and SAP Kyma I mentioned Gardener, an open source solution for creating Kubernetes clusters:
github.com/gardener
I created a Kubernetes cluster based on Google Cloud Platform on Gardener inside SAP and named it Jerry1204:
You can see that the version of Kubernetes on the created cluster is still relatively new, with 1.12.3 just below the 1.13 version released on December 3.
Click the Dashboard hyperlink in the Access TAB above to operate on the Kubernetes cluster. Of course, older drivers like those in the Kubernetes training course at SAP Shanghai prefer to use the command line.
Because it is a free cluster, only one working node is assigned:
Kubectl get node -o wide = kubectl get node -o wide = Kubernetes
Two important concepts in Kubernetes: POD and Deployment
Here we use the command line to consume the image i042416/ UI5-nginx that we uploaded to the Docker Hub in our previous article:
kubectl run jerry-ui5 –image=i042416/ui5-nginx
There’s a lot going on behind this command line.
First of all, the application running on Kubernetes, its high availability, scalability and fault tolerance is guaranteed through Kubernetes what mechanism?
The answer is POD. Click on the Kubernetes architecture diagram above and zoom in to see that nodes contain multiple pods, and each pod contains multiple containers. As its Chinese meaning (pod, aircraft, spacecraft, or ship that can be separated from the main body) implies, POD is the carrier through which applications run, and is the basic operation unit of Kubernetes. The whole Kubernetes system is designed around POD, such as POD deployment and operation, how to ensure that the total number of PODS in the running state is equal to a constant value, how to expose the services provided by pod applications to external access and so on.
Going back to our previous command line, we tried to execute another command kubectl get pod, and sure enough, we found that a pod was created, 40 seconds old (Age = 40s).
View the details of this POD using the describe command:
kubectl describe pod jerry-ui5-6ffd46bb95-6bgpg
Kubernetes also supports CoreOS Rocket. Kubernetes also supports CoreOS Rocket.
The Events field of the describe named output reveals a lifecycle state jump for a POD from birth to service:
Scheduled->Pulling->Pulled->Created->Started
You can also tell a lot from the FROM field in each state.
Scheduled from: default-scheduler Scheduler is one of the components of Kubernetes that schedules pods to appropriate nodes. What kind of node is appropriate depends on the implementation of Kubernetes Scheduler scheduling algorithm, which Jerry has not studied. If Scheduler is thought of as a black box, its input is a POD and a list of nodes, and its output is a binding between a POD and a matching node. Message: “Successfully assigned XXX to Shoot — jerrytest-jerry1204-worker-yamer-z1-xxx “the shoot — jerrytest string is the name of the node to which the pod is assigned.
Kubelet is an important module on the Kubernetes node, responsible for maintaining and managing all containers running on the node. Ensure that the POD operates as expected.
In Kubernetes Web console, you can also see the pod in the running state:
In addition to POD, the second important Kubernetes concept is deployment.
Execute another command kubectl get deploy and find that kubectl run generates a deployment as well as a POD. The Desired, Current, and up-to-date, Available numbers output from this command, combined with the principle that almost all designs in Kubernetes are designed around pod, can be easily guessed. This generated Deployment also serves pod.
In fact, beginners in Kubernetes can understand the main responsibility of deployment as ensuring pod numbers and health.
In the previous article, we learned how to use Docker Run to start a Docker image. However, in the world of Kubernetes, we do not directly deal with the Docker container running in the POD. Instead, we use Kubernetes Service to expose the services provided by the pod application to the outside world for consumption.
So far, no application-specific services have been generated on the Kubernetes cluster. The kubectl get SVC command returns only one Kubernetes standard service.
So we use the command kubectl expose to create a service based on the deployment we just generated using kubectl run:
kubectl expose deployment jerry-ui5 –type=LoadBalancer –port=80 –target-port=80
Once the expose command has been executed, the get SVC command this time returns a service with the same name as deployment, exposing the outside world to an IP address of 35.205.230.209:
To access SAP UI5 running in Kubernetes Pod, use the url 35.205.230.209/webapp:
Kubernetes guarantees some of the experiences of high availability and scalability of applications
So far our SAP UI5 application only runs in a single pod on a working node on the Kubernetes cluster, and we haven’t noticed any difference between the application’s runtime performance and that of the previous Docker container.
Let’s now try out Kubernetes Deployment’s horizontal scaling capabilities. Select Deployment on the Kubernetes console and execute the Scale command from the menu.
Set the number of new pods: the 3 shown in the screenshot below tells the Deployment that after the command is executed, it must strive to ensure that the number of pods it controls and monitors at all times is equal to 3.
Of course, the graphical menu on the console also has corresponding commands in the command line, which we will use later.
After the OK button is clicked in the figure above, execute kubectl get Pod again, it can be observed that after the horizontal extension, two new deployment units are generated, so this time get pod command returns a total of 3 pods, of which the last two pods are created just after the horizontal extension.
Use the kubectl describe command to view the deployment details and see the runtime details of the Deployment controlled POD in Replicas:
3 desired | 3 updated | 3 total | 3 available | 0 unavailable
We now intentionally delete a pod with Kubectl delete. Once again, a new pod is automatically generated. The total number of running pods is still 3.
Kubernetes Rolling Update feature experience
Rolling upgrade is a feature of Kubernetes. As the name suggests, it is a smooth transition upgrade method, which can achieve uninterrupted service upgrade by replacing upgrade one container at a time. The output of the describe command in Deployment shown below, where the StrategyType field indicates that the default deployment upgrade created by Kubectl Run is a rolling upgrade.
I designed a simple upgrade scenario where version 1.0 of my SAP UI5 application was running simultaneously on 10 pods on a Kubernetes node. Upgrade the application to version 2.0 by rolling upgrade without interrupting the entire application.
Since the image I uploaded to Docker Hub in the last article is labeled latest by default, I need to create two images labeled V1.0 and V2.0 on Docker Hub.
The following command line pushes an image labeled v1.0 to the Docker Hub:
Modify the title of UI5 app details page and add a **(V2.0)** after the text to indicate that this version of the app is version 2.0:
Also push this version 2.0 image to Docker Hub:
Docker Hub images are ready for both versions:
First, with the 1.0 image, start a single POD to execute the SAP UI5 application:
Kubectl run jerry – ui5 – image = i042416 / ui5 – nginx: v1.0
Scale a single POD horizontally to 10 with the scale command:
kubectl scale –replicas=10 deployment/jerry-ui5
Kubectl get Pod returns 10 running pods.
Use the following command to trigger a rolling upgrade to upgrade the image based on deployent named Jerry-UI5 from V1.0 to v2.0:
Kubectl set Image Deployment/jerry-ui5i042416 /ui5-nginx=i042416/ui5-nginx:v2.0
Use kubectl rollout Status Deployment/Jerry-UI5 to see the real-time progress of the rolling upgrade. The log shown above shows how many old versions of pods are waiting to be terminated and how many new versions are available at a point in time.
- X old replicas are pending termination
- X of Y updated replicas are available
Click on any POD to view the details, and find that the docker image is already v2.0 version:
Finally, the title of the order details page appears in the browser (V2.0), confirming that the rolling upgrade has been successfully completed.
This article is just the tip of the iceberg of Kubernetes features, more details, we need to learn, after all, SAP cloud platform will support Kubernetes environment. Thanks for reading.
For more of Jerry’s original articles, please follow the public account “Wang Zixi “:
