For your first question:
When using a Kubernetes LoadBalancer or Ingress, is the normal
NodePort used as the underlying connection point?
Technically it depends on the cloud network for LoadBalancers (e.g. Google Compute Engine does not technically require this although one may be created). However, I believe a NodePort and ClusterIP are generally ...
I would suggest at least one for production and one for npe. The nginx-ingress helm chart appears to only support setting a scope to all namespaces or just one namespace (a frustrating limitation not in other ingress controller options):
Try to use only n1-standard-1 nodes and let the autoscaler do it's magic.
If you can accept some downtime (and eventually some failures of the CI/CD jobs that should be fixed when you retry) you can use preemptible nodes.
Migrate stateless apps to Cloud Run.
Follow this guide to reduce resource consumption on your cluster.
Given that you mentioned rarely using some k8s resources, you could explore some alternatives:
With gcloud SDK you could create scripts to be executed for the periods you want to reduce GKE nodes (even to zero) during periods you're not using it
With Google Cloud Functions (GCF) you can create some python/Node.js/Go script to access GKE APIs and also ...
Yes. Check out this example for a nice tutorial to get started.
Per the StorageOS documentation you shouldn't even have to worry about this. Just let StorageOS handle the namespaces for you with one StorageOS install.
the definition of the replicated pods are always a copy-paste of a pod template file
This behavior is implemented by Kubernetes itself: it takes the template part of the deployment spec and creates replicas identical pods.
The corollary to this is that you don't need to manually write out the pod spec as a separate object. Including it in the template ...
Yes you can create resources (including pods) from a url yaml using kubectl. However, just because you pointed to a remote url does not mean that the resource will automatically update. You will need to either re-deploy when the remote yaml is updated, develop/integrate with a service that handles this, or look into using a tool such as helm to help manage ...
If you can keep one common deployment strategy across both that would be simpler and less effort from the ops side of things. Kubernetes seems to be a great choice for the cloud orchestration layer at this point in time. Does Kubernetes make sense for the on-prem side though? If you're not planning on each on-prem install including 5-10 servers to spread ...
Check https://github.com/helm/helm/issues/3130, this might help.
I followed the instruction in the post:
kubectl --namespace kube-system create serviceaccount tiller
kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller
helm init --service-account tiller --upgrade
This works for me.
(Kublr CTO) Take a look at Kublr - https://kublr.com/
It is designed exactly for a use-case like this: centralized management and operations of multiple Kubernetes clusters in multiple and/or heterogeneous target environments. Currently it supports AWS, Azure, Google Cloud, vSphere, vCloud Director, and on-prem/BYOI (Bring Your Own Infrastructure mode.