Recently I migrated some Kubernetes clusters, managed by Amazon EKS. The clusters were running in public subnets, so I wanted to make them more secure by utilizing private and public subnets where needed. Changing networking settings is not possible once you create the service in AWS. Any service, not just EKS. Since I already had Velero installed for backups with S3 provider, the most natural thing was to use it to restore all resources on the new cluster as well. ...
Even though I'm not Kubernetes Dashboard user, I understand why it is the easiest way for most people to interact with their apps running on top of Kubernetes. If you are interacting with it daily or managing the cluster itself, you are probably more fine with CLI, aka kubectl. Kubernetes Dashboard is easy to install, but you might want to have it per namespace and to limit what users can do. Let's see how to install and configure it for ...
I will say that "starting" a Kubernetes cluster is a relatively easy job. Deploying your application to work on top of Kubernetes requires more effort especially if you are new to containers. For people that worked with Docker this can also be a relatively easy job, but of course, you need to master new tools like Helm for example. Then, when you put all together and when you try to run your application in production you will find out there ...