Deploy OCI Service Mesh and Microservices on OKE Using Cloud Shell
Your application may run on the cloud, but is it cloud native? New applications are trending towards microservices instead of monolithic applications. Microservices provide a smaller, fine, granular service with business logic that is loosely coupled with lightweight communication protocols.
In a microservices ecosystem where each microservice needs to communicate with each other, additional business logic or endpoints need to be implemented for microservices to communicate. This microservice-to-microservice communication within clusters is typically not secured, and sometimes retry logic needs to be added to each microservice to enable successful communication. You also need to monitor how your microservices are performing. What errors are occurring? How many requests are being sent? How long does it take my microservice to respond?
Oracle Cloud Infrastructure (OCI) Service Mesh is a free service that simplifies the development and operation of cloud-native applications. Service Mesh enables security, observability, and network traffic management without requiring application changes. Service Mesh automatically encrypts all communications between microservices and collects telemetry, metrics, and logs for application performance and health monitoring. Microservices enable you to onboard new team members faster, by enabling you to isolate services with their own business logic. You can also fix, test, and deploy bug fixes faster in a microservice ecosystem.
Architecture
This architecture is designed to deploy Service Mesh and redirect microservice communication into a sidecar proxy. There are two microservices: Home and Price. Service Mesh is used to define the percentage of traffic split between Home and Price.
- The Home microservice has two virtual deployments: home v1 and home v2. Home v1 is a Bootstrap static webpage that displays prices. Home v2 is a dynamic web page created with VueJS that retrieves prices from the Price microservice via REST. Home is deployed with a route table to split the traffic (from Ingress Gateway) between v1 and v2. The default split is 20:80, with most traffic going to v2 initially. Home uses port 3000.
- The Price microservice has one deployment which retrieves and updates prices from Oracle Autonomous Database and the Node Database Library. Price will create the schema and data in Oracle Autonomous Database in the first call if the schema is empty. Price also has a back office admin user interface to maintain prices on a web page. Price uses port 3010.
The application container sits alongside the proxy sidecar container in the same pod. Both containers share the same network namespace and IP address, allowing the containers to communicate via localhost. The sidecar is decoupled from the application code and enables traffic, security, and connection management without requiring any application code changes.
These microservices are stored as containers in Oracle Cloud Infrastructure Registry (OCIR). Ingress Gateways are created to access the Home and Price admin pages from the Internet. Access Policies allow traffic from Ingress Gateways to Home and Price, and traffic from Home to Price. Traffic between Home and Price to external services is allowed to enable traffic to Oracle Autonomous Database.
The sample code contains shell scripts required to build and deploy Service Mesh and Oracle Autonomous Database, using the Kubernetes CLI tool kubectl. The prerequisite to implementing the sample code is to have a Kubernetes Cluster running on Oracle Container Engine for Kubernetes (OKE) and Oracle Services Operator for Kubernetes installed with kubectl access. The DNS and OCI Monitoring samples are optional and use also only the OCI Command Line Interface. Alternatively, an /etc/hosts file configuration can be used to access Service Mesh locally. OCI Monitoring uses Grafana and will create an Ingress of its own (an OCI Load Balancer) as part of the installation. The scripts are designed to run from OCI Cloud Shell, but can also be run from a local environment. After successfully deploying Service Mesh, homepage traffic can be easily tested for the traffic split routing. Lastly, the sample also contains a third-party tool Kubeshark, which can be used to view the components and traffic inside Service Mesh.
The following diagram illustrates this reference architecture.
service-mesh-cloud-shell-architecture.zip
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).
- 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 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.
- Route table
Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.
- Internet gateway
The internet gateway allows traffic between the public subnets in a VCN and the public internet.
- Dynamic routing gateway (DRG)
The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.
- Network address translation (NAT) gateway
A NAT gateway enables private resources in a VCN to access hosts on the internet, without exposing those resources to incoming internet connections.
- Security list
For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.
- DNS
Oracle Cloud Infrastructure Domain Name System (DNS) service is a highly scalable, global anycast domain name system (DNS) network that offers enhanced DNS performance, resiliency, and scalability, so that end users connect to customers’ application as quickly as possible, from wherever they are.
- 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.
- Autonomous Database
Oracle Cloud Infrastructure Autonomous Database is a fully managed, preconfigured database environments that you can use for transaction processing and data warehousing 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.
- Service mesh
Oracle Cloud Infrastructure (OCI) Service Mesh is an application infrastructure layer managed by OCI for service-to-service communication. It streamlines the development and deployment of cloud native apps by defining standards for observability, security, and traffic management. Service Mesh is implemented as an array of lightweight proxies that are deployed in the customers' pods alongside application code without requiring the application to be aware of them.
- 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.
- On-premises network
This network is the local network used by your organization. It is one of the spokes of the topology.
Deploy
The Terraform code for deploying OCI Service Mesh is available in GitHub.
- Go to GitHub.
- Clone or download the repository to your local computer.
- Follow the instructions in the
READMEdocument.
Considerations
When implementing this Service Mesh sample code, consider these capabilities.
- CI/CD
Adding CI/CD is relatively simple using the scripts located in GitHub. OCI DevOps and GitHub Actions have been successfully used to build and deploy the microservices. Service Mesh can be deployed from CI/CD.
- Security
Traffic is allowed to the Price Admin from the Internet as part of the code sample, but in a real-life scenario, it should be restricted to private subnets only. Consider also making the Access Policies more specific.
- API Specification
The Price component API was generated using OCI API Management with the swagger.json in
price/api-docs/.