I'm a bit confused about what version of kubernetes I need and what method to use to deploy it.
I have deployed 1.5 the manual way. But there is a fix we need (PR-41597). This fix doesn't seem to have been merge in 1.5 but it is in 1.6.
But I can't find any way to install 1.6 without kubeadm. The documentation clearly states that kubeadm should not be used in production. And the kubeadm way does not allow for upgrades anyway. So I would prefer to stay away from kubeadm.
So I either have to get that fix merged in 1.5 or find a way to install 1.6 without kubeadm. Am I missing something here? Any help would be much appreciated. Thanks.
There are plenty of ways to install Kubernetes 1.6:
https://kubernetes.io/docs/getting-started-guides
For example, CoreOS's CloudFormation installer supports 1.6: https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html#announcement-to-regular-users-of-kube-aws
As does Canonical's Juju templates: https://jujucharms.com/canonical-kubernetes/
If you need more specific assistance, please share more about your target environment (cloud/bare metal, OS, etc.).
A fairly low-level set of instructions can be found in https://github.com/kelseyhightower/kubernetes-the-hard-way; this may help you to tailor your own setup process.
For CentOS specifically, your best bet might be Kargo. This doesn't yet support 1.6, but it is active, so it should receive a 1.6 patch soon.
Related
I have deployed Grafana using helm chart and Terraform. We have exposed version as a input property so, we can run same script to update the version. I also have to support patching(any patch security etc.) similarly but I have no knowledge on how patches are released and how to apply them using Helm for Grafana..
Can someone please let me know ?
Thanks.
Thanks for taking a look at this. I am able to get solution for this, patches are released as minor versions and it is no different from version upgrade.
Thanks.
I encountered the same issue as in https://github.com/kubeflow/kubeflow/issues/6014 with my Kubeflow app. The fix is very simple (just a type casting), then I would like to fix it myself and redeploy Kubeflow.
The problem is that I am running a k3s cluster on my local machine where I have installed Kubeflow bundle via Juju. Then, I cannot change the source code.
How to modify Kubeflow source code before deploying it with Kubernetes?
Should I use the manifest installation https://github.com/kubeflow/manifests#installation ? or a totally different method?
Thank you.
The bug was fixed in the last version of the manifests, then I have finally installed kubeflow directly from the manifests.
But still I am in touch with one Kubeflow developer, I will post here the right way to do modify/deploy if interested.
You got to check out their Github repo. Make changes and use kustomize to install like explained in their wiki. If you check the example folder you can see that it points to all other component folders.
https://github.com/kubeflow/manifests#install-with-a-single-command
One another hack could be, just look for the controllers in Kubernetes eg., deployments created for kubeflow, then modify them; works only if your changes are only related to Kubernetes resource definitions. I suggest going with the first option above for a clean development experience, and hey, that way can you contribute back to the kubeflow project as well, if you changes will benefit others.
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.
Stupid question, but right now I'm deploying my Kubernetes cluster inside a VM. Is there a way to deploy it directly onto my machine?
I'm sure there has to be a easy fix but many of the docs I've read have been focused on deploying it inside VM.
I am assuming you are using some flavor of Linux; otherwise the information below won't be useful to you.
The easiest way of bare metal deployment ("onto your machine") is by using kubeadm. The documentation for that is excellent.
(If you need help with then reply with your exact OS flavor and version and I can edit this answer to reflect that specific situation.)
I'm trying to install Openstack Swift on CentOS 6.5. I only need object storage, so no other Openstack services will be installed. The problem I'm facing now is how to choose the auth system.
I've tried keystone, which seems a little bit too 'heavy' to me. After some Googling, I found swauth, but only a few results about it. So is it fine to use swauth as the auth system, even in a production installation? Thanks!
swauth is an alternative to keystone, Its note difficult to configure and operate. It depends on how big is going to be your installation, but from my experience its pretty feasible for a mid size deployment.