This is a really great list and hits on all of the major usage quirks I've seen at large co's as their ops and development teams start to adopt Kubernetes.
I wonder about point number five, giving out kubectl access, even when an end-user is limited to a specific namespace. Kelsey Hightower once came and gave an in-person overview of Kubernetes and he was adamant, back in mid-2016, that the vast majority of Kubenetes API consumption would be abstracted from cluster consumers. (This was early days of tools like helm.)
I'm super curious to hear what others are doing. Has kubectl escaped to the wild? How are ops people dealing with that, especially the implications of `kubectl exec` and `kubectl portfw` direct to production from developer workstations?
I wonder about point number five, giving out kubectl access, even when an end-user is limited to a specific namespace. Kelsey Hightower once came and gave an in-person overview of Kubernetes and he was adamant, back in mid-2016, that the vast majority of Kubenetes API consumption would be abstracted from cluster consumers. (This was early days of tools like helm.)
I'm super curious to hear what others are doing. Has kubectl escaped to the wild? How are ops people dealing with that, especially the implications of `kubectl exec` and `kubectl portfw` direct to production from developer workstations?