|
|
|
|
|
by shatteredspace
1672 days ago
|
|
Preface this with I don't hate K8s. I see it as a solution and something to be used when the situation calls for it. I've used it quite a bit from directly interacting with it using Go and it's Go modules, using it's REST API, via kubectl, and via those that provide front-ends for it (Rancher). I see it as all about use-case, staffing, and what kind of instance you are using. Cloud-based? A-lot more freedom in being able to just deploying a cluster and not worry about much, on-prem based? Well dang now you've opened up having to be the one to update those nodes yourself - hope that you are a systems admin as well and have the time to perform said updates. Situation A - I'd like to introduce you to Docker Swarm. Secret management - sure K8s can do it, but I'm almost certain your organization as well as mine has accepted a vault of some sort that is not in K8s for end users and services to use. Now you just have to write your applications to use this. Network policies - while K8s can do this, I don't know if this is the strongest argument to use K8s or just a nice cherry on top. It feels like just a shift in responsibility or adding more granularity from your network security team. When does the situation call for it (in my opinion)? Your company has embraced the methodology of work with staffing for it and you have more than a handful of apps on more than a handful of nodes. |
|