DETAILED ACTION
Claim 1 is pending in this application.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2022/0035662 A1 to Wiggers et al. in view of U.S. No. 10,791,168 B1 issued to Diley et al. and further in view of U.S. Pub. No. 2023/0236897 A1 to Kumar et al. and further in view of U.S. Pub. No. 2021/0328858 A1 to Asveren et al.
As to claim 1, Wiggers teaches a method for managing execution of computing workloads by a fleet of multiple Kubernetes clusters in a distributed computing environment (Virtualized Computing System 100) comprising:
determining on which of a plurality of managed clusters to place the workloads by tracking and matching resource needs of the respective workloads with resource capacities and availability of at least selected ones of all of the fleet of clusters (“…FIG. 4 is a flow diagram depicting steps of a method carried out by each scheduler according to embodiments. The method of FIG. 4 is applicable to any of the independent schedulers including the high priority scheduler and the low priority scheduler, and begins at step 410, where the scheduler selects the next workload in its inventory to schedule. Then, at step 412, the scheduler determines if there are sufficient resources for scheduling the selected workload and if the scheduling of the selected workload will cause it to exceed its resource budget. If there are sufficient resources for scheduling the selected workload and the scheduling of the selected workload will not cause it to exceed its resource budget (step 412, Yes), the scheduler schedules the selected workload on the resources at step 414. On the other hand, if the resources for scheduling the selected workload are insufficient or the scheduling of the selected workload will cause the scheduler to exceed its resource budget (step 412, No), the scheduler examines the resource usage by workloads that it previously scheduled, to see if there is an opportunity to defragment (step 418). For example, if the memory requirement of a VM that needs to be scheduled is greater than what a single host in host cluster 118 can provide, a defragmentation process can be executed to live migrate one or more VMs from one host in host cluster 118 to one or more other hosts in host cluster 118 to free up enough memory in the one host for the VM that needs to be scheduled. If there is no opportunity to defragment, an error is returned at step 420. If there is opportunity to defragment, migration is carried out at step 422 to free up resources on one of the hosts in host cluster 118. Upon completion of the migration, step 414 is executed to schedule the selected workload on the resources of the freed-up host. If the selected workload is nota VM, which is statefbl, but a different virtual object, which is stateless, migration is carried out by terminating the running instance of the virtual object in one host and instantiating the virtual object in another host…” paragraph 0032); and
placing the workloads on one of:
an ordered set of target clusters and, according to the ordered set, prioritizing the workloads in the ordered set, and statically, pre-determined clusters (“…If there are sufficient resources for scheduling the selected workload and the scheduling of the selected workload will not cause it to exceed its resource budget (step 412, Yes), the scheduler schedules the selected workload on the resources at step 414…” paragraph 0032).
Wiggers is silent with reference to duplicating common Kubernetes workloads related to multi-tenancy across subsets of the fleet of clusters,
cloning and, on-demand, bringing up new clusters and shutting down shut down idle clusters, and
triggering start of workloads from a failed cluster to a different functional cluster.
Diley teaches duplicating common Kubernetes workloads related to multi-tenancy across subsets of the fleet of clusters (First Network Workload Namespace 408-1/Second Network Workload Namespace 408-2) (“…The example logical edge configuration in FIG. 4 depicts a first TCP tunnel 412-1 between a connection with a first external endpoint (not shown) at the IPv4 port of the network proxy server 414 and a first API/MS 410-1 in the first network workload namespace 408-1 of node A and between the first API/MS 410-1 in the first network workload namespace 408-1 node A and a set of code packages App A in the first network workload namespace 408-1 node A. The example logical edge configuration also depicts a second TCP tunnel 412-2 between a second external endpoint (not shown) at the IPv4 port of the proxy server 414 and a second API/MS 410-2 in the second network workload namespace 408-2 of node A and between the API/MS 410-2 in the second network workload namespace 408-2 of node A and a set of code packages App M in the second network workload namespace 408-4 of node B. The example logical edge configuration further depicts a third TCP tunnel 412-3 between a third external endpoint (not shown) at the IPv6 port of the proxy server 414 and a second API/MS 410-4 in the second network workload namespace 408-4 of node B and between the API/MS 410-4 in the second network workload namespace 408-4 of node B and a set of code packages App M in the second network workload namespace 408-4 of node B…” Col. 10 Ln. 57-67).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Wigglers with the teaching of Diley because the teaching of Diley would improve the system of WIggers by providing a namespace mechanism that ensures that all of a given set of objects have unique names so that they can be easily identified.
Kumar teaches cloning and, on-demand, bringing up new clusters and shutting down shut down idle clusters (“…In step 612, on-demand cluster manager 406 uses the cluster parameters to create a cluster and passes the job to the new cluster. Once, the job is executed (completed), on-demand cluster manager 406 removes the new cluster and frees up the resources…” paragraph 0060).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Wigglers and Diley with the teaching of Kumar because the teaching of Kumar would improve the system of WIggers and Diley by providing a cluster manager for creating and removing Kubernetes clusters to free up computing resources (Kumar paragraph 0060).
Asveren teaches triggering start of workloads from a failed cluster to a different functional cluster (Step 522) (“…In step 520, the second Pod begins operating in a standby mode of operation which includes operating the second Pod to monitor the operation of the first Pod for a first condition, the first condition being indicative of a failure of the first Pod. The second Pod while operating in the standby mode of operation does not provide services of the first service type, e.g., SBC services, to entities external to the Kubernetes system. Second Pod in standby mode of operation is standing by to take over providing such services upon the detection of the failure of the first Pod which is in the active mode of operation and is providing the services of the first type, e.g., SBC services. In some embodiments, the first condition being indicative of a failure of the first Pod includes one of the following: (i) a failure to receive at the second Pod from the first Pod heartbeat signals, or (ii) a failure to receive at the second Pod from the first Pod responses to health check messages communicated from the second Pod to the first Pod…Operation proceeds from step 520 to step 522. In step 522, in response to the second Pod detecting the failure of the first Pod, the first Pod initiates a migration procedure to change the allocation of the second IP address from the first Pod to the second Pod. Operation proceeds from step 522 via connection node A 524 to step 526 shown on FIG. 5B…In step 526, the migration procedure to change the allocation of the second IP address from the first Pod to the second Pod is performed…” paragraphs 0138-0140).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Wigglers, Diley and Kumar with the teaching of Asveren because the teaching of Asveren would improve the system of Wigglers, Diley and Kumar by providing a backup operational mode that automatically switches to a standby cluster, server or pod/container if the primary cluster, server or pod/container fails, or is shut down for servicing.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Pub. No. 2024/0281280 A1 to Bainbridge et al. and directed to a workload orchestration system that performs steps of receiving unassigned workloads for assignment on nodes for execution; and responsive to a scheduling trigger, scheduling the multiple unassigned workloads together considering one or more of resources on the nodes and a constraint policy for each of the unassigned workloads.
U.S. Pub. No. 2022/0353201 A1 Navali et al. and directed to a technique is directed toward controlling placement of workloads of an application within an application environment.
U.S. Pat. No. 12,511,164 B2 issued to Makaya et al. and directed to systems and methods are described to orchestrate the execution of an application, such as a machine learning or artificial intelligence application, using distributed compute clusters with heterogeneous compute resources.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES E ANYA whose telephone number is (571)272-3757. The examiner can normally be reached Mon-Fir. 9-6pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, KEVIN YOUNG can be reached at 571-270-3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHARLES E ANYA/ Primary Examiner, Art Unit 2194
Prosecution Insights