Hacker News Reader

Hacker News

Comment by thinkersilver | Hacker News Reader

Parent Full thread

thinkersilver

Kubernetes is becoming the lingua-franca of building infrastructure. Through CRDs and the kube api spec I can

- start an single application

- deploy a set of interconnected apps

- define network topologies

- define traffic flows

- define vertical and horizontal scaling of resources

And now I can define AWS resources.

This creates an interesting scenario where infrastructure can be defined by the k8s API resources and not necessarily have k8s build it. For example podman starting containers off a K8S deployment spec. It's an API first approach and its great for interoperability. The only downside is managing the yaml and keeping it consistent across the interdependencies.

View on HN

The Kubernetes resource model is the real lingua franca

I really wish fabric8, and more specifically kotlin k8 dsl[2] was getting more traction.

It removes the down side of yaml all over the place. It's missing the package management features of helm. But I have several jars acting as baseline deployments, and provisioning. It works really well, and I have an entire language. So I can map over a list of services, instead of do templating. The other big down side is a java run takes a minute or two to kick off

I was resilient to k8 for a long time. Complexity was secondary to cost, but Digital ocean has a relatively cheap implementation now. This commonality and perseverance of tooling is great.

I want metrics, a simple annotation. I want a secret injected from vault, just add an annotation. It's also cloud agnostic, so this logic can be deployed any where some one provides a k8 offering.

EKS was very powerful. As running service accounts via non managed clusters. Removed the need to pass an access key pair to the application. That service account just ran with a corresponding iam role.

[1] https://github.com/fabric8io/kubernetes-client [2] https://github.com/fkorotkov/k8s-kotlin-dsl

It's been a while since I've looked at Fabric8 but it had good java -> k8s integration and was great for writing k8s tools.

It appears though that Fabric8 is useful for solo java projects without complex dependencies on non-java projects or small java shop. It overlaps with where jenkins-x is going, which has made major strides in the last 24 months.

The original team that worked on Fabric8 lead by James Strachan all moved on from Redhat and many of them are working on Jenkins-x.

I’d love an option for the yaml to be changed to something akin to gRPC .proto configs.

Reply on news.ycombinator.com