Note: I'm not a GCE user yet, the answer is based solely on documentation.
You could be Viewing Audit Logs in the Google Cloud Console, more specifically the Admin Activity logs:
Admin Activity logs contain log entries for API calls or other
administrative actions that modify the configuration or metadata of
resources. For example, the logs record ...
If you cordon and drain the nodepool before deleting it, then you can avoid downtime. I use the following script (shamelessly taken from the lazyweb elsewhere and adapted to my needs):
oldnodes=$(k get no --selector='cloud.google.com/gke-nodepool='$oldpool -o json | jq .items.metadata.name -r | xargs)
kubectl cordon --selector='cloud....
The simple answer is "yes" you can use Ansible for monitoring configuration, but you will have to do some extra work. As Vasily stated in their answer, Ansible does not have a built in triggering mechanism, so you need something to trigger the convergence of state. This can be done in several ways, the easiest being probably ansible-pull. As the ...
Not sure if you sorted this out, but I had to do something similar to get who started the instance so I can badger them into stopping the instance if they are not using it. I put together a Logging query:
resource.type = gce_instance AND (jsonPayload.event_subtype = compute.instances.start OR jsonPayload.event_subtype = compute.instances.insert ) AND ...
We use AWS's EC2 Plugin to spin up spot instances in AWS for our Jenkins master based on a single AMI, exactly as you describe, so Jenkins does support this behavior.
From a quick bit of searching Google Cloud seems to offer a similar solution;
Spotinst’s Jenkins Plugin helps you to do more with your Jenkins setup by allowing you to automatically ...
According to "TPU types and zones" TPUs are only available in a very limited set of regions, namely:
Europe, Middle East and Africa
europe-west4-a (Eemshaven, Netherlands)
us-central1-a, b, c and f (Council Bluffs, Iowa, USA)
asia-east1-c (Changhua County, Taiwan)
Note: not every SKU is available in each region, so double check ...
I'm not aware of any straightforward way to do that, without also running a different container to act as a middleware of sorts. You might want to look at one of the "Serverless" platforms. If your use case will fit that model, many of the docker/swarm/kubernetes serverless tools do what you're asking, but again, you're running other container(s) to manage ...
I faced this same problem when I was trying to automate GCP kubernetes deployment using Jenkins by putting image in GCR and I created one service account giving admin permission in gcp IAM.
I launched one VM giving same IAM service account access.
I installed gcloud sdk using here follows below command.
$gcloud auth configure-docker
From the Before you begin section of the instructions you referenced:
Make sure that you:
Have access to the registries which you will be pushing to and pulling from
This is specified in more details in Using Container Registry with Google Cloud Platform:
To push private Docker images from a Compute Engine instance, your
instance must ...
I think you can do this by Nodeselector. Firstly add a label for node selector in your daemonset config. Then label your nodes with the attached label. Now if you can set the autoscaling thresholds, it will be deployed on that node automatically on nodes that matches the label. Maybe you can tweak somehow to attach a label to your node when it is added to ...
It seems like you found your answer but let me add a little color since we went through the same thing.
Your yaml for the pods can have both a request and limit for both CPU and memory. Since you are discussing CPU here I'll stick with that. What you can do in order to utilize your resources efficiently is set your resource request to the minimum ...
1). Inside the node pool(lets call it old_node_pool ) that you want to delete, First Cordon all the nodes one after the other.
kubectl cordon <name_of_node_1>
kubectl cordon <name_of_node_2>
2). Drain all the nodes of the old_node_pool.
kubectl drain <name_of_node_1>
kubectl drain <name_of_node_2>