There are a lot of options available for deploying kubernetes including Redshift, CoreOS, hosted options. I was wondering if there is anyone exploring kubeadm for non-prod enironments. Is it a viable option for standing up a multi-node k8s cluster. Thanks in advance.
Yes, kubeadm is a viable option for a non-production cluster, but it is currently (late 2017) undergoing significant development. Two features that I would watch closely are support for upgrades, and support for HA masters. Currently kops has support for both, so you might consider that as an alternative if you need those features.
There are many other differences between the two, so its impossible to recommend one over the other, but in general, I would recommend kubeadm for learning about kubernetes (especially the provisioning aspect, and what is required for a running cluster) and kops if you just need a mostly-production-ready cluster.
(I don't have experience with other provisioning tools, so I can't comment on them, but there are many worth looking at.)
In the future, the kubeadm maintainers want kubeadm to provide the plumbing and so that other provisioning tools can build off of it in a more opinionated way.
Related
I am an IoT Infrastructure Engineer student at Howest Kortrijk. For a project in my final year I have to figure out the following question, "How to build a failover Kubernetes cluster between an on-premises and cloud environment using Rancher?".
I have sat up a k3s cluster myself and tried to install Rancher, but without success. So much for my problems with the technical solution. In fact, I am left with another question. Is it actually still relevant to set up everything yourself and dabble with this.
Wouldn't it be better to run everything in the cloud?
Surely there are plenty of solutions for this?
Are running things on-premises still pertinent?
I myself don't have much experience with this yet. But hopefully there are experts here with a bit more experience who can answer these questions.
I recently attended an Azure (for developers) session and it got me thinking.
I have been working with kubernetes in a staging environment for a couple of month and want to switch to production, I came across a tool called Rancher almost 2 weeks ago and since then am going through their documents.
It was recommended by the developers and also in the community not to use rancher in production kubernete and preferably create a separated cluster for that and add an agent to your main production cluster from that one.
However in the latest stable version, there is actually an option you can tick to use the rancher only for local cluster so this question came to my mind that:
If the latest stable version of rancher is modified to be deployed on production cluster itself rather than having dedicated cluster? and if there is any security or restarting issues can happen that deletes all the configurations for other components on cluster
Note: on another staging environment I installed on the local clustor an instance of wordpress and ghost and both were working fine.
I still think the best option for you would be to have fully accessible own cluster and you wont be dependent to rancher cloud solutions. I am not saying Rancher is bad - no. Just If you are talking about PRODUCTION environment - my personal opinion cluster should be own. Sure arguable topic.
What I can mention also here - you can use any of Useful Interactive Terminal and Graphical UI Tools for Kubernetes . for example Octant
Octant is a browser-based UI aimed at application developers giving
them visibility into how their application is running. I also think
this tool can really benefit anyone using K8s, especially if you
forget the various options to kubectl to inspect your K8s Cluster
and/or workloads. Octant is also a VMware Open Source project and it
is supported on Windows, Mac and Linux (including ARM) and runs
locally on a system that has access to a K8S Cluster. After installing
Octant, just type octant and it will start listening on localhost:7777
and you just launch your web browser to access the UI.
I have production stage hosted in Google Kubernetes Engine with Kubernetes version 1.12.9-gke.15.
My team is planning to upgrade it to Kubernetes version 1.13.11-gke.5.
A capture of list of Kubernetes version
I have read some articles to upgrade Kubernetes. However, they use kubeadm not GKE.
How to update api versions list in Kubernetes here's a example that use GKE.
If you guys have experience in upgrading kubernetes cluster in GKE or even kubeadm. Please share what should i do before upgrading the version ?
Should i upgrade the version to 1.13.7-gke.24 and then to 1.13.9-gke.3 and so on ?
You first should check if you are not using any depreciated features. For example check the Changelogs for version 1.12 and 1.13 to make sure you won't loose any functionality after the upgrade.
You will have to remember that if you have just one master node you will loose access to if for few minutes while control plane is being updated. After master node is set then worker nodes will follow.
There is a great post about Kubernetes best practices: upgrading your clusters with zero downtime, which talks about location for nodes and a beta option being Regional
When creating your cluster, be sure to select the “regional” option:
And that’s it! Kubernetes Engine automatically creates your nodes and masters in three zones, with the masters behind a load-balanced IP address, so the Kubernetes API will continue to work during an upgrade.
And they explain how does Rolling update works and how to do them.
Also you might consider familiarizing yourself with documentation for Cluster upgrades, as it discusses how automatic and manual upgrades work on GKE.
As you can see from your current version 1.12.9-gke.15 you cannot upgrade to 1.14.6-gke.1. You will need to upgrade to 1.13.11-gke.5 and once this is done you will be able to upgrade to latest GKE version.
GCP Kubernetes is upgraded manually and generally does not require you to do much. But if you are you looking for manual upgrade options maybe this will help.
https://cloud.google.com/kubernetes-engine/docs/how-to/upgrading-a-cluster
A point worth mentioning is too, make sure you have persistence volumes for services that require to do so viz. like DB, etc And for these, you will have to back them up manually.
Hoping that there is some good insight into how to handle orchestration amount microservices in an on prem smaller company environment. Currently, the systems that we are looking to convert from monolithic to microservices like the rest of the world :).
The problem I'm having with as an architect, is justifying the big learning curve and server requirements with the resources we have at the moment. I can easily see us having 50ish microservices, which I feel could be on that line of using kubernetes or not.
The thing is, if we don't, how do we monitor if it is on-prem. We do use Azure Devops, so I'm wondering if this would safice for deployment parts.
Thanks!
This comes down to a debate over essential vs accidental complexity. The verdict is in from companies that k8s strikes a good balance vs swarm and other orchestrators are barely talked about in the industry.
https://www.reactiveops.com/blog/is-kubernetes-overkill
The platforms that build on kubernetes are still emerging to offer a simpler interface for those wanting a higher level of abstraction but aren't mature enough yet. GKE offers a very easy way to just deal with workloads, AKS is still maturing so you will likely face some bugs but it is tightly integrated with Azure Devops.
Microsoft is all-in on k8s although their on-prem offering doesn't seem fully fledged yet. GKE on-prem and Openshift 4.1 offer fully managed on-prem (if using vSphere) for list price of $1200/core/year. https://nedinthecloud.com/2019/02/19/azure-stack-kubernetes-cluster-is-not-aks/
Other ways of deploying on prem are emerging so long as you're comfortable with managing the compute, storage and network yourself. Installing and upgrading are becoming easier (see e.g. https://github.com/kubermatic/kubeone which builds on the cluster-api abstraction). For bare metal ambitious projects like talos are making k8s specific immutable OSes (https://github.com/talos-systems/talos).
AWS is still holding out hope for lock-in with ECS and Fargate but it remains to be seen if that will succeed.
I'm new in kubernetes and I have some doubts about the installation of kubernetes on centos 7, I have read some documentation on some links:
https://kubernetes.io/docs/getting-started-guides/kubeadm/
https://kubernetes.io/docs/getting-started-guides/centos/centos_manual_config/
But I not undestanding which procedure to follow, on first link it show how to install it using kubeadm but at the end of the article on "Limitations" appear that this tool "is a work in progress and these limitations will be addressed in due course", on second link I need to have at least 2 machines, so my question is which is better to use if I will to install it like production.
Thanks in advance
kubeadm.
kubeadm now can support for multi masters, which is considerable for production.
The kubeadm also supplies a secure deployment. It automatically configs TLS settings or RBAC for the cluster, which is not included in the "manual installation page".
My advice: play kubeadm in your development environment first, so that you see how kubeadm deploys a Kubernetes cluster, many components can be deployed by Kubernetes itself. Then, you decide whether use it in your production.
You can follow up the repository made by one of our developer with an additional thing of Horizontal Pod autoscaling of stateless application.
https://github.com/vevsatechnologies/Install-Kubernetes-on-CentOs