I want to deploy WSO2 API Manager with Kubernetes.
Should I use Google Cloud?
Is there another way?
The helm charts 1 for APIM can be deployed on GKE, AKS, EKS, etc. You can even deploy the all-in-one simple deployment pattern 2 in a local Kubernetes cluster like minikube, etc.
You might have to use a cloud provider for more advanced patterns since they require more resources to run.
All these charts are there as samples to get an idea about the deployment patterns. It is not recommended to deploy those as it is in real production scenarios as the resource requirements and infrastructure vary according to the use cases.
1 - https://github.com/wso2/kubernetes-apim
2 - https://github.com/wso2/kubernetes-apim/tree/master/simple/am-single
I am new to Spinnaker and when using the UI (with Spinnaker for GCP), it says for rollout strategies
Allow Spinnaker to associate each ReplicaSet deployed in this stage with one or more Services and manage traffic based on your selected rollout strategy options.
Does this mean that its rollout strategies are "only" Kubernetes-Replicaset based, but doesn't have support for, for example, Istio Traffic Management and Virtual Services? (or does the UI only offer limited option, compared to, say, an API)
Probably the same question can be asked for canary analysis?
I have 2 namespaces in my kubernetes cluster: development and production. I'm currently adding a third namespace: staging.
I'm NOT using terraform with which this task would have been supposedly simpler.
I'm looking for solutions within the GCP ecosystem to provision a workload in the staging namespace with all the environment variables and configurations of the development namespace.
Please check my answer to similar question here. Unfortunately there is no ready solution for that within GCP, especially if you want to migrate workload from the existing cluster between different namespaces. However you can use for that purpose Heptio Velero. It's nicely described in this article.
I cannot find any articles answering question: Is it safe/right to deploy Spinnaker to same Kubernetes cluster which Spinnaker will manage? Mainly I mean for production, HA deployments.
I think the architectures of Spinnaker and Kubernetes compliment each other very well, and running Spinnaker in the same K8s cluster it is managing is definitely safe.
As per your comment in #mdirkse's answer, there is a codelab, which is official Spinnaker documentation, that explains how to create a set of basic pipelines for deploying code from a Github repo to a production Kubernetes cluster in the form of a Docker container.
In this documentation, it specifically states the following:
We will be deploying Spinnaker to the same Kubernetes cluster it will be managing. ...
Not sure if this is exactly what you are looking for though.
I'm not sure about "right", but I'd definitely say that it is safe to run Spinnaker on the same Kubernetes cluster that it manages, if you set it up right. Kubernetes (and Docker) gives you all the tools you need to properly separate Spinnaker from the other things running on the cluster (namespaces, quotas, node affinities etc). Indeed the whole point of Kubernetes is to be able to easily run software in an HA/fault tolerant way, and since Spinnaker consists of a collection of stateless microservices it really plays to the strenghts of k8s.
I'm trying to dig into Rancher, and was wondering if having Rancher plugged in with Kubernetes has any additional benefits over Cattle which is Rancher's in home orchestration framework. So far, I haven't been able to figure out why someone would opt for Rancher with Kubernetes. Does it only help ease out the initial setup of Kubernetes? How do these options differ from a stand alone setup of Kubernetes ?
There is now a very good answer to this. Rancher just moved 100% into Kubernetes by announcing Rancher 2.0: http://rancher.com/announcing-rancher-2-0/. It does not use Cattle anymore.
After 1+ year of using Rancher + Cattle and Kubernetes in production simultaneously, I can share some personal observations, but first let me share some thoughts on Kubernetes vs Rancher + Cattle:
Kubernetes is astonishingly flexible and designed to be extendable. There are two pillars on which Kubernetes cluster stands - kube-apiserver as a main unit and etcd as a storage. Other basic components are vital for a cluster, but they were designed to use kube-apiserver's API as any Kubernetes extension should. You can design your cluster the way you need, use different network providers, authentication/authorization services, volume providers and substitute almost every component in cluster - and if configured correctly your extended Kubernetes cluster will be more stable than basic Cattle cluster in almost any case, not speaking of Cattle extensions.
Kubernetes has a lot of useful out-of-the-box features for persisting your data, keeping your data secret and control access to it. This is important part, rancher-nfs is quite fragile, moreover, NFS-storage is the only more or less stable option you have in Cattle to keep volumes, not mentioning local storage.
Kubernetes is an overkill for non-frequent deployments and development in a small team. No doubts, Cattle has been created as a simple clone of Kubernetes and has inherited its basic concepts of namespaces, pods, scheduling, etc., yet making it very easy to deploy and maintain a cluster, making it useful for developers with no understanding of containerisation and networking. Due to its simplicity it became pretty unusable for heavy and dynamically changing production projects.
Kubernetes community is growing fast, being supported by cloud providers and by uncountable number of open-source project and startups, so it's wiser to learn Kubernetes than Cattle, which is one foot in grave now.
And finally - Cattle is unstable, very unstable. Especially if you plan to use it with bare metal. Believe me, you don't want to use Cattle in production.
And speaking about Rancher + Kubernetes tied together - it's a very nice combination, Rancher web UI makes Kubernetes concepts simpler in a good way, cluster maintenance and provisioning become much easier, but there's always some "buts": Rancher 2.0 is very unstable, too, bugs make it unusable for production now. Can't say anything about Rancher 1.x + Kubernetes.
In our experience,
Cattle is just a toy. It's just suit for development or some small environment. If you used Cattle in PROD, you will know what I say.
But Rancher is far more concise and simple than k8s.
So I'm looking forward to the Rancher 2.0,
Rancher 2.0 is a complete container management platform built on Kubernetes
rancher v2 is more complicated as ks8 is complicated but its contain great features to manage containers ,for pros and cons between cattle rancher v1 and ks8 rancher v2 here some of most important differences :
1- rancher v1 cattle is more like docker-compose than modern orchestration tools and lack of support new storage drivers or real high available loadbalancer approach like ingress in ks8.
2- rancher v1 have great community catalogs that make create of high available services lots more easy but its kind of tricky to resolve problems that can happen.
3 - rancher v2 support community catalogs and helm but need more contribution to become stable and great as v1 was but k8s instead is completely stable and using kubectl to manage pods and resources is easy.
my opinion is use rancher v2 if you want to start docker orchestration , ks8 have great cli tools but when you need upgrade container or change configuration rancher web gui can help effectively.