K8s Pro Sentinel: Extend Secret Security in Kubernetes Cluster

Indrajith Ekanayake; Kavindu Gunathilake

REVIEW 3 major objections 5 minor 20 references

K8s Pro Sentinel: Extend Secret Security in Kubernetes Cluster

T0 review · 3 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read K8s Pro Sentinel is an operator that automates Secret encryption and access control in Kubernetes by extending the API server with a custom resource and controller.

desk verdict A student-project operator with a real artifact but an undefined and likely infeasible encryption mechanism; the evaluation never tests the core security claim. read the letter →

arxiv 2411.16639 v1 pith:UGCQAKOL submitted 2024-11-25 cs.DC cs.CR

Kavindu Gunathilake , Indrajith Ekanayake This is my paper · ORCID

classification cs.DCcs.CR

keywords KubernetesSecretsmanagementoperatorCustomResourceDefinitionRBACencryptionatrestDevSecOpsChaosEngineering

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Kubernetes stores passwords, API keys, and tokens as Secret objects, but it does not encrypt them by default and relies on administrators to hand-configure RBAC, encryption providers, and rotation. Manual configuration is slow, requires specialized knowledge, and is a known source of misconfigurations in real-world manifests. This paper introduces K8s Pro Sentinel, an operator that extends the Kubernetes API server with a Custom Resource Definition and controller so that Secrets are created, validated, and audited through a guided CLI or GUI. The claimed payoff is that automating these steps reduces human error and improves cluster security. The authors support the claim with latency measurements, chaos experiments, and a six-test operator scorecard that passed five of six checks.

What carries the argument

The central mechanism is the Sentinel operator: a Custom Resource Definition (CRD) plus a controller with a reconcile loop that extends the Kubernetes API server. The CRD defines three Secret flavors (BaseSecret, LocalEncryptionProvider, and RBAC), and the controller validates the user request against preconditions before creating or modifying the underlying Secret. The controller enforces the desired state continuously and records Secret information in etcd using the EncryptionProviderConfig encryption type. A proxy API and GUI/CLI presentation tier feed user inputs into the controller and return validation results.

What would settle it

Run two identical clusters, create Secrets through the K8s Pro Sentinel GUI/CLI in one and through ordinary kubectl commands in the other using the same tasks, then inspect etcd to count how many Secrets are stored unencrypted and how many RBAC bindings are broader than the requested scope; if the operator cluster does not show fewer misconfigurations, the central reduction-of-human-error claim is not supported.

Watch

Extended reading notes

Core claim

K8s Pro Sentinel is a cloud-agnostic Kubernetes operator that automates the security configuration of Secret objects. It adds a Sentinel Custom Resource through which users request a BaseSecret, a LocalEncryptionProvider Secret, or an RBAC-constrained Secret; the operator's controller validates the request, creates the backing Secret with the appropriate EncryptionProviderConfig or service-account role binding, and reconciles the cluster state to match the desired configuration. The operator also provides automated auditing and surfaces deployment errors in the GUI. The paper's central claim is that this automation removes the need for specialized Kubernetes knowledge and eliminates the misconfiguration-prone manual steps involved in enabling Secret encryption and access control.

Load-bearing premise

The load-bearing premise is that automating Secret configuration actually reduces human error and improves security, yet the paper's evaluation measures latency and scorecard/chaos results rather than comparing misconfiguration rates or security outcomes with and without the operator.

Editorial extensions

If this is right

If the operator works as claimed, clusters gain encryption-at-rest and role-based access control for Secrets without an administrator writing EncryptionConfiguration objects or binding roles by hand.
Guided creation through the GUI or CLI should let teams with limited Kubernetes expertise deploy Secrets safely, lowering the barrier to adopting least-privilege access.
The reconcile loop means drift from the desired Secret configuration is corrected automatically, reducing the window in which a misconfigured Secret stays in place.
Because the design is cloud-agnostic and uses only standard Kubernetes extension points, the same operator should work across managed and self-hosted clusters.
Passing five of six built-in operator scorecard tests means the Custom Resource is mostly well-formed, while the failed 'spec fields with descriptors' check remains an unmet best-practice item.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The paper does not measure misconfiguration rates directly, so a natural extension would be a user study comparing the operator's guided workflow against raw kubectl commands on identical Secret-creation tasks.
The operator could be extended to automate Secret rotation on a schedule, since the literature it cites lists rotation as a core Secrets-management strategy but the current design covers only creation, modification, and auditing.
The failing scorecard test suggests the CRD/CSV descriptors are incomplete; adding descriptors and re-running the scorecard is a concrete next step before the operator is packaged for a broader audience.
Because the evaluation used one self-hosted two-node cluster, testing against managed Kubernetes services or a multi-node cluster would establish whether the latency and validation behavior hold at larger scale.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Quick take: this is a student-engineering project report, not a research paper. The core claim—that the operator automates Secret encryption—rests on a mechanism the paper never defines, and standard Kubernetes doesn't support per-Secret encryption at rest. That said, the authors do ship an open-source operator with a real GUI/CLI, and they run standard operator tests. The flaws are fixable, but the current text doesn't support the security conclusions.

What's new: not much scientifically. The operator pattern is standard. The combination of a GUI form for Secret creation and automated RBAC checks is a nice convenience for small teams. The paper does a fair job of motivating the problem: 15.7% manifest misconfiguration is a real concern. I'll give credit for making source code available and for using the Operator SDK scorecard—five of six pass, which is a concrete, reproducible check.

Where it falls down: The encryption story. The paper mentions a 'LocalEncryptionProvider' Secret type and 'EncryptionProviderConfig type Secret' as if they were standard Kubernetes features. They are not. Secret encryption at rest is configured cluster-wide in the API server via EncryptionConfiguration; an operator cannot selectively enable it for individual Secrets. If the operator encrypts data before storing it inside a Secret, the key management is nowhere described, and a key stored in the cluster defeats the purpose. The evaluation never exercises encryption: latency, scorecard, and chaos experiments with no reported results don't validate the security benefit. The one scorecard failure (Spec fields with descriptors) is minor by itself, but it points to an incomplete OLM bundle. There is also no comparison with Sealed Secrets or External Secrets, which already solve parts of this problem.

Proportion: if this were submitted to a workshop or undergraduate symposium, it's about the right depth. For a peer-reviewed venue, the central mechanism needs to be defined and tested, and the evaluation needs a security metric (e.g., misconfiguration rate before/after) and a comparison baseline. If the GitHub repo shows a working key-management design, the paper could be reshaped into something publishable.

For you: this paper is a decent example of an honest but flawed engineering report. I wouldn't cite it, and I wouldn't bring it to reading group, but I would let a referee look at it if the venue is engineering-oriented, because the artifact is testable.

Referee Report

3 major / 5 minor

Summary. The paper proposes K8s Pro Sentinel, a Kubernetes operator built with the Operator SDK that extends the Kubernetes API via a Custom Resource Definition (CRD). The operator is claimed to automate the configuration of RBAC, encryption, and auditing for Kubernetes Secret objects, thereby reducing human error and enhancing cluster security. The evaluation consists of latency measurements from a self-hosted two-node cluster, a qualitative description of chaos experiments, and Red Hat Operator Scorecard tests, of which five of six pass. The conclusion claims the tool enhances security practices based on this evaluation.

Significance. If the central claim were validated, an open-source, cloud-agnostic operator that automates Secret security configuration would be a genuinely useful contribution for small teams and for reducing Kubernetes misconfigurations, which the paper correctly notes are prevalent. The paper has some strength in making source code available and in using standard operator-development tooling. However, the claimed security benefit is not supported by the evaluation, and the encryption mechanism—the headline feature—is not described in a way that corresponds to any standard Kubernetes encryption-at-rest capability. As presented, the contribution is an engineering demo rather than a validated security solution.

major comments (3)

[Section III] The encryption mechanism is undefined and, as described, does not correspond to standard Kubernetes functionality. The paper refers to a 'LocalEncryptionProvider' Secret type and an 'EncryptionProviderConfig type Secret', but Kubernetes encrypts Secrets at rest cluster-wide through the API server's EncryptionConfiguration object and the --encryption-provider-config flag; there is no per-Secret 'LocalEncryptionProvider' type. If the operator instead encrypts data before storing it in a Secret's data field, the paper must specify where keys are stored and how they are managed; no key management is described, and keys stored in the cluster would defeat the purpose. This ambiguity directly undermines the abstract's claim that the operator automates configuration of encryption for Secret Objects.
[Section IV] The evaluation does not measure any security outcome. The central claim is that the operator reduces human error and enhances security, but Table I reports only single latency values without variance or number of runs, and the chaos experiments are described only qualitatively with no results, metrics, or failure analysis. There is no measurement of misconfiguration rates, no comparison to manual configuration or existing tools, and no demonstration that the operator prevents or detects any specific vulnerability. Consequently, the conclusion that 'the empirical evaluation demonstrates the performance of K8s Pro Sentinel in enhancing security practices' is unsupported by the evidence presented.
[Section IV, Table II] The Operator SDK Scorecard result is reported as a pass rate of 5/6, but the single failing test ('Spec fields with descriptors') is directly relevant to the claimed comprehensiveness of the automation: it indicates that the CRD's spec fields are not fully described in the Cluster Service Version (CSV). The paper does not discuss the implications of this failure for OLM compatibility or for the completeness of the operator's schema. This unaddressed failure weakens the claim that the operator provides fully automated and reliable Secret management.

minor comments (5)

[Section IV] There are several typos and infelicities: 'Mesure latency' in Fig. 4, and 'The evacuation of creating and modifying BaseSecret...' should be 'The evaluation of creating and modifying...'.
[Section III] The paper says the system 'extends the Kubernetes API server' by using a CRD; CRDs are an extension mechanism of the API, but this is not the same as API aggregation (a different extension method). Clarifying this distinction would improve technical precision.
[Section III] The auditing functionality is listed as a key feature, but the methodology does not describe how auditing is implemented, what events are audited, or how the results are exposed to the user. This is a missing technical detail for a claimed core capability.
[References] Reference [27] appears to be corrupted ('A TRHORLEE-EBTAISEERDAARCCHISTSECCOTNUTRREOFLOR'); it should be corrected to a proper citation of the three-tier architecture reference.
[Section IV] The latency table reports values in whole seconds for operations that are typically sub-second; the absence of error bars or repeated trials makes the measurements difficult to interpret, and the GUI/CLI differences are not discussed.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's claims are engineering assertions evaluated by external tests and measurements, with no derivation that reduces to its own inputs.

full rationale

This paper does not contain a mathematical derivation chain, so the classic circularity patterns do not arise. The central claim—that K8s Pro Sentinel automates encryption and access control and thereby reduces human error—is an engineering assertion supported by latency measurements, Red Hat Operator Scorecard tests, and qualitative chaos experiments. None of these evaluation quantities is fitted from, or defined in terms of, the claimed outcome, so no step reduces by construction to its inputs. The scorecard is an external OLM test suite, and the paper reports the failing 'Spec fields with descriptors' test honestly rather than relabeling it as a pass; a failed external check is evidence against the authors' own completeness claim, not circular reasoning. The paper's terminology around 'LocalEncryptionProvider' Secret types and 'EncryptionProviderConfig type Secret' is not standard Kubernetes and leaves the encryption-at-rest mechanism undefined, which is a serious feasibility and correctness concern, but it is a missing-mechanism problem rather than a self-referential derivation. The paper also explicitly acknowledges its limited self-hosted evaluation scope in Section V, again a limitation statement rather than a circular step. No load-bearing self-citations, imported uniqueness theorems, or ansatz-smuggling citations were found. Therefore the correct finding is no significant circularity, with the substantive weaknesses belonging to evidence quality and technical correctness rather than circularity.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The paper introduces no new theoretical entities. Its conclusions depend on domain assumptions about Kubernetes default security and the efficacy of automation, which are plausible but not demonstrated in this evaluation.

assumptions (3)

domain assumption Kubernetes Secrets are stored as base64 by default and are not encrypted at rest
Stated in Introduction with citation [9]; drives the need for encryption automation.
domain assumption Automation reduces human error and improves security posture
Assumed in Abstract and Conclusion, but not empirically tested.
domain assumption The controller's reconciliation correctly enforces desired state
Relies on standard Kubernetes controller pattern, mentioned in Methodology.

how reviews work

0 comments

Cite this review

Pith. "Pith review of K8s Pro Sentinel: Extend Secret Security in Kubernetes Cluster." pith.science (2026). https://pith.science/paper/UGCQAKOL

@misc{pith2026241116639,
  author       = {Pith},
  title        = {Pith review of: K8s Pro Sentinel: Extend Secret Security in Kubernetes Cluster},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/UGCQAKOL}},
  note         = {Machine review of arXiv:2411.16639}
}

read the original abstract

Microservice architecture is widely adopted among distributed systems. It follows the modular approach that decomposes large software applications into independent services. Kubernetes has become the standard tool for managing these microservices. It stores sensitive information like database passwords, API keys, and access tokens as Secret Objects. There are security mechanisms employed to safeguard these confidential data, such as encryption, Role Based Access Control (RBAC), and the least privilege principle. However, manually configuring these measures is time-consuming, requires specialized knowledge, and is prone to human error, thereby increasing the risks of misconfiguration. This research introduces K8s Pro Sentinel, an operator that automates the configuration of encryption and access control for Secret Objects by extending the Kubernetes API server. This automation reduces human error and enhances security within clusters. The performance and reliability of the Sentinel operator were evaluated using Red Hat Operator Scorecard and chaos engineering practices.

Figures

Figures reproduced from arXiv: 2411.16639 by the authors.

**Figure 2.** presents the three-tier architecture used to design the K8s-Pro Sentinel. This architecture pattern, widely adopted in software development, segregates an application into three interrelated components, each tasked with distinct functionalities [27] [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗

**Figure 4.** Mesure latency while creating RBAC type Secret object. TABLE I. LATENCY (MEASURED IN SECONDS) The evacuation of creating and modifying BaseSecret, LocalEncryptionProvider Secret, and RBAC type Secret was conducted using Chaos experiments [29]. Following chaos engineering principles, authors intentionally introduced failures into the system (e.g., introducing Secrets that are not secured to the cluster, or Create Sec… view at source ↗

Figures from the paper (6 more)

**Figure 5.** Figure 5: Spec block exist test result 2) Bundle validation: Validates bundle manifests, identifies content errors, and suggests corrections [PITH_FULL_IMAGE:figures/full_fig_p003_5.png]

**Figure 6.** Figure 6: Bundle validation test result Function From GUI From CLI Installing operator N/A 4s Deploying Custom Resource 2s 1s Secret validation 3s 2s [PITH_FULL_IMAGE:figures/full_fig_p003_6.png]

**Figure 7.** Figure 7: Exposed API validation test result 4) Owned CRDs have resources listed: Checks that CRDs list all utilized resources in their resources subsection, ensuring comprehensive tracing and documentation [PITH_FULL_IMAGE:figures/full_fig_p004_7.png]

**Figure 8.** Figure 8: Owned CRDs have resources listed test result 5) Spec fields with descriptors: Ensures each field in the spec sections of Custom Resources includes a descriptor in the Cluster Service Version (CSV) [PITH_FULL_IMAGE:figures/full_fig_p004_8.png]

**Figure 9.** Figure 9: Spec fields with descriptors test result 6) Status fields with descriptors: Confirms that every field in the status sections of Custom Resources is paired with a descriptor in the Cluster Service Version (CSV) for accurate status reporting [PITH_FULL_IMAGE:figures/ful…

**Figure 10.** Figure 10: Status fields with descriptors test result TABLE II. SUMMARY OF OPERATOR SDK SCORECARD TESTING V. CONCLUSION This study addresses vulnerabilities in Kubernetes by mitigating human error and misconfiguration of Secret Objects through the novel open-source tool, K8s Pro…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

20 extracted references · 12 canonical work pages

[1]

microservices

K8s Pro Sentinel: Extend Secret Security in Kubernetes ClusterKavindu Gunathilake Department of Computer Science Informatics Institute of Technology Sri Lanka kavindu.2019822@iit.ac.lk Indrajith Ekanayake Department of Computer Science Informatics Institute of Technology Sri Lanka indrajith.e@iit.ac.lk Abstract— Microservice architecture is widely adopted...

work page 2011
[3]

Smith and G

B. Smith and G. Linden, ‘Two Decades of Recommender Systems at Amazon.com’, IEEE Internet Comput., vol. 21, no. 3, pp. 12–18, May 2017, doi: 10.1109/MIC.2017.72

work page doi:10.1109/mic.2017.72 2017
[4]

Jamshidi, C

P. Jamshidi, C. Pahl, N. C. Mendonça, J. Lewis, and S. Tilkov, ‘Microservices: The Journey So Far and Challenges Ahead’, IEEE Softw., vol. 35, no. 3, pp. 24–35, May 2018, doi: 10.1109/MS.2018.2141039

work page arXiv 2018
[5]

A. R. Sampaio et al., ‘Supporting Microservice Evolution’, in 2017 IEEE International Conference on Software Maintenance and Evolution (ICSME), Sep. 2017, pp. 539–543. doi: 10.1109/ICSME.2017.63

work page doi:10.1109/icsme.2017.63 2017
[6]

Burita, ‘Information Analysis on Facebook’, in 2019 Communication and Information Technologies (KIT), Oct

L. Burita, ‘Information Analysis on Facebook’, in 2019 Communication and Information Technologies (KIT), Oct. 2019, pp. 1–5. doi: 10.23919/KIT.2019.8883471

work page arXiv 2019
[7]

Burns, B

B. Burns, B. Grant, D. Oppenheimer, E. Brewer, and J. Wilkes, ‘Borg, Omega, and Kubernetes’, Commun. ACM, vol. 59, no. 5, pp. 50–57, Apr. 2016, doi: 10.1145/2890784

doi:10.1145/2890784 2016
[8]

Malviya and R

A. Malviya and R. K. Dwivedi, ‘A Comparative Analysis of Container Orchestration Tools in Cloud Computing’, in 2022 9th International Conference on Computing for Sustainable Global Development (INDIACom), Mar. 2022, pp. 698–703. doi: 10.23919/INDIACom54597.2022.9763171

arXiv 2022
[10]

G. M. Diouf, H. Elbiaze, and W. Jaafar, ‘On Byzantine fault tolerance in multi-master Kubernetes clusters’, Future Gener. Comput. Syst., vol. 109, pp. 407–419, Aug. 2020, doi: 10.1016/j.future.2020.03.060

work page doi:10.1016/j.future.2020.03.060 2020

Show all 20 references

[11]

Under-reported

D. B. Bose, A. Rahman, and S. I. Shamim, ‘“Under-reported” Security Defects in Kubernetes Manifests’, in 2021 IEEE/ACM 2nd International Workshop on Engineering and Cybersecurity of Critical Systems (EnCyCriS), Jun. 2021, pp. 9–12. doi: 10.1109/EnCyCriS52570.2021.00009

2021
[12]

Poniszewska-Marańda and E

A. Poniszewska-Marańda and E. Czechowska, ‘Kubernetes Cluster for Automating Software Production Environment’, Sensors, vol. 21, no. 5, Art. no. 5, Jan. 2021, doi: 10.3390/s21051910

2021 doi
[14]

de Silva, S

M. de Silva, S. Daniel, M. Kumarapeli, S. Mahadura, L. Rupasinghe, and C. Liyanapathirana, ‘Anomaly Detection in Test Case Test Result Spec block exist Pass Bundle validation Pass Exposed API validation Pass Owned CRDs have resources listed Pass Spec fields with descriptors Fa...

2022
[15]

D. C. Kalubowila, S. M. Athukorala, B. A. S. Tharaka, H. W. Y. R. Samarasekara, U. S. S. Samaratunge Arachchilage, and D. Kasthurirathna, ‘Optimization of Microservices Security’, in 2021 3rd International Conference on Advancements in Computing (ICAC), Dec. 2021, pp. 49–54. d...

2021
[18]

H. S. Nalawala, J. Shah, S. Agrawal, and P. Oza, ‘A Comprehensive Study of “etcd”—An Open-Source Distributed Key-Value Store with Relevant Distributed Databases’, in Emerging Technologies for Computing, Communication and Smart Cities, P. K. Singh, M. H. Kolekar, S. Tanwar, S. ...

2022 doi
[19]

aws-samples/k8s-rbac-iam-java-operator. (Jan. 24, 2024). Java. AWS Samples. Accessed: Sep. 17,

2024
[22]

Rahman, F

A. Rahman, F. L. Barsha, and P. Morrison, ‘Shhh!: 12 Practices for Secret Management in Infrastructure as Code’, in 2021 IEEE Secure Development Conference (SecDev), Oct. 2021, pp. 56–62. doi: 10.1109/SecDev51306.2021.00024

2021 arXiv
[24]

Rahman, S

A. Rahman, S. I. Shamim, D. B. Bose, and R. Pandita, ‘Security Misconfigurations in Open Source Kubernetes Manifests: An Empirical Study’, ACM Trans. Softw. Eng. Methodol., vol. 32, no. 4, pp. 1–36, Oct. 2023, doi: 10.1145/3579639

2023 doi
[28]

kubernetes/sample-controller. (Sep. 17, 2024). Go. Kubernetes. Accessed: Sep. 18,

2024
[29]

Basiri et al., ‘Chaos Engineering’, IEEE Softw., vol

A. Basiri et al., ‘Chaos Engineering’, IEEE Softw., vol. 33, no. 3, pp. 35–41, May 2016, doi: 10.1109/MS.2016.60

2016 doi
[2021]

2021, pp

New York, NY, USA: Association for Computing Machinery, Aug. 2021, pp. 1689–1690. doi: 10.1145/3468264.3473495

2021
[2024]

Available: http://arxiv.org/abs/1606.04036

[Online]. Available: http://arxiv.org/abs/1606.04036

arXiv

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.

[1] [1]

microservices

K8s Pro Sentinel: Extend Secret Security in Kubernetes ClusterKavindu Gunathilake Department of Computer Science Informatics Institute of Technology Sri Lanka kavindu.2019822@iit.ac.lk Indrajith Ekanayake Department of Computer Science Informatics Institute of Technology Sri Lanka indrajith.e@iit.ac.lk Abstract— Microservice architecture is widely adopted...

work page 2011

[2] [3]

Smith and G

B. Smith and G. Linden, ‘Two Decades of Recommender Systems at Amazon.com’, IEEE Internet Comput., vol. 21, no. 3, pp. 12–18, May 2017, doi: 10.1109/MIC.2017.72

work page doi:10.1109/mic.2017.72 2017

[3] [4]

Jamshidi, C

P. Jamshidi, C. Pahl, N. C. Mendonça, J. Lewis, and S. Tilkov, ‘Microservices: The Journey So Far and Challenges Ahead’, IEEE Softw., vol. 35, no. 3, pp. 24–35, May 2018, doi: 10.1109/MS.2018.2141039

work page arXiv 2018

[4] [5]

A. R. Sampaio et al., ‘Supporting Microservice Evolution’, in 2017 IEEE International Conference on Software Maintenance and Evolution (ICSME), Sep. 2017, pp. 539–543. doi: 10.1109/ICSME.2017.63

work page doi:10.1109/icsme.2017.63 2017

[5] [6]

Burita, ‘Information Analysis on Facebook’, in 2019 Communication and Information Technologies (KIT), Oct

L. Burita, ‘Information Analysis on Facebook’, in 2019 Communication and Information Technologies (KIT), Oct. 2019, pp. 1–5. doi: 10.23919/KIT.2019.8883471

work page arXiv 2019

[6] [7]

Burns, B

B. Burns, B. Grant, D. Oppenheimer, E. Brewer, and J. Wilkes, ‘Borg, Omega, and Kubernetes’, Commun. ACM, vol. 59, no. 5, pp. 50–57, Apr. 2016, doi: 10.1145/2890784

doi:10.1145/2890784 2016

[7] [8]

Malviya and R

A. Malviya and R. K. Dwivedi, ‘A Comparative Analysis of Container Orchestration Tools in Cloud Computing’, in 2022 9th International Conference on Computing for Sustainable Global Development (INDIACom), Mar. 2022, pp. 698–703. doi: 10.23919/INDIACom54597.2022.9763171

arXiv 2022

[8] [10]

G. M. Diouf, H. Elbiaze, and W. Jaafar, ‘On Byzantine fault tolerance in multi-master Kubernetes clusters’, Future Gener. Comput. Syst., vol. 109, pp. 407–419, Aug. 2020, doi: 10.1016/j.future.2020.03.060

work page doi:10.1016/j.future.2020.03.060 2020