How Can I enable batch/v2alpha1API for a google container engine cluster ?
Which is by passing
--runtime-config=batch/v2alpha1=true
to the API server .
I'm using version kubernetes 1.7.6.
Where should I go to enable that !!!
You cannot change the runtime configuration of the Kubernetes apiserver in Google Container Engine and by policy alpha APIs are not enabled because they have no official support policy. From https://kubernetes.io/docs/concepts/overview/kubernetes-api/:
Alpha level:
The version names contain alpha (e.g. v1alpha1).
May be buggy.
Enabling the feature may expose bugs.
Disabled by default.
Support for feature may be dropped at any time without notice.
The API may change in incompatible ways in a later software release without notice.
Recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of long-term support.
If you want that particular alpha API enabled in Google Container Engine, you can create an alpha cluster.
Related
Auto-Scaling is OFF and Cluster-Upgrade is OFF but still dont know why cluster get restarted today morning. All Nodes got replace/change and All Pods got restarted
Reason is that it got restarted due to node got upgrade from 1.22 to 1.23 version
I have Regular Version in GKE Cluster
You should double-check with Google support (if you have a support plan), but I know from painful experience that if you're running a version of GKE that falls out of support, they may force-upgrade you to keep you within support, even if you have cluster upgrade turned off -- unless you use a maintenance exclusion.
The REGULAR channel release notes are here: https://cloud.google.com/kubernetes-engine/docs/release-notes-regular
The December 5th one is probably the one that affected you.
If you disable node auto-upgrade, you are responsible for ensuring that the cluster's nodes run a version compatible with the cluster's version, and that the version adheres to the Kubernetes version and version skew support policy.
Nodes running versions that have reached their end of life date are auto-upgraded even when auto-upgrade is disabled, to ensure supportability and version skew compatibility.
For more information you can read this link.
You can also check this link for temporary mitigation.
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.
I've seen some argument on how we should not run a database on Kubernetes in production, for various reasons, e.g, https://www.youtube.com/watch?v=Nosa5-xcATw&feature=youtu.be&t=1080. And how PetSet / StatefulSet is still on beta as of 1.5.
I wonder if the same holds true for OpenShift Origin. It is built on top of Kubernetes, but maybe, it has some "bells and whistles" for running database on production?
From what I see in https://github.com/openshift/origin:
Stateful Sets are still being actively developed and no backwards compatibility is guaranteed until 1.5 is released. Starting in 1.5, Stateful Sets will be enabled by default and some backwards compatibility will be guaranteed.
Statefulsets were recently available in Openshift (April 2017), and from what I see here: https://blog.openshift.com/kubernetes-state-storage/ in principle I do not see anything that differentiates using StatefulSets in Kubernetes and Openshift.
I'm trying to learn about Heroku's deployment capabilities. I've used Google App Engine in the past and have found its support for multiple simultaneously-accessible live application versions useful, for example, in order to test a new version in the production context before making it the default, running a specially-instrumented version in parallel with the default version to debug a problem specific to the production environment (e.g. production data), for A/B testing, traffic splitting, gradual rollout, etc.
Does Heroku have support for this kind of thing? My Googling has not turned up anything.
No, it doesn't offer support for this right now.