If you read until this paragraph, you may seems feel my arguments become
There are reasons for that.
We have seen that Kubernetes is not run on specific hardware by itself.
Its run on VM which may run on hypervisor or on top of another software that
abstract the CPU and memory in the real hardware.
With this additional layer we will have additional infrastructure to manage,
another latency to application.
I have not experienced it may self, but I hope I will never have to
experience the joy of debugging network issue on this layer.
The cost of premature scaling.
As we have discussed on the "What is Kubernetes?", we will pay for VMs (three
at least), a load balancer, and an external static IP for single application
An application that previously can handle traffics with 1 CPU and 2 GB memory
now run inside three nodes with 2 CPU 4 GB, with probably 75% unused
If you can afford the cost (as in money), then go with it.
Logging, alerting, and monitoring.
Deploying an application that can "scale" does not end up with just packing it
in container and let the Kubernetes handle the rest.
The second major task in infrastructure is to gather information about all
resources, including metrics of CPU, memory, data, networks, application logs,
and so on.
In case of request fail on application level, we need to know where to look at
it, so we need a central logging.
In case of timeout we need to know what cause it, does it cause by high CPU
usage in one of application which block the rest of request or because the
application itself, so we need an alert and monitoring.
Kubernetes recommended using Prometheus, if you were afraid of vendor
lock-in (you basically already locked in if you use one of cloud provider
You will need to setup a Prometheus, and some graphical interface like Grafana
for dashboard, but that is just for alerting and monitoring.
For logging, you will need setup another stack, like ELK because
is not an event logging system.
Finally, now you have one application plus two or more containers to manage
Or … you could use one single binary monitoring, like influxdb.
In GCP, they already provide native logging and monitoring, so we did not
need to setup or install another applications.
Unfortunately for logging we need to setup CloudFunctions that consume the
log from Pub/Sub that published by Log Viewer.
Once again, there is a price for everything in the cloud.
Does the original assumption about Kubernetes still stand?
You decide, but in my opinion maybe you need a good logging, alerting, and
monitoring tools for your infrastructure.