KOPS and Amazon EKS have their own Pros and Cons, Selection of any technology should be based on various factors including the use case and cost of maintainability.
We have shared our experience with KOPS and EKS below:
KOPS | Amazon EKS |
---|---|
Selection of Kubernetes cluster version e.g. it support various versions. | Amazon Controlled, and the recent deployments are slow than the mainline. |
Initial instrumentation as by default, it will not add any RBAC or User management. | Tightly coupled with Amazon IAM, and leverage the open source AWS authenticator for Access control. https://github.com/kubernetes-sigs/aws-ia m-authenticator |
Fully managed by yourself It can be an advantage or disadvantage for the future use. | Managed by AWS |
Ensuring etcd cluster is up and running. | Managed by AWS |
Ensure Kube master node services are up and running. E.g. Kube api server, kube DNS, kube-scheduler etc | Managed by AWS |
CNI integration. Various options: Flannel Amazon-vpc-routed-eni Kubenet (default) | VPC level networking is already implemented at the network level, it means, the container routes will be published by default through Amazon using amazon-vpc-cni-k8s |
KOPS maintains its state file in a S3 bucket. | Maintained by AWS |
Full control of Kubernetes. | |
Instance groups with tainting/labeling. | EKS doesn’t support and not even supported by EKSCTL. |
Rotating the cluster. | Manually, and one by one instance. |
Our Experience with KOPS/EKS:
We have enabled one of our customers to use KOPS for more than 200+ machines. The KOPS was installed on AWS nodes in different availability zones, if the cluster contains more than 50 nodes, we highly recommend more than 5 Master nodes for KOPS, the initial management of KOPS is slightly more than provisioning of EKS cluster, but it will give you
We have used a tool of customer’s choice to provision the Kubernetes Cluster, If your infrastructure is already based in