The present disclosure relates generally to communication networks, and more particularly, to network selection for micro-services in a service mesh.
Micro-services in a service mesh deployment use multiple networks to communicate with external endpoints. Often times, a priority based policy is needed to connect a peer for a given protocol on a specific network for security reasons.
Corresponding reference characters indicate corresponding parts throughout the several views of the drawings.
Overview
In one embodiment, a method generally comprises mapping micro-service network interfaces in a service network to service engine network interfaces for connecting micro-services to external endpoints, transmitting a request for communication with one of the external endpoints from one of the micro-services to a service broker operable to select one of the micro-service network interfaces for the communication with the external endpoint, and receiving a response from the service broker with the selected micro-service network interface. The service broker dynamically selects a service path for the communication based on a policy and independent from default network routes.
In another embodiment, an apparatus generally comprises a service broker in communication with a plurality of service engines each comprising at least one micro-service comprising multiple micro-service network interfaces mapped to host network interfaces for connecting the micro-service to external endpoints. The service broker is operable to receive a request from the micro-service for communication with one of the external endpoints, select one of the micro-service network interfaces, and respond to the micro-service with the selected micro-service network interface.
In yet another embodiment, logic is encoded on one or more non-transitory computer readable media for execution and when executed operable to map micro-service network interfaces in a service network to service engine network interfaces for connecting micro-services to external endpoints, transmit a request for communication with one of the external endpoints from one of the micro-services to a service broker operable to select one of the micro-service network interfaces for the communication with the external endpoint, and receive a response from the service broker with the selected micro-service network interface. The service broker dynamically selects a service path for the communication based on a policy and independent from default network routes.
Further understanding of the features and advantages of the embodiments described herein may be realized by reference to the remaining portions of the specification and the attached drawings.
The following description is presented to enable one of ordinary skill in the art to make and use the embodiments. Descriptions of specific embodiments and applications are provided only as examples, and various modifications will be readily apparent to those skilled in the art. The general principles described herein may be applied to other applications without departing from the scope of the embodiments. Thus, the embodiments are not to be limited to those shown, but are to be accorded the widest scope consistent with the principles and features described herein. For purpose of clarity, details relating to technical material that is known in the technical fields related to the embodiments have not been described in detail.
Micro-services are common patterns for cloud based deployments and there are typically a lot of network paths needed for these micro-services to reach external endpoints such as load balancers, gateways, routers, and the like. Micro-services in a service mesh deployment use multiple networks to communicate with external endpoints. Often times, such as in the case of Kubernetes deployments, a micro-service gets one network interface and a static route is set to a default gateway that connects the micro-service to external networks. For specific types of applications, one network approach may not work and an application will need to connect to multiple external networks to implement a business function. When a micro-service has multiple interfaces, how to choose a correct network interface for its own initiated connections (out-bound) is an issue. For security reasons, a priority based policy may be needed to connect a peer for a given protocol on a specific network. Prefix based default routes are typically configured on these network nodes. In one example, prefix based routes may be pushed to the micro-service so that it can choose the right network interface to communicate with external endpoints. However, this has several limitations and does not scale well for large scale deployments. For example, it is hard to continually update routes across all micro-services, sometimes all the prefixes are not known in advance, or a default gateway policy may change based on security or other policy and applications already bound would not be updating the gateway.
The above described problem is an issue in the case of ACI (Application Centric Infrastructure) service engine deployments where a customer can onboard an APIC (Application Policy Infrastructure Controller) site that can be reachable on any of the host networks. In typical application implementations, for an outbound connection, the network interface that leads to a known route will be chosen, which is why the proper route needs to be installed within the micro-service namespace.
There is therefore, a need for an automated means to dynamically detect a correct network interface for a peer in real time that can be enforced at service level across all micro-services in a seamless and consistent manner.
The embodiments described herein implement a network service that will enable micro-services to dynamically select a network interface based on user policies in a multi-network environment. This allows a network level service graph to be built by overriding conventional static network route based criteria. As described in detail below, the embodiments allow for dynamic selection of a network within a micro-service that is reachable from a host. In one or more embodiments, if there are multiple ways to reach an APIC, a priority based policy is enforced that will be sent via in-band network (rather than an out-of-band management network).
It is to be understood that ACI and APIC as used herein are provided as examples, and the embodiments described herein may be implemented in other types of service engine deployments for use with any type of policy controllers.
Referring now to the drawings, and first to
In the example shown in
In one or more embodiments, the application centric infrastructure provides centralized automation and policy-driven application profiles. The ACI network may include, for example, switches configured for ACI, a centralized policy management and application policy infrastructure controller, an application virtual switch for virtual network edges, software and hardware components, integrated physical and virtual infrastructure, network storage, and management. Within the APIC, software applications may be defined logically using constructs that are application centric, rather than network centric. The complete application definition may be located at the APIC in an application profile, which is specified based on the communication, security, and performance needs of the application. The application profile may be used to push logical topology and policy definitions down to stateless network hardware in the network fabric. As previously noted, ACI is only one example of an infrastructure in which the embodiments described herein may be implemented.
In the example shown in
As described in detail below, a service broker 18 is in communication with a policy enforcement engine and a plurality of the service engines 14 each comprising at least one micro-service 16 comprising multiple micro-service network interfaces 17. Each of the micro-service network interfaces 17 are mapped to one of the host network interfaces 15 for connecting the micro-service to one or more of the external endpoints 12. The service broker 18 is operable to receive a request from one of the micro-services 16 for communication with one of the external endpoints 12, select one of the micro-service network interfaces 17, and respond to the micro-service with the selected micro-service network interface. The service broker 18 dynamically selects a service path (e.g., path 19 shown in
Referring now to
The service engines 24 are in communication with a service broker 28, which may be associated with a cluster federation 22 comprising a policy enforcement engine 29 and an application orchestrator (service orchestrator) 21. As previously noted, the service broker 28 may be in communication with the policy enforcement engine for use in selecting the service path (micro-service NIC 27) based on one or more policies.
As shown in
The service broker 28 is configured with a framework to provide priority based network selection and may be used with these priorities configured for a specific type of application, specific type of micro-service, or a specific domain of destination endpoints. Typical network route criteria based on user configured policy is dynamically overridden to select a network to communicate with external networks in a multi-network environment. The service broker 28 may detect correct network selection based on user configured policies and connect the micro-service with a source of the selected network. User criteria of network selection may be enforced globally across all micro-services dynamically.
It is to be understood that the networks and service engine cluster shown in
It is to be understood that the flowcharts shown in
Memory 44 may be a volatile memory or non-volatile storage, which stores various applications, operating systems, modules, and data for execution and use by the processor. The network device 40 may include any number of memory components.
Logic may be encoded in one or more tangible media for execution by the processor 42. For example, the processor 42 may execute codes stored in a computer-readable medium such as memory 44. The computer-readable medium may be, for example, electronic (e.g., RAM (random access memory), ROM (read-only memory), EPROM (erasable programmable read-only memory)), magnetic, optical (e.g., CD, DVD), electromagnetic, semiconductor technology, or any other suitable medium. In one example, the computer-readable medium comprises a non-transitory computer-readable medium. The network device 40 may include any number of processors 42.
The network interface 46 may comprise any number of interfaces (line cards, ports, NICs) for receiving data or transmitting data to other devices.
It is to be understood that the network device 40 and topology shown and described above and the embodiments described herein may be implemented in networks comprising different network topologies or a different number, type, or arrangement of network devices, without departing from the scope of the embodiments. For example, the network may comprise any number or type of network communications devices that facilitate passage of data over the network (e.g., routers, switches, gateways, controllers), network elements that operate as endpoints or hosts (e.g., servers, virtual machines, clients), and any number of network sites or domains in communication with any number of networks. Thus, network nodes may be used in any suitable network topology, which may include any number of servers, virtual machines, switches, routers, or other nodes interconnected to form a large and complex network, which may include cloud or fog computing.
Although the apparatus and method have been described in accordance with the embodiments shown, one of ordinary skill in the art will readily recognize that there could be variations made to the embodiments without departing from the scope of the embodiments. Accordingly, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.
The present application claims priority from U.S. Provisional Application No. 63/016,793, entitled PRIORITY BASED AUTOMATED NETWORK SELECTION FOR MICRO-SERVICES IN SERVICE MESH, filed on Apr. 28, 2020 (Attorney Docket No. CISCP1414+). The contents of this provisional application are incorporated herein by reference in its entirety.
Number | Name | Date | Kind |
---|---|---|---|
6970902 | Moon | Nov 2005 | B1 |
8677023 | Venkataraghavan | Mar 2014 | B2 |
9237034 | Huang | Jan 2016 | B2 |
10362141 | Thompson | Jul 2019 | B1 |
10484337 | Subbarayan | Nov 2019 | B2 |
10791168 | Dilley | Sep 2020 | B1 |
10860390 | Sukhomlinov | Dec 2020 | B2 |
10999407 | Thompson | May 2021 | B1 |
11128633 | Bhatia | Sep 2021 | B2 |
20030105864 | Mulligan | Jun 2003 | A1 |
20060069777 | Kato | Mar 2006 | A1 |
20100251327 | Channabasavaiah | Sep 2010 | A1 |
20130232498 | Mangtani | Sep 2013 | A1 |
20140304402 | Prakash | Oct 2014 | A1 |
20160028616 | Vasseur | Jan 2016 | A1 |
20170012870 | Blair | Jan 2017 | A1 |
20170187785 | Johnson | Jun 2017 | A1 |
20180004544 | Vasiltschenko | Jan 2018 | A1 |
20180123941 | Flamini | May 2018 | A1 |
20190207912 | Nielson | Jul 2019 | A1 |
20190250966 | Chennupati | Aug 2019 | A1 |
20190268384 | Hu | Aug 2019 | A1 |
20190268420 | Acharya | Aug 2019 | A1 |
20190394286 | Chunduru Venkata | Dec 2019 | A1 |
20200050494 | Bartfai-Walcott | Feb 2020 | A1 |
20200067818 | Jeuk | Feb 2020 | A1 |
20200092366 | Fix | Mar 2020 | A1 |
20200110625 | Warnicke | Apr 2020 | A1 |
20200177634 | Hwang | Jun 2020 | A1 |
20200211027 | Sharifi | Jul 2020 | A1 |
20200322230 | Natal | Oct 2020 | A1 |
20200365264 | Girardeau | Nov 2020 | A1 |
20200404076 | Mahadevan | Dec 2020 | A1 |
20200409797 | Mathew | Dec 2020 | A1 |
20210037117 | Johnson | Feb 2021 | A1 |
20210058435 | Sharma | Feb 2021 | A1 |
20210135973 | Vedam | May 2021 | A1 |
20210149879 | Kancharla | May 2021 | A1 |
20210160169 | Shen | May 2021 | A1 |
20210184977 | Testicioglu | Jun 2021 | A1 |
20210342188 | Novakovic | Nov 2021 | A1 |
Entry |
---|
Google Cloud, “Establishing 99.99% availability for Dedicated Interconnect,” retrieved from https://cloud.google.com/network-connectivity/docs/interconnect/tutorials/dedicated-creating-9999-availability, on Apr. 4, 2022, 8 pages. |
Google Cloud, “Anthos technical overview,” retrieved from https://cloud.google.com/anthos/docs/concepts/overview, on Apr. 4, 2022, 16 pages. |
Goodison, “Google Cloud Unleashes Managed Service Mesh, Serverless for Anthos,” https://www.epam.com/about/newsroom-in-the-news/2019/google-cloud-unleashes-managed-service-mesh-serverless-for-anoths, Sep. 18, 2019, 4 pages. |
BSO | IX Reach, “Press Release: IX Reach supports new Google Cloud Partner Interconnect product,” https://www.ixreach.com/news/hybrid-network-google-cloud-partner-interconnect/, Apr. 24, 2018, 3 pages. |
Number | Date | Country | |
---|---|---|---|
20210336872 A1 | Oct 2021 | US |
Number | Date | Country | |
---|---|---|---|
63016793 | Apr 2020 | US |