Kelsey Hightower

Keynote: Kelsey Hightower, Crossplane Community Day, May 2020

[@BerndGoetz]

Thanks! That's a great conceptional positioning of crossplane and terraform in the context of k8s.

[@vimalneha]

It was helpful in building my understanding, I need to go further but it provides some clarity!

[@buvaneswariramanan5010]

Excellent! Your presentation brought clarity into my understanding.

[@Dr0rpheus]

Kelsey as usual you just helped me solve a problem I’ve been trying to understand/rectify/solve (and like a year ago, oy). For those of us who like writing modules in HCL and enjoy the verifiability and policy enforcement BEFORE code even hits the infra, this is exactly what I’ve been trying to achieve. Currently I have no idea how policy enforcement would work in a cross plane only environment - there’s gotta be some phase before any code reaches the cloud provider apis to really enforce anything. Building module definitions in HCL for CRDs can be incredibly useful for scoping declarative, modular, permission scoped workflows. Props to the Hashicorp team for working on this. Props to the cross plane team for recognizing and leveraging the control plane loops available in k8s for this type of infrastructure management. Now my question is: how do we develop patterns for logging and alerting on success/fail/unexpected change/cross plane-initiated change back? Meaning, if I have a user changing infra through some unexpected means (say, the web console) and cross plane wants to change it back, how does one alert and control the change back process in the hopes of a sounding data loss? Would that be done with more customized CRDs in cross plane? I imagine we would we enforce policy through code in something like Hashicorp Sentinel before those changes even hit the K8s control plane? Or, I suppose we just cut off change access to devs and let the robots manage the change that devs describe in code, and that’s the answer… Still doesn’t solve the problem of notifying people things are about to change because robots found a diff in our infrastructure from what Crossplane thinks it’s supposed to be.

[@Crossplane]

Since crossplane is Kubernetes-native, you can combine it with (almost) any other tool built or adapted to work in k8s. So, Crossplane is a part of a massive ecosystem and does not need to build tooling for everything, including notifications. You can, for example, use Argo Events or any other similar tool you are already using for notifications in your k8s clusters. The key is that you do not have to change the tools to use crossplane. Whatever you are using in k8s today, you can extend to crossplane.