 Hey, guys, good morning. Thank you very much for joining me in this session. First of all, I'd like to apologize. I couldn't be there in person. Thank you very much to Force Asia for still allowing this to happen through recording. Okay, without further ado, let's start. Just a little intro. My full name is Rikius Tiawan. I've been doing database and operations engineering for the past 20 year plus. I've been exposed to open source since I started working in Oracle MySQL. That was 2012. And then I never look back ever since. Now, I also a DevOps consultant. Having a lot of fun. Helping companies to transform their culture into DevOps culture. Without further ado, let's start with what is Kubernetes? Kubernetes was originally developed by Google. Its aim is only to manage distributed container instances across thousands of nodes or servers in Google. There are other similar competing products like Maysauce and DokaSwarm. But Kubernetes by far has much wider adoption. And now the de facto standard for container management. I'd like to quit a little excerpt from Red Hat. So basically, according to Red Hat, Kubernetes helps you to easily and efficiently manage those clusters, containers clusters. Clusters can span host across public and private and hybrid clouds. For this reason, Kubernetes is an ideal platform for hosting cloud-native applications that require rapid scaling. For instance, like a real-time data streaming. Now, before we go further, let's step back for a bit and take a look at what is the difference between container and VM. So VM, as you might already know and be unaware that each VM has its own operating system files. So each of them can have different operating system. You can have Linux, you can have Windows, you can have free DSD, anything. It doesn't matter what the host operating system is. Now, that means it has a pretty good isolation. Now, let's go to container. Container, or the other hand, is sharing the operating system with the host. It only encapsulates the processes and software it's supposed to run on the container itself. So all the OS files is shared across all the containers and the host. Why would anyone want to run application on containers? First is because it's much less bulky and require less resources compared to VM. It is faster to spawn lightweight as well because it doesn't need to have OS files inside the container. All OS files sitting on the host. Second is the process isolation because each of the process which is supposed to be on specific container is all isolated with any other process. Third is easier management due to dependencies and encapsulation. OS and patches, basically you only need to patch one time and all the container will enjoy new patches. As compared to if it is in the VM you have to patch every single VM because every single VM has its own OS files. Application environment and application code and dependencies are all encapsulated within each container. And due to the encapsulation this is one part that makes it easy for continuous testing which is part of DevOps workflow. To show you the proof Kubernetes is very fast adopted by companies based on study conducted by Nirmata at KubeCon and CloudNativeCon 2018 from over 150 IT professionals. Basically 78% are using or plan to deploy microservices on Kubernetes. The rest of them, as you can see they might deploy other application like 3 tier big data, AI on NML, IoT, networking, and so on and so forth. Based on the same study it also shows that 52% are using Kubernetes in production and nearly 40% are using it in development and testing environments. Now let's take a look at architecture. Every Kubernetes system always have a master node. This is where the Kubernetes software resides. And then you'll see on top of it you have a Kube CTL this is the command line tool to send commands through the master node into the nodes. On the right hand side you see nodes. Normally a Kubernetes system consist more than just one node. It comprise of multiple nodes to form a cluster to have certain high availability. Inside each node you will find a number of pods. Pods basically is a group of containers. Each pod has its own network system and other resources and hosting as well. So all these containers within one pod will have to share all these resources belong to the pod. Underneath is basically the Docker software. Now that we know about Kubernetes and its architecture let's go into MySQL InnoDB Cluster. As you know MySQL is the most popular open source database in the world. It's widely used everywhere in any applications. Now MySQL InnoDB Cluster is basically the HA solution high availability solution built on top of MySQL replication technology. It's comprise of three main components which is MySQL group replication which is in this case in this diagram comprise of three nodes three database nodes. On top of it you have MySQL router and on the right side you have MySQL shell which is the tool to manage InnoDB Cluster. Now the group replication comprise of three database nodes. One will become primary the other two will become secondary. The primary is available for read-write the two secondary available for read-only. And MySQL router will be the one to manage failover. Anytime the primary is down MySQL router will check and find out which one will become the new primary and it will redirect the traffic into the new primary node. Now, why we want to run databases on Kubernetes? Simply because of support for the microservices architecture is faster to spawn lightweight containers does not include OS files and especially when your application already running microservices model. Next is to eliminate hefty license cost when you are using enterprise databases. Quite simply because many enterprise databases like MySQL and MariaDB they are actually licensed based on server where in this case let's say you have 3 physical nodes 3 physical servers a powerful one and you can run let's say in maybe 30, 40 database containers it's totally logical and it's actually pretty common these days. Last one is a good HA feature even though you are running only a single instant data of MySQL so there is no cluster attached there only a single instance and Kubernetes will still handle the HA because Kubernetes will simply spawn another container when the database container failed. To go further why MySQL in ODB cluster now ODB cluster offer you a higher level of availability than just a single instance. It is also affordable as you know because MySQL, MariaDB and PostgreSQL very very affordable licensing especially MySQL and MariaDB is running licensed based per server also on the other hand it's very easy to scale the read because every ODB cluster by default you have 3 nodes and 2 of them which is available for read only that means you can actually road balance your read only between these 2 secondary nodes Last one is multi master mode also available and it actually perform very well when you configure properly with some condition attached and do do take note of these conditions before you decide to go for multi master because this is very important and it can make or break your application On with the challenges on Kubernetes now first is IO because by default database is currently IO intensive so there is a challenge to be able to decide which storage required and on top of that different databases have different requirements maybe one database is database needs SSD one database need simply can run on HDD one can run on rate 5 properly the other one really really need rate 10 and then maybe some other databases require hybrid storage so they have different storage requirements Next is the different configuration different database different database have different workload pattern like online and let's say transaction processing or even let's say analytical maybe reporting maybe data warehouse load so different database have different configuration and and then also different way of application to connect into the database so this makes it more complex to manage the configuration for each and every container next is because of the nature of Kubernetes top is mortal so Kubernetes is by default designed for applications so it is easy for you to simply restart whenever the container is down Kubernetes will do it for you automatically but here the problem is database has to be persistent it has to run on persistent storage so that is why any database deployment on Kubernetes has to run on stateful sets remember these stateful sets do not use normal deployment because by default Kubernetes use deployment now resources resources is shared across lots of containers remember what I said earlier Kubernetes cluster is running let's say on a few physical service but on top of that maybe hundreds of containers that means all database containers will be sharing a number of lots of resources database containers will share all the resources of these physical nodes so resource management can be very complex security and audit policy compliance every databases have different security and audit policy compliance this make it hard as well and the last one is of course skill set of the people who manage it so this is at this moment based on my experience doing a number of consultancy and certain companies not many engineers actually have a proper skill set on Kubernetes because Kubernetes itself is still considerably new so people need some time to take up and be familiar with this technology so yeah that is a pretty good challenge there now that we know about the challenges how to overcome it we have a first is we have to analyze the database environments and analysis in the beginning is very important and this will determine whether you will make it or you will break it in production a couple of questions and we can ask ourselves before we decide to move the entire workload to Kubernetes is first whether it is already running on docker containers if it is already running on docker containers then it is a no brainer to simply move to Kubernetes it makes it easier for you to manage now if it is still monolithic we need to ask ourselves is it possible to turn it into microservices model now also whether apps support splitting these databases into smaller channels some certain apps does not support it they simply connect directly using one connections and they cannot be changed so no choice but certain application especially the custom application they can change it they can support splitting the databases into a different smaller databases next is what benefits for the database to run on microservices versus monolithic don't get me wrong it is not it is not a bad thing it is not a bad thing do not fall into this this notion where everything has to run on Kubernetes no no and no something that is running on monolithic and runs fine that's it do not touch it you better it is actually better for you to focus on new application instead of changing whatever you already have on monolithic and run very well how much effort you require to transform to microservices model this is something also you need to think about how much blood, how much tears how much sweat you need to spill in order to transform whether it is worth your time whether it is worth everybody's time in your team this is something that we need to think about next is the database is basically is commonly used on Kubernetes is commonly used for caching layer is because caching layer does not need to be persistent let's say when the container is down the Kubernetes simply pack up again and the database is empty and the application will simply affiliate that again so not a problem next use cases is normally database sharding database sharding is a good one because why would anyone want to shard a database is because they want to have a better performance because by having a smaller database smaller it is they can run more they can run on concurrently they can achieve highly parallel processing so this is this is a very good use cases one of the most popular choices for data sharding solution running on MySQL, MariaDB or Percona is actually Vitesse you might have heard about this before it is very good very reliable piece of software you might want to take a look at that if you have interest in it next one is test and test and test I cannot emphasize more the importance of testing now moving from bare metal to VM is already require a big paradigm changes moving for bare metal directly to containers it's even more changes a big huge changes so there will be a lot of unknown situation where you will never think about so do test any scenarios that you can think of this is very very important I've seen a lot of problems with companies that move from bare metal directly to containers simply with because they are not doing enough testing testability especially on database workload search now database can search due to maybe due to underlying problem within the database due to bug maybe due to to the nature of the application let's say if it is an e-commerce running on Black Friday there will be a high search on that area I think you what about the story from Amazon story from Alibaba as well right that they suddenly have a lot of transaction coming in on Black Friday on the 11-11 12-12 you name it the next one is the no skill set in no time if you have no skill set and you have no time to do all this testing I advise you to engage professional health if you want to still pursue and explore going to Kubernetes do engage professional health how to start you can get a mini cube if you want to play around on your own laptop on your own time go ahead and download it on the Kubernetes website from the MySQL part you can go to the github from Oracle this MySQL operator is created by the Oracle MySQL team you can get it there from this link now let's say you have a big team we want them to get familiar with Kubernetes you can grab a managed Kubernetes engine most of the cloud provider provide one for you there are a lot of choices there most of them offer free credits for trial and even some of them offer for 12 months so do make use of their generous offer and play around in the cloud finally we are at almost at the end already let's see the key points do tour analysis first we need to do analysis properly and thoroughly this is very important this will just determine whether we break it or we make it in a production next is do test and test and test test any single scenarios that we can think of anything put it into the system and test it because anything can happen especially on a workload search database workload can search at any time due to anything like i said before so and this can impact not just your database also other containers as well other containers might also have other databases that is used by other applications so this is very important do test monolithic is not is not bad if you have application or database that is already running monolithic model at this moment leave it aside if they are already running well leave it aside do not touch it hands off concentrate on new applications leave it aside do not touch it last but not least find strong reasons to justify and get the top executive support this is very important you don't want in the midst of your journey to transform to Kubernetes suddenly the management come down and stop everything you don't want this to happen so do get the management support first before embarking on the journey the next few slides will consist of other steps for you to set up a mass scale operator for Kubernetes you can follow them i believe our friends from force Asia will put this online so everyone can see it everyone can download it and just follow the steps to get it up and running on your own system or probably in the public cloud as well alright guys this is it thank you very much for spending about 28 minutes with me here thank you our friends from force Asia every anyone that wants to connect with me, go ahead this is my contact let me know if you guys suddenly think about having coffee and you need some friend call me up ring me and we have a coffee session while talking Kubernetes thank you very much thank you