Deploy Microservices to a Kubernetes Cluster

In a microservices architecture, each microservice performs a simple task and communicates with clients or other microservices by using lightweight mechanisms such as REST API requests. You can code each microservice using a programming language that's best suited for the task that it performs. Microservices-based applications are easier to deploy and maintain.


This reference architecture shows Python Flask and Redis microservices deployed as Docker containers in a Kubernetes cluster in Oracle Cloud Infrastructure. The containers pull Docker images from Oracle Cloud Infrastructure Registry.

The following diagram illustrates this reference architecture.

Description of microservices-oci.png follows
Description of the illustration microservices-oci.png

The architecture has the following components:

  • Region

    An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Availability domains

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

  • Fault domains

    A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.

  • Virtual cloud network (VCN) and subnet

    A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  • Container Engine for Kubernetes

    Oracle Cloud Infrastructure Container Engine for Kubernetes is a fully managed, scalable, and highly available service that you can use to deploy your containerized applications to the cloud. You specify the compute resources that your applications require, and Container Engine for Kubernetes provisions them on Oracle Cloud Infrastructure in an existing tenancy. Container Engine for Kubernetes uses Kubernetes to automate the deployment, scaling, and management of containerized applications across clusters of hosts.

  • Registry

    Oracle Cloud Infrastructure Registry is an Oracle-managed registry that enables you to simplify your development-to-production workflow. Registry makes it easy for you to store, share, and manage development artifacts, like Docker images. The highly available and scalable architecture of Oracle Cloud Infrastructure ensures that you can deploy and manage your applications reliably.


Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.

  • VCN

    When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

    Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.

    After you create a VCN, you can change, add, and remove its CIDR blocks.

    When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

    Use regional subnets.

    For simplicity, this architecture uses a public subnet to host Container Engine for Kubernetes. You can also use a private subnet. In that case, use a NAT gateway to allow access to the public internet from the cluster.

  • Container Engine for Kubernetes

    In this architecture, the worker nodes use the VM.Standard2.1 shape and they run on Oracle Linux. Two worker nodes are used to host two different microservices, but you can create up to 1000 nodes on each cluster.

  • Registry

    We use Oracle Cloud Infrastructure Registry as a private Docker registry for internal use, pushing Docker images to and pulling them from the Registry. You can also use it as a public Docker registry, enabling any user with internet access and the appropriate URL to pull images from public repositories in the registry.


  • Scalability

    You can scale out your application by updating the number of worker nodes in the Kubernetes cluster, depending on the load. Similarly, you can scale in by reducing the number of worker nodes in the cluster. When you create a service on the Kubernetes cluster, you can create a load balancer to distribute service traffic among the nodes assigned to that service.

  • Application availability

    Fault domains provide the best resilience within a single availability domain. You can also deploy instances or nodes that perform the same tasks in multiple availability domains. This design removes a single point of failure by introducing redundancy.

  • Manageability

    This architecture uses two microservices. One is a Python Flask microservice, a simple web application that performs CRUD operations. The other microservice is a Redis in-memory database. The Python-Flask microservice communicates with the Redis microservice to retrieve the data.

  • Security

    Use policies that restrict who can access which Oracle Cloud Infrastructure resources that your company has and how.

    Container Engine for Kubernetes is integrated with Oracle Cloud Infrastructure Identity and Access Management (IAM). IAM provides easy authentication with native Oracle Cloud Infrastructure identity functionality.


The code required to deploy this reference architecture is available in GitHub. You can pull the code into Oracle Cloud Infrastructure Resource Manager with a single click, create the stack, and deploy it. Alternatively, download the code from GitHub to your computer, customize the code, and deploy the architecture by using the Terraform CLI.

  • Deploy by using Oracle Cloud Infrastructure Resource Manager:
    1. Click Deploy to Oracle Cloud

      If you aren't already signed in, enter the tenancy and user credentials.

    2. Review and accept the terms and conditions.
    3. Select the region where you want to deploy the stack.
    4. Follow the on-screen prompts and instructions to create the stack.
    5. After creating the stack, click Terraform Actions, and select Plan.
    6. Wait for the job to be completed, and review the plan.

      To make any changes, return to the Stack Details page, click Edit Stack, and make the required changes. Then, run the Plan action again.

    7. If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.
  • Deploy by using the Terraform CLI:
    1. Go to GitHub.
    2. Download or clone the code to your local computer.
    3. Follow the instructions in

Change Log

This log lists significant changes: