Deploy Container Engine for Kubernetes with Autonomous Transaction Processing in the cloud

Deploy Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) with Oracle Autonomous Transaction Processing (ATP) database to reliably build, deploy, and manage cloud-native applications using Oracle database technology on Oracle Cloud Infrastructure.

Architecture

Deploy Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) with Oracle Autonomous Transaction Processing (ATP) database to reliably build, deploy, and manage cloud-native applications using Oracle database technology on Oracle Cloud Infrastructure.

The following diagram illustrates the architecture.



deploy-oke-atp-oci-oracle.zip

The architecture has the following components:

  • Regions

    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. Oracle Cloud Infrastructure Container Engine for Kubernetes handles distribution of the nodes in the cluster across multiple fault domains. So your containerized application is protected against physical server failure, system maintenance, and power failure within an fault domain.

  • Virtual cloud network (VCN) and subnets

    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.

  • Load balancer

    The load balancer provided by Container Engine for Kubernetes (OKE) provides automated traffic distribution from a single entry point to resources in the cluster.

  • Autonomous Transaction Processing

    Oracle Autonomous Transaction Processing is a self-driving, self-securing, self-repairing database service that is optimized for transaction processing workloads. You do not need to configure or manage any hardware, or install any software. Oracle Cloud Infrastructure handles creating the database, as well as backing up, patching, upgrading, and tuning the database.

  • 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.

Recommendations

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

  • 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 in the Kubernetes cluster use the VM.Standard2.1 shape, and they run on Oracle Linux. You can create up to 1000 nodes in a cluster.

  • Autonomous database

    In this architecture, the application stores the relational data in an Oracle Autonomous Transaction Processing database. We recommend using the latest version.

Considerations

When implementing this architecture, consider your requirements for the following parameters:

  • Autonomous database scalability

    You can manually scale the database's base number of CPU cores up or down at any time. Autonomous Transaction Processing's autoscaling feature allows your database to use up to three times the current base number of CPU cores at any time. As demand increases, autoscaling automatically increases the number of cores in use. Autonomous Transaction Processing allows you to scale the storage capacity of the database at any time without impacting availability or performance.

  • Autonomous database backups

    Oracle Cloud Infrastructure automatically backs up your autonomous databases and retains these backups for 60 days. You can restore and recover your database to any point-in-time in this retention period. You can also create manual backups to supplement your automatic backups. Manual backups are stored in an Oracle Cloud Infrastructure Object Storage bucket that you create and are retained for 60 days.

  • Kubernetes 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.

  • Security

    Use policies that restrict who can access which Oracle Cloud Infrastructure resources and how they can access them.

    Oracle Cloud Infrastructure 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.

Deploy

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 command line interface.

  • 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 command line interface:
    1. Go to GitHub.
    2. Download or clone the code to your local computer.
    3. Follow the instructions in deploy/complete/README.md.

Change Log

This log lists significant changes: