Kubernetes Application Survey 2018 (Responses)
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
View only
 
 
ABCDEFGHIJKLMNOPQRSTUVWXYZAAABACADAEAFAGAHAIAJAKALAMANAOAPAQARASATAUAVAWAXAYAZBABBBCBDBEBFBGBHBIBJBKBLBMBNBOBPBQBRBSBTBU
1
Timestamp
I would describe my experience with Kubernetes as:
How would you describe your usage of the workload controllers (Deployment, DaemonSet, StatefulSet, ReplicaSet)?
What do you like about the workload controllers?
What would you like to see added or changed in the workload controllers?
How would you describe your usage of Jobs and CronJobs?
What do you like about Jobs and/or CronJobs?
What would you like to see added or changed in Jobs and/or CronJobs?
How would you describe your usage of kubectl
What do you use kubectl for (e.g., to manage RBAC, to apply change to Kubernetes objects, etc)?
What do you like about kubectl?
What would you like to see added or changed in kubectl?
What tools do you use instead of kubectl?
How would you describe your usage of the Kubernetes Dashboard
What do you like about the Kubernetes Dashboard?
What would you like to see added or changed in the Kubernetes Dashboard?
What dashboard do you use?
How would you describe your usage of Helm
How would you describe your experience with Helm Charts
The default template engine (gotpl) is sufficient for my needs?
Why was gotpl insufficient for your needs, if you answered no to the previous question?
How would you describe your usages of chart repositories
Have you used any plugins to extend helm?
What plugins have you used, if you answered yes to the previous question?
Before reading this survey, were you aware that you can create your own client side plugins in Helm to extend its functionality?
What do you like about Helm?
What would you like to see added or changed in Helm?
How would you describe your usage of the Community Charts
What do you like about the Community Charts?
What would you like to see added or change in the Community Charts?
How would you describe your usage of Kompose
What do you like about Kompose?
What would you like to see added or changed in Kompose?
How would you describe your usage of Minikube
What do you like about Minikube?
What would you like to see added or changed in Minikube?
What platform(s) do you run Minikube on?
What driver(s) do you use regularly with Minikube?
What bootstrapper do you use with Minikube?
What version(s) of Kubernetes are up you currently using?
What --extra-config parameters do you use?
What addons do you use?
Are you interested in having a multi-node minikube (beyond current single-node)?
What container runtime(s) do you use with minikube?
Where is the software you operate in Kubernetes developed?
Which types of software do you or your organization deploy onto Kubernetes?
Please rate the following questions as Usually, Sometimes, Never, or Not Applicable [I want to be able to visualize all the Kubernetes objects that make up my application]
Please rate the following questions as Usually, Sometimes, Never, or Not Applicable [I want to be able to visualize the Kubernetes objects that make up a sub-component of my application]
Please rate the following questions as Usually, Sometimes, Never, or Not Applicable [I want to be able to find the version of an application I have running]
Please rate the following questions as Usually, Sometimes, Never, or Not Applicable [I want to be able to find the tool managing my application or that launched it (e.g., Helm)]
Please rate the following questions as Usually, Sometimes, Never, or Not Applicable [I want to be able to find a pointer to the more details on an application running in Kubernetes]
Please rate the following questions as Usually, Sometimes, Never, or Not Applicable [I would like an object to represent my application running in Kubernetes. Possibly with similar content to that in a Helm Chart.yaml and that the objects representing my application can reference]
Please rate the following questions as Usually, Sometimes, Never, or Not Applicable [I would benefit from documentation that helps me to better understand how to practically run applications in Kubernetes]
Please rate the following questions as Usually, Sometimes, Never, or Not Applicable [I would benefit from improved clients or SDKs and developer documentation that explained how to build tools to complement Kubernetes]
Which of the following publicly available tools for managing apps on Kubernetes are you using
Are there any publicly available tools you use in addition to the previous set?
Can you share a little about why you choose the tools you used?
Does your organization build its own in-house tools to aid in developing and operating applications on Kubernetes
If your organization builds in-house tools, do you personally develop those tools?
If your organization builds in-house tools, why do you build them? (e.g., for your custom workflow or you have a need that you can’t find an existing tool to fill)
I deploy or test Kubernetes configurations via CI/CD?
I use one or more of the following tools for CI/CD
I currently use CI/CD to
I don't today but would like to use CI/CD to
Tools I use as part of CI/CD
Do you enjoy running applications on Kubernetes?
Final Comments
2
4/5/2018 12:03:35
I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API
I supplement the core workload controllers with custom controllers
They "just work" for what I need (deployments)
I use Jobs and/or CronJobs
I remember hearing that it might not be possible for a job to run exactly once (for some certain pod failure scenarios). If that's true, we should fix that so it does support run-once semantics.
I regularly use kubectl
Pretty much everything :-) get, delete, create, exec, port-forward, apply
It's generally a decent way to interact with a cluster
I don’t use a graphical UI for Kubernetes
I do not use HelmI do not use Kompose
I occassionally use Minikube
It was really easy to install & set up
MacOSHyperkitdefault (localkube)v1.9.xYesDocker, cri-o
Software developed in-house, Open Source software
Custom Kubernetes controllers + CRDs
SometimesSometimesUsuallySometimesNot ApplicableSometimesSometimesUsuallyNoNoYesJenkins
Build container images, Push container images to a registry
Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Positive
3
4/5/2018 12:03:35
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
I use Jobs and/or CronJobs
I regularly use kubectl
I use the Kubernetes Dashboard
I do not use HelmI do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless services, Traditional Batch or streaming data processing
SometimesSometimesUsuallyNeverNeverSometimesNot ApplicableSometimes
Ansible, Skaffold, Terraform
YesYesNoStrongly Positive
4
4/5/2018 12:06:30
I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
Relatively simple. (But the terminology is awful; "controller" in the larger Kubernetes ecosystem means many different things depending on who is speaking or writing.)
I do not use Jobs and/or CronJobs
I regularly use kubectl
Applying changes to Kubernetes objects.
Scriptable.
More consistency and predictability with respect to subcommands and options. If you're going to have a single command, then unfortunately you have to accept the huge, huge burden of organizing its subcommands and options effectively. kubectl could be much better here.
I use the Kubernetes Dashboard
All-in-one convenience.
A little more predictability in refresh behaviors.
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
gotpl is an arcane and irritating syntax.
I use the community stable or incubator repositories, I use charts stored in locations other than a repository or a version control system
NoYes
Its package manager semantics.
Instead of placing the burden of indicating what can be overridden on the chart author, it should be possible to simply overlay values files "on top of" existing charts.
I use the community charts for demo purposes only
Separate git repositories.
I do not use KomposeI regularly use Minikube
The only way to run Kubernetes for free on my laptop easily.
MacOSVirtualBoxdefault (localkube)v1.10.x, v1.9.xNoDocker
Software developed in-house, Open Source software
Stateless services, SQL databases, NoSQL databases, Message queues, Traditional Batch or streaming data processing
UsuallyUsuallySometimesSometimesUsuallyUsuallyUsuallyUsually
fabric8-mvn-plugin, fabric8 client, Helm, Metaparticle, Terraform
I want my infrastructure to be transparent. Kubernetes is something I want to simply disappear. We are miles and miles and miles and miles and miles and miles and miles and miles away from this, but glacially moving in that direction. fabric8 and Brendan Burns' Metaparticle understand this vision.
YesYesYes
CircleCI, Gitlab CI, Jenkins, Wercker
Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster
Negative
5
4/5/2018 12:07:16
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes
I exclusively use the core workload controllers
they do their best to keep my applications running
No idea. I don't think about workload controllers too much, because I am focusing on my apps.
I do not use Jobs and/or CronJobs
I regularly use kubectl
automate stuff on CI/CD system, get logs from testing and production systems, debug stuff, running ad-hoc containers with networking tools inside the cluster
Swiss army knife for troubleshooting and viewing the state of the cluster
kubectl is fine, but my teammates have hard time digesting information about another tool in order to debug the app themselves. Perhaps some UI parity with kubectl would be nice. Something that people can use without needing to learn kubectl.
I use the Kubernetes Dashboard
visually inspect all the aspects of the application running
feature parity with kubectl
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use object storage, a static web server, or similar system for my repository
NoYes
it packages everything that application needs in order to run in the cluster
Helm should be native feature of kubernetes as I don't want another tool to manage my application. Ideally I would see kubectl absorbing helm functionality entirely.
I operate production applications from the community charts
they work
chart repository is not mature enough
there is no easy way to see all previous versions and release notes of charts
but chart repository should not reinvent the wheel - we have enough registries and repositories already
I do not use Kompose
I occassionally use Minikube
it works locally, recently with even better hypervisor
MacOSHyperkitdefault (localkube)v1.9.x
ingress controller, registry
YesDocker
Software developed in-house
Stateless servicesUsuallyUsuallySometimesSometimesUsuallyUsuallyUsuallyNeverHelm, landscaper
they were the simplest to start with
they were ones of the most supported by community
NoNoYesTeamcity
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Strongly Positive
6
4/5/2018 12:08:51None
I do not use the workload controllers
I do not use Jobs and/or CronJobs
I do not use kubectl
I don’t use a graphical UI for Kubernetes
I do not use HelmI do not use KomposeI do not use Minikube
Software developed in-house
NoneNot ApplicableNot ApplicableUsuallyNot ApplicableNot ApplicableNot ApplicableUsuallyNot ApplicableNoNoNoNeutral
7
4/5/2018 12:09:39
I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends)
I supplement the core workload controllers with custom controllers
I use Jobs and/or CronJobs
I regularly use kubectl
I don’t use a graphical UI for Kubernetes
I am evaluating Helm
I have deployed Charts created by others
I use the community stable or incubator repositories
NoNo
I use the community charts for demo purposes only
I do not use Kompose
I occassionally use Minikube
LinuxVirtualBoxkubeadmv1.10.x, v1.9.x, v1.8.xYesDockerOpen Source software
Stateless services, Traditional Batch or streaming data processing
SometimesSometimesUsuallyUsuallyUsuallyUsuallyUsuallyUsually
Draft, generator-kubegen, Helm, OpenShift templates
YesYesYes
CircleCI, Gitlab CI, Travis CI
Build container images, Programatically update or alter Kubernetes manifest files, Test upgrading my application
Positive
8
4/5/2018 12:10:12
I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
I do not use Jobs and/or CronJobs
I regularly use kubectl
I use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)
I do not use Helm
I used Kompose as one-time tool to bootstrap Kubernetes manifest.
I regularly use MinikubeMacOS, LinuxVirtualBox, xhyvekubeadmv1.10.x, v1.9.x, v1.8.xNoDocker
Software developed in-house, Open Source software
Stateless services, SQL databases, NoSQL databases
SometimesSometimesUsuallyNeverNeverUsuallyUsuallyUsuallyYesYesYesJenkins
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster, Deploy updates to my application to production
Initially deploy my application to production
Positive
9
4/5/2018 12:10:38
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API
I exclusively use the core workload controllers
I do not use Jobs and/or CronJobs
I regularly use kubectl
Proxy to dashboard, management of all kind of objects, simple scripts, cluster debugging
I use the Kubernetes Dashboard
It sometimes get inconsistent when there are network errors, making it annoying to use. OIDC support would be great (configure auth provider and let users sign in directly)
I use Helm
I have deployed Charts created by others
I use the community stable or incubator repositories
NoNo
I operate production applications from the community charts
Some charts are incompatible to others while the components are often used in a stack i.e. ELK stack (elastic search, logstash, kibana) - some standards would be great
I do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless services, SQL databases, Message queues
SometimesNeverUsuallyUsuallySometimesNeverSometimesUsuallyAnsible, HelmNoNoNoStrongly Positive
10
4/5/2018 12:10:58
I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends), I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
I use Jobs and/or CronJobs
I regularly use kubectl
I use the Kubernetes Dashboard
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
YesYes
I use the community charts for demo purposes only
I do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless servicesUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsually
Draft, Helm, Metaparticle, Skaffold
Yes
CircleCI, Jenkins, Jenkins X, Travis CI
Build container images, Push container images to a registry
Strongly Positive
11
4/5/2018 12:15:05
I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
They are pretty easy to use
I find them overly verbose. I wish there was something at the same level as heroku's configuration
I use Jobs and/or CronJobs
That they exist
I'm not sure yet, but I would like better metrics around cron jobs I think.
I use kubectl only when there’s a features gap in other tools I’m using
Mainly to deploy new services or update images
it's well documented
yaml is a pain in the ass. Figuring out the current state of my system and deployments and updating it is very hard.
I use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)
I do not use HelmI do not use KomposeI do not use Minikube
Software developed in-house
Stateless services, Traditional Batch or streaming data processing
UsuallyUsuallyUsuallySometimesSometimesSometimesUsuallyUsually
Ansible, kubecfg, Terraform
They seemed to workYesYes
Because I want easy git push to running in prod.
Yes
Travis CI, Google Container Registry
Build container images, Push container images to a registry, Test or lint my Kubernetes object configuration
Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Neutral
12
4/5/2018 12:17:20
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development
I exclusively use the core workload controllers
I do not use Jobs and/or CronJobs
I regularly use kubectlshortcuts
better support of old versions. I had to run clusters with multiple versions
I use the Kubernetes Dashboard
I would like to see some problems immediately when I open dashboard
I do not use HelmI do not use KomposeI do not use Minikube
Software developed in-house, Open Source software, Proprietary 3rd party solutions (e.g., Oracle database)
Stateless services, SQL databases, NoSQL databases
Not ApplicableNot ApplicableNot ApplicableNot ApplicableSometimesNot ApplicableUsuallyNot Applicablebosh
Bosh is the best tol for immutable infrastructure
YesYesYesConcourse
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Test upgrading my application
Neutral
13
4/5/2018 12:19:26
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I do not use the workload controllers
I use Jobs and/or CronJobs
It takes my container and turns it into a cron job / one off
it's pretty fine as it is, after the 1.8 changes I was happy.
I regularly use kubectl
interacting with my k8s cluster
it works!
I would like kubeconfig files to not be so hard to manage. I would like a nicer way to sort and filter resources. jsonpath makes me have to think in terms of "how is this resource, that i wrote in yaml, represented in json?" that plus memorizing the syntax for something that i only use occasionally means i have to look up examples every single time. I'd love a more user friendly approach
I don’t use a graphical UI for Kubernetes
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
NoNo
it gets me tls real fast on any cluster
I operate production applications from the community charts
fewer security gaps (see: jenkins chart about 1 year ago)
I do not use Kompose
I occassionally use Minikube
it works
i'd like minikube to be a better representation of a real multi-node cluster
MacOSHyperkit
default (localkube), kubeadm
v1.8.xYesDocker
Software developed in-house, Open Source software
Stateless services, Traditional Batch or streaming data processing
NeverNeverSometimesUsuallyUsuallyUsuallyNot ApplicableUsually
Helm, jsonnet, ksonnet, kubecfg
NoYesJenkins
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files
Strongly Positive
14
4/5/2018 12:19:50
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
I use Jobs and/or CronJobs
I regularly use kubectl
I don’t use a graphical UI for Kubernetes
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc), I use object storage, a static web server, or similar system for my repository, I use a version control system (e.g., git) instead of a repository with no index.yaml file
YesYes
I operate production applications from the community charts
I do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless services, NoSQL databases
SometimesSometimesUsuallyUsuallySometimesSometimesUsuallySometimesHelm, TerraformKopsYesYesYesConcourse
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Test or lint my kubernetes object configuration
Strongly Positive
15
4/5/2018 12:20:53
I operate Kubernetes clusters for my organization
I exclusively use the core workload controllers
I use Jobs and/or CronJobs
SimplicityI regularly use kubectlEverythingI like command line
I don’t use a graphical UI for Kubernetes
gkeI do not use HelmI do not use Kompose
I occassionally use Minikube
Run on my laptopMacOSxhyvedefault (localkube)v1.9.xheptio contourNoDocker
Software developed in-house, Open Source software
Stateless services, SQL databases
NeverNeverUsuallySometimesSometimesSometimesUsuallyUsuallyNoNoStrongly PositiveGreat job
16
4/5/2018 12:22:13
I operate Kubernetes clusters for my organization, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
They fit most use cases.
Support needed in the back end or config for multi-location scaling and deployment.
I do not use Jobs and/or CronJobs
I regularly use kubectl
Applying yaml changes, brief inspections.
It offers intuitive CRUD, doesn't try to replace more complex tools.
I use both the Kubernetes Dashboard and another UI
The workload overview is good, it can be faster than making many queries with kubectl.
More information about deployments and their corresponding pods.
I do not use HelmI do not use Kompose
I occassionally use Minikube
It's an easy and free demo of a cluster.
Increased stability.LinuxVirtualBox, KVMdefault (localkube)v1.9.xNoDocker
Software developed in-house, Open Source software
Stateless services, SQL databases, NoSQL databases
UsuallyUsuallyUsuallySometimesSometimesSometimesSometimesUsuallyYesYes
We only need very simple deploy tools currently, and most existing tools are very complex.
NoPositive
17
4/5/2018 12:23:23
I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
easy to use and update
tighter coupling between the controllers and the resources they create\manage
I do not use Jobs and/or CronJobs
I use kubectl only when there’s a features gap in other tools I’m using
mostly to inspect running resources and to troubleshoot
it handles just about anything
better resource filtering would be nice but there is always grep and awk
I don’t use a graphical UI for Kubernetes
I do not use HelmI do not use Kompose
I occassionally use Minikube
it's ok for local development
less resource consumption
MacOSVirtualBoxdefault (localkube)v1.8.x
various alpha settings from time to time
ingress + corednsNoDocker
Software developed in-house
Stateless services, Machine Learning training or serving
SometimesSometimesSometimesSometimesSometimesSometimesUsuallySometimesSkipper
It doesn't require our developers to write and manage templates
YesYes
It gives us a way to control our own custom environment in a centralized manner, yet still provides total freedom to engineering teams.
YesCircleCI, Jenkins
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
skipperStrongly Positive
18
4/5/2018 12:23:41
I operate Kubernetes clusters for my organization
I exclusively use the core workload controllers
The just workSimplification
I use Jobs and/or CronJobs
Distributed cron jobs are amazing
Just market them moreI regularly use kubectl
Lots of things but I like the dashboard way better
For basic stuff it's greatSimplification
I use the Kubernetes Dashboard
Simple to use
Excise which namespace you're in a little more prominently
I am evaluating Helm
I have deployed Charts created by others
Yes
I use the community stable or incubator repositories
NoNoIt's a package manager
ARM support and competition
I operate production applications from the community charts
They're doneMore of themI do not use KomposeI regularly use Minikube
Local dev environment simplification
Ditch the VM hypervisor
MacOSVirtualBox, xhyvedefault (localkube)v1.9.xYesDocker
Software developed in-house, Open Source software
Stateless servicesUsuallyUsuallyUsuallyUsuallySometimesNeverUsuallyNever
Ansible, Skaffold, Terraform
NoNoNoPositive❤️ y'all
19
4/5/2018 12:29:34
I operate Kubernetes clusters for my organization, I operate applications on Kubernetes, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
I use Jobs and/or CronJobs
I regularly use kubectl
CRD validation, better (more consistent) support for declarative configuration
I use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
No
It's not necessarily that gotpl is insufficient, it's that templating has run amok
I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc), I use object storage, a static web server, or similar system for my repository
Yesdiff, registry, templateYes
I operate production applications from the community charts
I do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless services, Message queues, Traditional Batch or streaming data processing
UsuallyUsuallyUsuallyUsuallySometimesUsuallyUsuallyUsually
Helm, ksonnet, Terraform
YesNoYesGitlab CI
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Test upgrading my application
Strongly Positive
20
4/5/2018 12:31:38
I operate Kubernetes clusters for my organization, I operate applications on Kubernetes
I exclusively use the core workload controllers
Ability to update and rollback is built in
I do not use Jobs and/or CronJobs
I regularly use kubectl
Apply changes and get objects
Simple usage
More shorthand for objects (crb for clusterrolebinding, etc)
I use the Kubernetes Dashboard
Displays status of objects in a visual manner without being an overload of information (like with kubectl get all)
Being able to edit YAML for objects rather than the resulting JSON
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
NoNo
Easily develop new charts
Ability to reference top level values of child charts in parent charts when using dependency
I operate production applications from the community charts
Stable enough
Better vetting of some charts (But that's rather easy to do with a PR if an error occurs)
I do not use KomposeI regularly use Minikube
Easily bootstrap a dev environment locally
Keep more up to date with latest K8s versions and appropriate addons
LinuxVirtualBox, KVM2
default (localkube), kubeadm
v1.9.x
addon-manager, dashboard, default-storageclass, freshpod, heapster, ingress, kube-dns, registry, storage-provisioner, metrics-server
YesDockerOpen Source software
SQL databases, Traditional Batch or streaming data processing
UsuallySometimesSometimesUsuallyUsuallySometimesSometimesUsuallyHelm
Easy to design a CI/CD pipeline around, rather than a supplied CI/CD solution
NoNoYesTravis CI, Buildkite
Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster
Generate Kubernetes manifest files, Test or lint my kubernetes object configuration
Helm, kubectlPositive
21
4/5/2018 12:34:06
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
ds: scalability, ss: deterministic naming schema
Support for vanilla NFS on PVCs.
I use Jobs and/or CronJobs
Same declaration language as workloads
Better deterministic execution (e.g. recovery of missed jobs if the job executor was not running at the moment)
I regularly use kubectl
Verify workload state, edit configmaps, test manifest changes before committing
predictable language - knowledge of how to use kubectl with one component (e.g. pods) translates well to other components
More complete output format coverage (e.g. yaml output is not always supported)
I use the Kubernetes Dashboard
All in one overview
More atomic AAA options
I am evaluating Helm
I use a version control system (e.g., git) instead of a repository with no index.yaml file
NoNo
Good change management options (rolling updates, use same chart for multiple app versions)
I use the community charts as a foundation or template for my own charts that I store elsewhere
They provide a good reference for community best practices
I do not use Kompose
I occassionally use Minikube
Easy to set up a test environment for developers
More default options (e.g. install dashboard, heapster, etc) to allow a seamless out of the box experience for devs
MacOS, LinuxVirtualBox, KVM2, KVM
default (localkube), kubeadm
v1.10.x, v1.9.xNoDocker
Software developed in-house, Open Source software
Stateless services, SQL databases, NoSQL databases, Message queues, Traditional Batch or streaming data processing, Machine Learning training or serving
SometimesSometimesSometimesSometimesUsuallySometimesUsuallySometimesAnsible, HelmSpinnakerEvaluationYesYes
Patch shortcomings in existing tools and bridge transitions from one tool to another
YesJenkins, Spinnaker
Build container images, Push container images to a registry, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster
Programatically update or alter Kubernetes manifest files, Initially deploy my application to production, Deploy updates to my application to production
Sonatype NexusPositive
Overall the Kubernetes community is great. However sometimes we get the feeling that the community is resistant to change, falling into a "We don't develop it because no one uses it / No one uses it because it's not developed" cycle.
22
4/5/2018 12:36:13
I operate Kubernetes clusters to support my application development, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
It manages the lifecycle of the pods
It would be nice if volume claim templates can be in plain deployments (though they wouldn't, obviously, sensibly persist)
I use Jobs and/or CronJobs
They map well it namespace-wide initialization
Making it easier to get logs after the job completes would be nice
I regularly use kubectl
Examine state of the system, and to change it (deploy things, delete pods, etc.)
Command line tool, consistent in what it does
Better support for looking at specific namespaces; being able to use a substring for an item instead of its full name (when typing on the command line); abbreviations for things like `describe` and `statefulset`
I use the Kubernetes Dashboard
Easy way to get at the heapster output
Make it faster, and less JavaScript. It's generally in the same local network for me, an SPA just slows things down. Better reporting on why token logins aren't working would be nice too.
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use object storage, a static web server, or similar system for my repository, I use charts stored in locations other than a repository or a version control system
NoYes
Templating for deployment
More templating functions, and better control over deployment order (hooks would be nice). I can't have a pre-deploy hook that depends on an RBAC role defined in the chart, for example.
I use the community charts for demo purposes only
They exist?
It's unclear what the upgrade policy is; I'd like them to be stable over years.
I do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless services, SQL databases, Traditional Batch or streaming data processing
UsuallyUsuallyUsuallyUsuallyUsuallySometimesSometimesSometimesHelm
http://github.com/aarondl/kctl
Just the basics, more or less
YesYes
Bridging existing external things with kubernetes
Yes
Jenkins, Concourse (don't use it, it's an 60% solution)
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster
Way too much bashNeutral
I am not using minikube because it needed better support for storage.
23
4/5/2018 12:40:39
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development
I supplement the core workload controllers with custom controllers
I do not use Jobs and/or CronJobs
I regularly use kubectl
easier way to "set current namespace" so i dont have to type -n ALL THE TIME
I use the Kubernetes Dashboard
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc)
NoNo
I operate production applications from the community charts
I do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless services, SQL databases, NoSQL databases
UsuallyUsuallySometimesSometimesUsuallyUsuallyUsuallyUsuallyHelmNoNoYesGitlab CI
Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster
Initially deploy my application to production, Deploy updates to my application to production
Strongly Positive
24
4/5/2018 12:40:54
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
I do not use Jobs and/or CronJobs
I regularly use kubectl
I use the Kubernetes Dashboard
better authentication support
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
NoNo
I operate production applications from the community charts
I do not use Kompose
I occassionally use Minikube
MacOSVirtualBoxdefault (localkube)v1.10.xYesDocker
Software developed in-house, Open Source software
Stateless services, Traditional Batch or streaming data processing
UsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyHelmYesYes
to automatically attach additional metadata to deployed resources
YesGitlab CI
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Test or lint my kubernetes object configuration
HelmStrongly Positive
25
4/5/2018 12:42:19
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API
I exclusively use the core workload controllers
They are working
Provide better support for bootstrapping and self-hosting clusters (kubeadm)
I do not use Jobs and/or CronJobs
I regularly use kubectl
get, create, replace, apply, rollout status, rollout undo, whatever
It's awesome
The ability to set namespaces in my context seamlessly so I won't have to specify the namespace whenever needed. Something that I miss a lot from oc; that is "oc project"
I don’t use a graphical UI for Kubernetes
OpenShift ConsoleI do not use HelmI do not use KomposeI do not use MinikubeOpen Source softwareStateless servicesUsuallyNeverUsuallyNot ApplicableSometimesSometimesUsuallyUsuallyOpenShift templatesmake
Openshift templates are nice for grouping and some level of parameterization but they are inflexible. A makefile with a bunch of target is currently what we are doing (manages a bunch of manifests including Lists and Openshift Templates).
YesNoYesJenkins, Prow
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Deploy updates to my application to production
Strongly Positive
I really need a tool that is able to apply patches on top of existing manifests so that I won't have to copy the same manifest around just to tweak a couple of fields. Thanks a lot!
26
4/5/2018 12:42:27
I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends), I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
Out of the box functionality
I do not use Jobs and/or CronJobs
I use kubectl only when there’s a features gap in other tools I’m using
I don’t use a graphical UI for Kubernetes
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use object storage, a static web server, or similar system for my repository
NoYes
Make it easier to extend blueprints (overlay perhaps)!
I use the community charts as a foundation or template for my own charts that I store elsewhere
I do not use KomposeI do not use Minikube
Software developed in-house, Open Source software, Proprietary 3rd party solutions (e.g., Oracle database)
Stateless services, SQL databases, NoSQL databases
UsuallySometimesUsuallySometimesSometimesNeverSometimesNeverHelmYesYesNoPositive
27
4/5/2018 12:45:35
I operate Kubernetes clusters for my organization
I exclusively use the core workload controllers
Until now they fit my need
I wish there is more work on secret, and integrate vault as default option , to increase the security level of what we store in secret
I do not use Jobs and/or CronJobs
I regularly use kubectl
To manage everything actually
Pretty good until now
I don’t use a graphical UI for Kubernetes
Default kubernetes dashboard
I use Helm
I have developed Charts for use with Helm
Yes
I use charts stored in locations other than a repository or a version control system
NoNo
Managing yaml files and subcharts, also global value is a pretty good thing, it helps a lot
I wish there is feature that help us to import multiple files and using dependencies for childchart
I use the community charts for demo purposes only
They give us more visibility how to write my own charts
Good until nowI do not use Kompose
I occassionally use Minikube
Simple to use for demos
Able to use it as clusterWindowsVirtualBoxdefault (localkube)v1.9.x
Disable swap and local volume
Dashboard,heapster,kubedns,kubeproxy, all the default add-ons
YesDocker
Software developed in-house, Open Source software, Proprietary 3rd party solutions (e.g., Oracle database)
Stateless services, Statefull application
UsuallySometimesSometimesUsuallyUsuallyUsuallyUsuallySometimesAnsible, Helm, kubecfgI like using helmNoNoNoStrongly Positive
Thanks for making such a good improvement to kubernetes
28
4/5/2018 12:46:25
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends), I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
I use Jobs and/or CronJobs
Easy to deploy
A success/failure notification system built in (slack/email/etc)
I regularly use kubectlApply, gets, edit, etc
Love that its very similar to docker exec/etc
More niche options so I have to do less jq. Stuff like show all the node IPs, kubectl top is great, things like that.
I don’t use a graphical UI for Kubernetes
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
Easy to figure out and train new people on
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
Yes
helm-diff, helm-template
Yes
Makes doing CI/CD incredibly simple
Better validation, similar to Terraform "This var is missing from values.yaml, etc"
I use the community charts as a foundation or template for my own charts that I store elsewhere
Quick deploys
More "how to make this public chart production ready"
I do not use KomposeI regularly use Minikube
Great for development environments
An OSX dropdown app that tells you the status, IP addresses, etc
MacOSxhyvedefault (localkube)v1.9.x, v1.8.x, v1.7.xDNS, registryYesDocker
Software developed in-house, Open Source software, Proprietary 3rd party solutions (e.g., Oracle database)
Stateless services, Message queues, Traditional Batch or streaming data processing
UsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsually
Ansible, Helm, kubecfg, Skipper, Terraform
YesYes
Quality of life improvements, locking down clusters, etc
YesGitlab CI, Jenkins
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster, Deploy updates to my application to production
Generate Kubernetes manifest files, Test or lint my kubernetes object configuration, Test upgrading my application, Initially deploy my application to production
Gitlab-CI + Helm mostly
Strongly Positive
29
4/5/2018 12:46:48
I operate Kubernetes clusters for my organization, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
Custom update strategies
I do not use Jobs and/or CronJobs
I regularly use kubectl
I don’t use a graphical UI for Kubernetes
I do not use HelmI do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless services, Message queues
SometimesSometimesSometimesSometimesSometimesSometimesSometimesSometimesjsonnet
Programmability, closeness to JSON, conciseness
YesYes
Safety, predictability, auditability
YesJenkins
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Deploy my application to a test cluster or namespace
Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Positive
30
4/5/2018 12:47:20
I operate Kubernetes clusters for my organization, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
The workload controllers get us 98% there when it comes to deploying our applications.
More robust rollout strategies (e.g. blue-green, canary). It's possible to do these today, but we have to jump through hoops. Projects like meta-controller help making custom workload easier.
I use Jobs and/or CronJobs
They're easy to get started with.
It's really easy to shoot yourself in the foot and take down your cluster, if you're trying to run a job exactly once and fail fast.
I regularly use kubectl
To view state of all the Kubernetes objects (describe, view logs, etc). To apply changes to objects that I currently don't use Helm for.
It's very powerful. Easy to use in scripts. Provides just enough data as a default, and has options to get more.
Some sort of login function for OIDC. I know it is now possible with the 1.10 release.
I use the Kubernetes Dashboard
It's great for new users of Kubernetes. It's easy to browse.
I'd like to see them finally transition from heapster to metrics-server.
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
No
Composing templates can be tedious. I like the approach that ksonnet is taking.
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
NoYes
It makes deploying applications a breeze. Love being able to quickly rollback applications.
I'd like to see changes in the Helm V3 proposal. The most important one is fixing the RBAC situation. I would also like to see the Helm controller so we can build a gitops flow.
I use the community charts as a foundation or template for my own charts that I store elsewhere
They're fairly stable and flexible enough to use without many changes
More testing :)I do not use KomposeI do not use MinikubeOpen Source softwareStateless servicesSometimesUsuallyUsuallySometimesUsuallyUsuallySometimesSometimesHelm, KonfdNope
Quality of the community, number of available apps, usability.
YesNoN/ANoStrongly Positive
Kubernetes is awesome. I love the direction the community is going.
31
4/5/2018 12:47:52
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends), I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
They cover the 90% of use cases for me.
They're missing complex upgrade logic by default (blue/green, canary, migrations, ...).
I use Jobs and/or CronJobs
Great encapsulation of everything I'd like to use.
There should be a way to wait on other state before running (eg. run this job only when the deployment is ready).
I regularly use kubectl
I use kubectl for all interactions with my cluster.
It works well when combined with awk/sed and pipes.
Querying and filtering ends up producing long awk/sed chains.
I use the Kubernetes Dashboard
Pretty decent high level view of what's going on.
The logs should stream.
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
No
gotpl and yaml do not play nicely together. It also makes transformations difficult.
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
Yes`helm template`Yes
The stable charts are pretty high quality and provide a great jumping off point for my own.
A focus on transformation of resources, instead of rendering of templates.
I operate production applications from the community charts
Many of the stable charts are high quality and solve my needs well.
Mostly just more of them.
I do not use Kompose
I occassionally use Minikube
Easy to get running, easy to use.
Not much.MacOS, LinuxVirtualBoxdefault (localkube)v1.10.x, v1.9.xNoDocker
Software developed in-house, Open Source software
Stateless services, Message queues, Traditional Batch or streaming data processing
UsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyHelmksync
Helm for templating and installs around differing environments. Ksync for fast development on the cluster.
YesYes
Wiring everything together so that it works in dev/staging/prod and CI/CD (all the same way) was quite a chore (5k LOC of make/bash).
Yes
CircleCI, Google Container Builder
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
helm, ksync, lots and lots of makefiles.
Positive
32
4/5/2018 12:51:02
I operate Kubernetes clusters for my organization, I operate applications on Kubernetes, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
Abstracting pod operations to make updates/rollouts easier
I use Jobs and/or CronJobs
Control over batching and parallelism
I regularly use kubectl
Everything to do with cluster management
CLI discoverability and output flexibility
I use both the Kubernetes Dashboard and another UI
Simple, clean interface
More management capability
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
No
The particular mix of gotpl and Sprig used in Helm is not very discoverable. It takes a lot of browsing and searching documentation to figure out how to do even some operations that turn out to be very simple. It also doesn't support some things I consider core functionality, like setting a variable in a conditional and using it later, or referring to values above/adjacent to a child chart in a value tree.
I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc), I use object storage, a static web server, or similar system for my repository, I use charts stored in locations other than a repository or a version control system
NoYes
It's easy to start writing a chart since untemplated resource manifests are valid chart templates. The community is extremely welcoming and helpful.
More flow control logic, more available template engines.
I operate production applications from the community charts
Standard best practices, easy to contribute, attention paid to upgradability.
More granularity in the PR process (I understand this is already in progress).
I do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless services, SQL databases
UsuallyUsuallyUsuallyUsuallyUsuallyUsuallySometimesSometimes
Ansible, Helm, Terraform
They are either designed to deploy to Kubernetes (Helm) or conceptualize Kubernetes as an infrastructure medium for generic deployments (Ansible/Terraform)
YesNo
Working from existing legacy deployment systems toward more native processes.
NoStrongly Positive
I'm afraid the community may be starting to fragment and lose focus as happened with OpenStack. There are a lot of new projects every day and I hope the development effort on them isn't draining brainpower from core Kubernetes progress.
33
4/5/2018 12:51:46
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API
I exclusively use the core workload controllers
Good default behavior
Ability to release resource commits on shutdown, we have some services that reserve a large pct of our cluster capacity and have long (4hr) drain times. So it's hard to do rollouts of them.
I do not use Jobs and/or CronJobs
I regularly use kubectl
1. Apply all changes from git repo
2. Diagnostics and debugging
Ease of use improvement for interactive debugging, e.g. remember namespace and pod name for subsequent invocations.
I use the Kubernetes Dashboard
I do not use HelmI do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless servicesSometimesSometimesUsuallyNeverUsuallyUsuallyUsuallySometimeskube-applier
We came in early and developed the kube applier and our model before other tools existed.

Git for objects + Jenkins pipelines is a fairly potent combination for safely rolling out change.
YesYesYesJenkins
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Test or lint my kubernetes object configuration
Positive
34
4/5/2018 12:54:47
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
I do not use Jobs and/or CronJobs
I regularly use kubectl
Check config, debug, etc
It's a good tool but need better user experience
better config management
I don’t use a graphical UI for Kubernetes
NoneI am evaluating Helm
I have deployed Charts created by others
I use the community stable or incubator repositories
NoNoNice toolBetter user experience
I use the community charts for demo purposes only
I do not use Kompose
I occassionally use Minikube
A good tool to taste kubernetes
better user experienceMacOS, Linux
VirtualBox, VMware Fusion, KVM, xhyve
kubeadmv1.9.x, v1.8.xYesDocker
Software developed in-house, Open Source software
Stateless servicesUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsually
Ansible, OpenShift templates
YesYesYesBamboo
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Strongly Positive
35
4/5/2018 12:56:00
I operate Kubernetes clusters for my organization, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
work well out of the box
the current level of complexity seems fine to me, so, not sure what to add
I use Jobs and/or CronJobs
meh, they exist and are workable
better support of error conditions and retries. I wrap tasks in a script that traps non-zero exit codes, logs an error and exits cleanly. This is awful.
I regularly use kubectlpractically everything
full featured. "explain" is good. "auth can-i --as " is cool
better ways of chaining things together, i.e. getting logs from the pods of a deployment. I'm not fond of jsonpath and prefer " -o json | jq .expression" to "-o jsonpath --template '{@.otherexpression}'
I use the Kubernetes Dashboard
easy to use.
rbac role and rolebinding display (and perhaps) management. Resource usage is nice to have, but should show some indicators of where the data is coming from (or not coming from if missing); should indicate the status of heapster or other sources.
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use object storage, a static web server, or similar system for my repository
NoYes
*some* kind of templating is necessary to simplify deployment. Helm is an mostly workable option. I don't like the way it handles dependent charts, but to be fair this is a very hard problem (probably because it is hard to define the problem).
I need to spend some quality time with ksonnet before I can adequately answer this.
I use the community charts as a foundation or template for my own charts that I store elsewhere
Good public examples
For my purposes they are fine. I think they should aim to be good starting points.
I do not use KomposeI regularly use Minikube
It works most of the time
a decent and well-documented way to share osx directories into pods.
Also https://github.com/kubernetes/minikube/issues/951 https://github.com/kubernetes/minikube/issues/1378
MacOSxhyvekubeadmv1.9.x--NoDocker
Software developed in-house, Open Source software
Stateless services, Message queues
UsuallySometimesUsuallySometimesSometimesNeverSometimesUsuallyAnsible, HelmYesYes
helper applications and scripts are always(*) necessary to fit things together, particularly when doing CI/CD
Yes
Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster
scripts, github, google container builder
Strongly Positivekeep on going
36
4/5/2018 12:56:43
I operate Kubernetes clusters for my organization, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends), I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
I do not use Jobs and/or CronJobs
I regularly use kubectl
creating, updating, viewing, managing API objects
flexibility of composing commands
increased ability to work on generic (non-kube) API objects, increased use of server-side APIs over compiled-in logic (for scaling, printing, cascading deletion, etc)
I use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)
I do not use HelmI do not use KomposeI do not use MinikubeOpen Source software
Stateless services, SQL databases, NoSQL databases
SometimesSometimesUsuallySometimesNeverNeverSometimesSometimes
Ansible, OpenShift templates
YesYesYes
Jenkins, Travis CI, prow/tide
Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster
Positive
37
4/5/2018 12:57:44
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API
I exclusively use the core workload controllers
Declarative, stable. Usable
Differentiating RS and deployments is not clear at the start.
I use Jobs and/or CronJobs
Cron Format is easy to modify
Event listeners for notifications when complete, rather than needing to embed into applications
I regularly use kubectl
create and manage objects. explore the environment
mirrors API functionality
I use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)
I am evaluating Helm
I have deployed Charts created by others
I use the community stable or incubator repositories
better workflows for applications sustainment/administration
I use the community charts for demo purposes only
repeatbale, reliableI do not use Kompose
I occassionally use Minikube
self contained and reproducible for demos/tutorials
egress seems clunkyMacOS, LinuxVirtualBox, xhyvedefault (localkube)v1.9.x, v1.7.xDocker
Software developed in-house, Open Source software
Stateless servicesUsuallySometimesUsuallySometimesNeverUsuallyUsuallyUsuallyOpenShift templatesYesJenkins
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Deploy my application to a staging or quality assurance (QA) cluster
Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Strongly Positive
38
4/5/2018 13:02:31
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
provides options for most common scenarios
More settings changeable, automatic rollback, more rollout-scenarios
I use Jobs and/or CronJobs
I regularly use kubectl
Get status of pods, nodes etc.
I use the Kubernetes Dashboard
Authentication of users (for rbac) can be improved a lot. ui behaves sometimes strange if objects were deleted (browser back is not always the best option).
I do not use HelmI do not use KomposeI regularly use Minikube
Bug fixed that prevents non-root pods to access pv (fsgid ignored).
LinuxVirtualBoxdefault (localkube)v1.9.x, v1.8.xMemory settingsYesDocker
Software developed in-house, Open Source software
Stateless services, Message queues, Traditional Batch or streaming data processing
SometimesUsuallyUsuallySometimesSometimesSometimesUsuallyUsually
kontemplate, Terraform
Templating optionsNoNoYesGitlab CI, Jenkins
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Yamllint, Positive
39
4/5/2018 13:05:01
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
Stability and availability
The scheduler doesn't know enough about storage. Currently, scheduling is based around pods. Scheduling needs to understand pods and storage together so that operators can plan for availability
I use Jobs and/or CronJobs
Jobs and CronJobs seem fine
I regularly use kubectlall objects
very pleased with kubectl.
kubectl context tools are not good, too error prone, subcommands too similarly named and too easy to mix up.
I don’t use a graphical UI for Kubernetes
None, sometimes prometheus
I am evaluating Helm
I have deployed Charts created by others
I use the community charts for demo purposes only
I do not use Kompose
I occassionally use Minikube
MacOSVirtualBoxv1.8.xYesDocker
Software developed in-house, Open Source software
Stateless servicesSometimesSometimesUsuallyNeverUsuallySometimesUsuallySometimesHelm
need production ready solutions,
YesYes
Our tools were built 2 years ago before other tools(helm) were ready. We want standardization, solid integration with github and ci tools
YesCircleCI, Jenkins
Build container images, Push container images to a registry, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Generate Kubernetes manifest files
CircleCI for build. Deploy from circle ci with shell scripts, kubectl apply
Strongly Positive
40
4/5/2018 13:05:54
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API
I exclusively use the core workload controllers
I use Jobs and/or CronJobs
I regularly use kubectl
I use the Kubernetes Dashboard
I am evaluating HelmNoYes
I use the community charts as a foundation or template for my own charts that I store elsewhere
I do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless services, Traditional Batch or streaming data processing
UsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyYesJenkins, Teamcity
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Strongly Positive
41
4/5/2018 13:06:29
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends), I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
I use Jobs and/or CronJobs
I regularly use kubectl
Everything, all control of cluster, apps, etc.
Only reliable way to control the cluster and its contents
I don’t use a graphical UI for Kubernetes
prometheus/grafanaI use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc), I use a version control system (e.g., git) instead of a repository with no index.yaml file, I use charts stored in locations other than a repository or a version control system
YesregistryYes
Nicely wraps up sets of kubernetes constructs into a single "package"
Make it more consistent with kubectl (arg wise). Make it consistent within itself (arg wise).
I use the community charts as a foundation or template for my own charts that I store elsewhere
I do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless services, SQL databases, NoSQL databases, Message queues, Traditional Batch or streaming data processing
SometimesSometimesUsuallyUsuallySometimesSometimesSometimesUsually
Ansible, Helm, Terraform
Kraken
developed in house and released publicly
YesYes
If we can't find opensource solutions, we build (or upstream) to get them.
YesGitlab CI, Jenkins
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Strongly Positive
42
4/5/2018 13:08:25
I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends), I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
They work
I do not use Jobs and/or CronJobs
I regularly use kubectl
RBAC, deployments, debugging
It works
I use the Kubernetes Dashboard
It gives a clear an concise view of a Kubernetes cluster
Add strong auth policies as a default. It's easy to expose K8S secrets via the dash due to insecure configuration. An official Helm chart with Auth would be good.
I use Helm
I have developed Charts for use with Helm
No
I'd like to be able to specify types, ranges, acceptable values etc that can be supplied by a template
I use the community stable or incubator repositories
NoYes
It's easy to create and consume charts
See earlier comment on templating
I use the community charts as a foundation or template for my own charts that I store elsewhere
I do not use Kompose
I occassionally use Minikube
It's simple and all in one
LinuxVirtualBoxIn house toolv1.9.xistioNoDocker
Software developed in-house
Stateless services, SQL databases, NoSQL databases, Message queues
UsuallyUsuallySometimesSometimesNeverNeverUsuallySometimesYesYes
So we can add opinionated deployments and enforce internal policies.
YesBamboo, Gitlab CI
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster
Positive
43
4/5/2018 13:09:24
I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
I use Jobs and/or CronJobs
I regularly use kubectl
I use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc), I use object storage, a static web server, or similar system for my repository
YesYesmakes K8s usable
should be client-only - no more tiller; or if it is server based, should maintain state of the cluster
I use the community charts as a foundation or template for my own charts that I store elsewhere
maturity. many seem to be not much more than 'hello world'
I do not use KomposeI regularly use Minikube
it's really getting better, seamless local operation
MacOSVirtualBoxdefault (localkube)v1.10.x, v1.9.xYesDocker
Software developed in-house, Open Source software
Stateless services, NoSQL databases, Traditional Batch or streaming data processing
UsuallyUsuallySometimesUsuallyUsuallyUsuallyUsuallyUsuallyAnsible, armada, HelmYesYesYesJenkins, Brigade
Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace, Initially deploy my application to production
Positive
44
4/5/2018 13:12:37
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
Simplicity
More templating options
I use Jobs and/or CronJobs
I regularly use kubectlEverythingFast, powerful
I use the Kubernetes Dashboard
Approachable for less cli-oriented people
Integration with cluster auth provider (ie OIDC/Oauth2)
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
NoNoTemplating
Possibility to diff before apply! git as supported repo type (no index or autogen)
I use the community charts as a foundation or template for my own charts that I store elsewhere
Less overwhelming templates. They are often very hard to read, and quite close to having the entire manifest in the values.yaml...
I do not use KomposeI regularly use MinikubeWindows, LinuxVirtualBoxdefault (localkube)v1.10.x, v1.9.xRBACdefaultsNoDocker
Software developed in-house, Open Source software
Stateless services, SQL databases, NoSQL databases, Message queues
SometimesSometimesUsuallyNeverNeverNeverNeverUsuallyHelmacs-engine, bash/makeYesYes
Custom workflows, ease of use (template away options that shouldn't be changed)
YesConcourse
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Strongly Positive
45
4/5/2018 13:17:58
I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
Standard component Nothing
I do not use Jobs and/or CronJobs
I regularly use kubectlMostly debugging Powerful
More like helm with concept of apps
I use the Kubernetes Dashboard
Gives an overview of cluster health
Could be more responsive on occasions
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc), I use object storage, a static web server, or similar system for my repository
NoYes
Deals with application lifecycle. Easy to use
Could use some push mechanism. Need for better logging when things don't work
I use the community charts as a foundation or template for my own charts that I store elsewhere
Easy to get started with common apps
Trust of the quality. Maybe like official docker image
I do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless services, Traditional Batch or streaming data processing
UsuallyUsuallyUsuallySometimesNeverUsuallyUsuallyNot Applicable
Ansible, Draft, fabric8 client, Helm
Well proven tools. YesYes
Ease the inhouse ci CD pipeline for applications
Yes
CircleCI, Jenkins, Codefresh
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Deploy my application to a test cluster or namespace
Deploy updates to my application to production
Docker composePositive
46
4/5/2018 13:19:27
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes
I exclusively use the core workload controllers
I do not use Jobs and/or CronJobs
I use kubectl only when there’s a features gap in other tools I’m using
oc like whoami
I use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)
I do not use HelmI do not use Kompose
I occassionally use Minikube
Fast setupMacOS
VirtualBox, VMware Fusion
default (localkube)v1.8.x, v1.7.xYesDocker
Software developed in-house
Stateless servicesSometimesSometimesSometimesNeverNeverNeverNeverSometimesSpinnakerMaturityNoNoNoStrongly Positive
47
4/5/2018 13:21:58
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends), I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
They well defined and document also work as expected
apply predefined spec changes to Pods
I use Jobs and/or CronJobs
Easy to useinput/output chaining I regularly use kubectllogging, exec it standartize and easy
I use the Kubernetes Dashboard
it works :)Easy to setup auth[z]I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use object storage, a static web server, or similar system for my repository, I use a version control system (e.g., git) instead of a repository with no index.yaml file
Yeschartify and my own Yes
It's amazing. it abstracts all the issue with app deployment
There is a Helm3. Overlays for charts.
I use the community charts as a foundation or template for my own charts that I store elsewhere
It tested and hooked to search engine
I do not use Kompose
I occassionally use Minikube
It a k8s on local machine
current localkube service is not that easy to kill. the asme experience as docker edge on macos would be nice to see on linux.
Linuxdefault (localkube)v1.9.x, v1.8.x, v1.7.xNoDocker
Software developed in-house, Open Source software
Stateless services, SQL databases, NoSQL databases, Message queues
SometimesSometimesUsuallySometimesUsuallyUsuallyUsuallyUsuallyHelm
Helm is a most general and easy to use tool.
YesYes
Cistome workflows, CRDs, custom resources
YesTravis CI, Shippable
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster
helm, bash, cloud provider clis, compilers and linters
Strongly Positive
This a great survey, thank you for doing this.
48
4/5/2018 13:26:06
I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes
I exclusively use the core workload controllers
I do not use Jobs and/or CronJobs
I regularly use kubectlEverything.
I use the Kubernetes Dashboard
Simple and elegant.
More details about what caused readiness or liveness probes to fail.
I am evaluating Helm
I have deployed Charts created by others
Yes
I use the community stable or incubator repositories
No
I operate production applications from the community charts
I do not use Kompose
I occassionally use Minikube
Addons. MacOSVirtualBox, Hyperkitdefault (localkube)v1.10.xYesDocker
Software developed in-house
Stateless services, Message queues, Prometheus.
UsuallyUsuallySometimesNot ApplicableNot ApplicableNot ApplicableSometimesNot ApplicableHelmNoYesGitlab CI, Concourse
Build container images, Push container images to a registry, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Test upgrading my application
Positive
Thanks for your awesome work.
49
4/5/2018 13:26:49
I operate applications on Kubernetes
I supplement the core workload controllers with custom controllers
I do not use Jobs and/or CronJobs
I use kubectl only when there’s a features gap in other tools I’m using
I use the Kubernetes Dashboard
I am evaluating Helm
I have deployed Charts created by others
YesNoNo
I use the community charts for demo purposes only
I do not use KomposeI regularly use MinikubeMacOSxhyvedefault (localkube)v1.9.xYesDocker
Software developed in-house, Open Source software
SQL databases, NoSQL databases, Message queues, Traditional Batch or streaming data processing, Machine Learning training or serving
UsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyHelm, TerraformYesYesYesJenkins, Concourse
Deploy my application to a test cluster or namespace, Initially deploy my application to production, Deploy updates to my application to production
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Test or lint my kubernetes object configuration, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster
Neutral
50
4/5/2018 13:26:58
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
I use Jobs and/or CronJobs
Easier stdout stderr recovery; Automated delete of Jobs
I regularly use kubectl
Inspecting cluster objects
coherent set of tools for inspecting cluster
command completion when specifying namespaces
I use the Kubernetes Dashboard
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
No
no support for non-scoped variables
I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc), I use object storage, a static web server, or similar system for my repository
Yes
In-house value-validator
Yes
the templating functionalities
Better error reports from helm hooks
I operate production applications from the community charts
The monorepo approach makes it hard to support/contribute to a limited number of charts.
I do not use KomposeI regularly use Minikubelocal, isolationMore supportWindows, LinuxVirtualBox, HyperVdefault (localkube)v1.9.x, v1.8.x
apiserver.Authorization.Mode=RBAC
YesDocker
Software developed in-house
Stateless services, Message queues
UsuallySometimesUsuallySometimesSometimesSometimesUsuallyUsuallyHelm, TerraformYesYes
Managing automated application lifecycle
YesGitlab CI
Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace, Deploy updates to my application to production
Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster
Custom docker base images for capturing common tools
Strongly Positive
51
4/5/2018 13:27:20
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development
I exclusively use the core workload controllers
Very well defined behavior by default re: declarative workloads.
Per namespace feature-gates dis/enabling
I use Jobs and/or CronJobs
Resilience
Event triggered jobs (yep, hard to express what/how you trigger upon, parameters, etc)
I regularly use kubectl
Change Kubernetes objects (workloads, configs, rbacs, network policies, everything actually)
Simplicity, same verb-subject approach for most commands
Better CRD support, make these "more" 1st citizens compared with native k8s objects (good work undergoing already)
I don’t use a graphical UI for Kubernetes
NoneI do not use HelmI do not use Kompose
I occassionally use Minikube
Mostly download+run -> ready
More documented, consistent Linux + KVM support - defaulting to virtualbox on Linux is a foreign MAC'ism to be honest.
LinuxKVM2
default (localkube), kubeadm
v1.9.x
Used to add RBACs (c.a. 1.6~1.7) , none nowadays or maybe if I want/need to explicitly test some new feature
nginx-ingressNoDocker
Software developed in-house, Open Source software
Stateless services, NoSQL databases
UsuallySometimesSometimesUsuallyNeverUsuallySometimesNot Applicablejsonnet, kubecfg
Helm is very popular and loved by newcomers, but gets really short when wanting to build more complex manifests hierarchies, that's why we chose jsonnet, also helm is reportedly heavily insecure in multi-tenant environments.
YesNoYesJenkins, Travis CI
Build container images, Programatically update or alter Kubernetes manifest files, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Strongly Positive
Thanks for the awesome work !, truly cloud-native computing FOR THE MASSES :)
52
4/5/2018 13:27:35
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
Fits my needs quite well
I use Jobs and/or CronJobs
Safer than writing the code to create individual containers myself
Feels unfinished still. Jobs failing in particular ways that ate up a whole cluster has been the singular greatest stability headache throughout the past year.
I regularly use kubectlFor *everything*.
Super-easy to install, easy to wrap and use from another language, friendly.
It could use a few more safety checks because it would sometimes fail to progress and therefore eat up a thread in the Java app that was calling it.
I don’t use a graphical UI for Kubernetes
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
NoYesMore or less right
The official chart repository is not yet developed enough. I keep running into use cases where I need to fork one of the official charts because it's not yet clear how to make a fully reusable chart repository.
I use the community charts as a foundation or template for my own charts that I store elsewhere
postgresql and minio charts are mostly trouble-free. Most of the rest is a good starting point.
Needs more work to be pluggable in all use cases. We had to fork the stable charts for fluentbit and artifactory and others
I do not use KomposeI do not use Minikube
Software developed in-house, Open Source software, Proprietary 3rd party solutions (e.g., Oracle database)
Stateless services, SQL databases, Traditional Batch or streaming data processing
SometimesSometimesSometimesSometimesSometimesUsuallySometimesUsuallyHelm, Terraformkubeadm, stern, kops
Seems to be stable, easy to extend, easy to install, and popular enough that we don't need to worry about it going away.
YesYes
Can't find existing tools to do our job.
YesJenkins
Build container images, Push container images to a registry, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace
Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
jenkins, custom scripting
Strongly Positive
53
4/5/2018 13:28:33
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends), I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
I do not use Jobs and/or CronJobs
I regularly use kubectl
I don’t use a graphical UI for Kubernetes
I do not use HelmI do not use KomposeI regularly use MinikubeMacOSVirtualBoxdefault (localkube)v1.9.x, v1.8.xDocker
Software developed in-house, Open Source software
Stateless services, SQL databases
SometimesSometimesSometimesSometimesSometimesSometimesSometimesSometimesYesStrongly Positive
54
4/5/2018 13:31:57
I operate Kubernetes clusters for my organization, I operate applications on Kubernetes, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
Simple and easy to use
I use Jobs and/or CronJobs
They work in a similar fashion to linux cron
Ability to specify timezone
I regularly use kubectl
All interaction with the cluster/all mentioned above
simple, zsh completion
simple integration with auth providers
I use the Kubernetes Dashboard
Easy to browse and find resources
Make it more easy to integrate with auth providers
I do not use HelmI do not use KomposeI do not use Minikube
Software developed in-house
Stateless services, Message queues
SometimesSometimesUsuallyNot ApplicableUsuallyUsuallyUsuallyUsuallyAnsibleYes
Template j2 configurations before pushing to kubernetes
YesNo
We deploy test environments with a small web ui that links to Kubernetes to visualise them and kicks off teamcity jobs for deploying new ones
YesTeamcity
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy updates to my application to production
Test or lint my kubernetes object configuration, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production
ECR, makefiles, Ansible jinja2, docker, docker compose, teamcity
Strongly Positive
Keep kops more up to date with current version release
55
4/5/2018 13:36:37
I operate Kubernetes clusters for my organization, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API
I exclusively use the core workload controllers
Standard, easy-to-understand, extensible
These describe the core of my workloads very well. I like the idea that scaling and similar are extended/wrapped around these cores. Extensions that help with things like scaling stateful workloads (clustered DBs) are useful.
I do not use Jobs and/or CronJobs
I regularly use kubectl
I use kubectl for debugging/understanding my cluster, and for some parts of changing Kubernetes objects.
Swiss-army knifeness. Ability to modify custom resources is powerful.
Sometimes it is a lot of typing to get what I want.
I don’t use a graphical UI for Kubernetes
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
YesdiffYes
Template extensibility, upgradeability
I use the community charts as a foundation or template for my own charts that I store elsewhere
A great start for lots of applications
I do not use KomposeI regularly use MinikubeEasy, fastMacOSVirtualBoxdefault (localkube)v1.9.x, v1.7.xlocalkube (dind)NoDocker
Software developed in-house, Open Source software
Stateless services, NoSQL databases, Traditional Batch or streaming data processing
UsuallyUsuallyUsuallySometimesUsuallySometimesUsuallyUsuallyHelm
Ubiquity of templates. We would like to do more via CI (git-backed kube configuration) but haven't done it yet; we know there are some tools to help.
NoNoYesCircleCI, Jenkins
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Deploy my application to a staging or quality assurance (QA) cluster
Test or lint my kubernetes object configuration, Test upgrading my application, Initially deploy my application to production, Deploy updates to my application to production
Strongly Positive
Using CI/CD and version control (git) to control how apps & related components are deployed seems like the right thing as my team's usage of Kubernetes grows.
56
4/5/2018 13:39:22
I operate applications on Kubernetes
I exclusively use the core workload controllers
The easy, declarative nature of them
I do not use Jobs and/or CronJobs
I regularly use kubectl
I use both the Kubernetes Dashboard and another UI
A possibility to integrate Deployment specific monitoring solution (e.g.: link to the monitoring solution that is described in the descriptor / a monitoring solution integrated right into Dashboard)
I am evaluating Helm
I have deployed Charts created by others
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
NoNo
Easy to deploy a whole solution
The management of image versions
I use the community charts as a foundation or template for my own charts that I store elsewhere
I do not use Kompose
I occassionally use Minikube
WindowsHyperVdefault (localkube)v1.7.xYesDocker
Software developed in-house
Stateless services, Traditional Batch or streaming data processing, Machine Learning training or serving
SometimesSometimesUsuallySometimesUsuallySometimesUsuallySometimesHelm, TerraformRancher
Except for Helm, I already knew those tools
NoNoPositive
57
4/5/2018 13:49:29
I operate Kubernetes clusters for my organization, I develop applications that interact with the Kubernetes API
I exclusively use the core workload controllers
the API stability and flexibility. Any edge cases such as b/g deployments can simply be tooled around the workloads API.
a spec for what fields can or cannot be changed between upgrades.
I do not use Jobs and/or CronJobs
I regularly use kubectl
viewing the current state of the cluster
the fact that older kubectl clients can still talk to a newer version of kubernetes
the install/upgrade process on Windows and Linux is a little clunky compared to MacOS w/ Homebrew
I don’t use a graphical UI for Kubernetes
noneI use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use object storage, a static web server, or similar system for my repository
Yes
primarily https://github.com/adamreese/helm-nuke, https://github.com/adamreese/helm-last and https://github.com/technosophos/helm-template (when it wasn't in core)
Yesthe community
An easier on-boarding process to start writing Helm charts
I use the community charts for demo purposes only
the vast majority of available charts
chart stability, support from the vendors directly
I do not use KomposeI regularly use Minikube
how quick and easy it is to stand up a free and workable "distribution" of Kubernetes.
the ability to test kubernetes release candidates the day it is released
MacOS, LinuxVirtualBox
default (localkube), kubeadm
v1.9.xnonenoneNoDocker, cri-oOpen Source software
Stateless services, Traditional Batch or streaming data processing, Machine Learning training or serving
UsuallySometimesSometimesNeverSometimesNeverUsuallyUsuallyAnsible, Draft, Helm
https://github.com/ahmetb/kubectx
I write tools to run applications on kubernetes, but I am not a system administrator that manages these applications.
NoNoYesCircleCI, Brigade
Build container images, Push container images to a registry, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace
Positive
58
4/5/2018 13:51:44
I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API
I exclusively use the core workload controllers
The get 80% of what I need in an easy shot, and work consistently and clearly
I'd like to be able to handle blue-green deployments as well as have a clear way of handling the more complex lifecycle of persistent stores so that I don't have to manually manage DB backups, restores, indexes, cleanup, etc.
I use Jobs and/or CronJobs
CronJob gives me a way to run scheduled tasks without running a constant container with a timer running within it - I like the separation
I'd like a more clear way to communicate/capture runtimes and operation - they've proven difficult to debug when they go awry, especially when they run long.
I regularly use kubectl
apply changes/manifests directly - I've been moving towards charts, but struggling with it's interactions with RBAC
direct and detailed, but can be overwhelming and complex - it expects a lot of knowledge of Kubernetes fundamentals and workload objects.
consistency in invoking commands - some work with pod names or deploy/* names, but others require specifics. example kubectl log works very differently from describe.
I don’t use a graphical UI for Kubernetes
n/aI am evaluating Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
No
It's difficult to understand, especially for developers that are familiar with other languages. Especially with how to pass information between charts, what good levels of encapsulation are, etc.
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
NoYes
it brings together a lot of template generation complexity, lets me keep sets of containers in a single collection/repository along with configuration
handle RBAC interactions more effectively, and support more advanced workflows where k8s doesn't yet fit - blue/green deployments and DB backups/migrations/restores are my big needs that aren't covered yet
I use the community charts as a foundation or template for my own charts that I store elsewhere
They mostly work
I'd like to see best practices and "how to create charts" better documented to help me create my own charts
I do not use KomposeI regularly use Minikube
quick and easy, gives a good validation experience for learning and basic/limited usage of a cluster
I'd like to see RBAC on as a default, and more consistency about add-ons with things like public charts - it's very mismatched today, and seems divorced from anything Helm related
MacOS, LinuxVirtualBox, Hyperkit
default (localkube), kubeadm
v1.9.x, v1.8.x
--memory all the damn time
heapster, ingress - wish there was a load balancer
NoDocker
Software developed in-house, Open Source software
Stateless services, SQL databases, NoSQL databases, Message queues
UsuallyUsuallyUsuallySometimesSometimesSometimesUsuallySometimes
Draft, Helm, ksonnet, Skaffold
kubeval and kubetest
validating the charts I generate within Helm before they hit a live cluster
NoNoYes
CircleCI, Jenkins, Travis CI
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster, Deploy updates to my application to production
Programatically update or alter Kubernetes manifest files, Deploy my application to a test cluster or namespace, Test upgrading my application, Initially deploy my application to production
anything and everything - practically, a lot of bash scripts, kubectl, and custom code to validate/test
Positive
Security and Identity of services, and multi-cluster interactions are the most significant weak points in using Kubernetes as a platform that I would like to see advanced/addressed. Istio helps, but many pieces aren't yet easily tied together.
59
4/5/2018 13:55:06
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
Declarative infrastructure, unified APIs
I use Jobs and/or CronJobs
An option for jobs to be automatically deleted on successfull completion
I regularly use kubectl
Have a look at deployments status. Troubleshooting
Very intuitive thanks to Kubernetes unified APIs. Similarity with docker for exec, logs,:::
I use the Kubernetes Dashboard
Nice visual overview of your clusters. GUI based access to logs
Could be fasterI use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
No
Having variables scoped to a block is annoying
I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc), I use a version control system (e.g., git) instead of a repository with no index.yaml file
YesDiff, template, nukeYes
Install a group of Kubernetes resources as one app. Templating. Dependencies. Ability to run several instance of an app
Easier installation of custom resources. Easier to secure tiller
I operate production applications from the community charts
Capitalisation of experience. Some are very good. For example the nginx ingress one
Better standardisation I do not use KomposeI regularly use MinikubeEasy to use
Better tested releases. One out of 3 is buggy
MacOSVirtualBoxdefault (localkube)v1.9.xCpu memoryHeapster YesDocker
Software developed in-house, Open Source software, Proprietary 3rd party solutions (e.g., Oracle database)
Stateless services, NoSQL databases, Message queues, Traditional Batch or streaming data processing, Machine Learning training or serving
UsuallyUsuallySometimesNeverNeverSometimesSometimesSometimes
Draft, fabric8 client, Helm, Helmfile, Kedge, Skaffold, Terraform
Telepresence
Problems solved. Stability. Community
YesYes
Tools for on premise deployments without requiring Kubernetes knowledge
YesGitlab CI
Build container images, Push container images to a registry, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster, Deploy updates to my application to production
Test upgrading my application
Strongly Positive
Thank you guys for your great work!
60
4/5/2018 13:57:02
I operate Kubernetes clusters for my organization, I operate applications on Kubernetes, I develop internal tools for running, managing, and validating applications that run on Kubernetes, Create kubernetes clusters for our clients
I exclusively use the core workload controllers
They are easy to understand how to use and reliable
I use Jobs and/or CronJobs
Nice for maintenance tasks like es curator
I regularly use kubectl
Manage RBAC, forwarding private pods, debugging initial issues, adding networking
Options are very well documented
easier switching between credentials like the tool kubectx
I use the Kubernetes Dashboard
Nice for troubleshooting issues.
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc)
YesregistryYes
It uses the native config type of kubernetes, makes deployments portable across namespaces and clusters
Way to turn on a "secure deployement" switch or at least documented steps for helm in a production environment.
I operate production applications from the community charts
They usually work out of the box
I do not use Kompose
I occassionally use Minikube
nice for testing things locally
MacOS, LinuxVirtualBoxdefault (localkube)v1.8.xYesDocker
Software developed in-house, Open Source software
Stateless services, SQL databases, Message queues, Machine Learning training or serving
SometimesSometimesUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyHelm, HelmfileNoYesJenkins
Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster
Jenkins, nexus, sonarqube
Strongly Positive
61
4/5/2018 14:18:09
I operate Kubernetes clusters for my organization
I exclusively use the core workload controllers
I do not use Jobs and/or CronJobs
I regularly use kubectl
I don’t use a graphical UI for Kubernetes
I am evaluating Helm
I don’t use the community charts
I do not use KomposeI do not use Minikube
Open Source software, Proprietary 3rd party solutions (e.g., Oracle database)
Stateless services, SQL databases
UsuallyUsuallyUsuallyUsuallySometimesSometimesSometimesSometimesAnsibleYesJenkins
Build container images, Push container images to a registry
Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Test or lint my kubernetes object configuration, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Strongly Positive
62
4/5/2018 14:25:16
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends), I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
Simple but effective upgrade strategies.
Better support for restarts. Better handling of node/container runtime errors (leading to one off pods in crash loop back off). Built in advanced deployment strategies (canary, A/B)
I use Jobs and/or CronJobs
It works
Allow restart policy/limits. Allow Guaranteed single run (with or without failures).
I regularly use kubectlAll available features
Intuitive/consistent sub commands and options
Better support for sort/filter. Simpler alternatives to jsonpath and gotemplate.
I use the Kubernetes Dashboard
Well designed UX
consolidated views for logs/stats/events using label selectors. For example live tailing logs for all pods in a service.
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
While it’s “sufficient”, gotpl isn’t necessarily ideal. There are simpler templating engines based non ERB/EJS, that would be easier to use.
I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc), I use object storage, a static web server, or similar system for my repository, I use a version control system (e.g., git) instead of a repository with no index.yaml file
YesHelm registryYes
Simple UX, decent dependency management, leads to better contracts with app devs
Secure tiller by default
I use the community charts as a foundation or template for my own charts that I store elsewhere
Canonical repository for best practices, managed/maintained by experts in domains or vendors. Referencable example of good implementation
Vendors providing “official” charts, avoid using images from third parties with custom bootstrapping or init stuff.
I do not use Kompose
I occassionally use Minikube
Simple & Powerful dev environment
Multi node cluster. MacOSVirtualBoxdefault (localkube)
v1.10.x, v1.9.x, v1.8.x, v1.7.x
Can’t recallCan’t recallYesDocker
Software developed in-house, Open Source software, Proprietary 3rd party solutions (e.g., Oracle database)
Stateless services, SQL databases, NoSQL databases, Message queues, Traditional Batch or streaming data processing
UsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyDraft, Helm, Terraform
Simple flexible tools, battle tested. Do not change the native experience too much
YesYes
Mostly around local development (so tooling around draft currently) and advanced deployment strategies (doing A/B tests, canaries etc)
Yes
CircleCI, Gitlab CI, Jenkins, Concourse CI
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Strongly Positive
Great community, great product. If we keep this up another 2-3 years I believe it will be de facto standard for application management
63
4/5/2018 14:26:26
I develop applications that interact with the Kubernetes API
I do not use the workload controllers
I use Jobs and/or CronJobs
I regularly use kubectl
Inspect my cluster, deploy stuff, debug stuff.
I don’t use a graphical UI for Kubernetes
I do not use HelmI do not use KomposeI do not use Minikube
Software developed in-house
Stateless services, SQL databases
SometimesSometimesUsuallyUsuallyUsuallySometimesUsuallyUsuallyForgeTelepresence
Great community; works well
YesNo
Need existing tools can't fill
YesCircleCI, Travis CI
Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster, Deploy updates to my application to production
ForgePositive
64
4/5/2018 14:26:48
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I develop applications that interact with the Kubernetes API
I supplement the core workload controllers with custom controllers
How they are designed to interact with k8s
I do not use Jobs and/or CronJobs
I regularly use kubectl
Manage, debuggen, deploy tests
Compatibility to multiple versions
Definition of compatibility to api
I don’t use a graphical UI for Kubernetes
I am evaluating Helm
I have deployed Charts created by others
YesNoNo
I don’t use the community charts
I do not use Kompose
I occassionally use Minikube
Local developmentWindows, LinuxVirtualBoxv1.9.x, v1.8.x, v1.7.xYesDocker
Software developed in-house, Open Source software
Stateless services, SQL databases, NoSQL databases, Message queues
SometimesSometimesNeverNot ApplicableSometimesNeverSometimesUsuallyAnsible, HelmBazelYesYesNoStrongly Positive
65
4/5/2018 14:28:02
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
Scaling
Local persistent storage
I use Jobs and/or CronJobs
Resource saving when job ends
I regularly use kubectl
Logs view, summary view
Simple syntax
Easy common commands like logs view on pods of a deployment
I use the Kubernetes Dashboard
Simplicity, resource based
Better monitoring and metrics
I am evaluating Helm
I have deployed Charts created by others
I use the community stable or incubator repositories
NoNoVery fast deployment
Support for local storage
I use the community charts for demo purposes only
I do not use Kompose
I occassionally use Minikube
WindowsVirtualBoxv1.10.x, v1.9.xYesDocker
Software developed in-house, Open Source software
Stateless services, SQL databases, NoSQL databases, Message queues
UsuallyUsuallyUsuallySometimesUsuallySometimesNeverSometimesHelmYesYes
Custom workflow involving external multi-tenant services
NoPositive
Kubernetes gave me a new opportunity to my business
66
4/5/2018 14:28:28
I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API
I exclusively use the core workload controllers
Flexibility
pluggable extensions easy to deploy on existing cluster
I do not use Jobs and/or CronJobs
I regularly use kubectlRBAC
Broad set of commands
Plugins
I use the Kubernetes Dashboard
Simple
Simplify using rbac and metric api without heapster
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
No
Need better security for secrets
I use the community stable or incubator repositories
NoYesFlexibility
Easy way to add plugins, better docs
I use the community charts as a foundation or template for my own charts that I store elsewhere
Choices
Regular updates, better docs
I do not use KomposeI do not use Minikube
Software developed in-house
Stateless services, SQL databases
UsuallySometimesUsuallyUsuallySometimesNeverUsuallyUsuallyHelmPrometheus
Standardized deployment
YesYesNo tool availability YesGitlab CIBuild container images
Generate Kubernetes manifest files
Positive
Too hard to upgrade between versions. Should be much easier.
67
4/5/2018 14:40:45
I operate applications on Kubernetes
I do not use the workload controllers
I do not use Jobs and/or CronJobs
I regularly use kubectldeploy apps
better error messages, esp when trying to run against older cluster
I don’t use a graphical UI for Kubernetes
I am evaluating HelmNoNo
I don’t use the community charts
I do not use KomposeI regularly use MinikubeMacOSdefault (localkube)v1.8.xYesDocker
Software developed in-house, Open Source software
Stateless services, Machine Learning training or serving
SometimesSometimesSometimesNeverSometimesNeverSometimesSometimeskontemplateYesNoYesDrone
Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster, Deploy updates to my application to production
Positive
68
4/5/2018 14:45:04
I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends)
I supplement the core workload controllers with custom controllers
The easy of use, they are extensible in nature just like the full k8s suite
Nothing as of now
I use Jobs and/or CronJobs
The easy of use, most other orchestrators don't have full support for these components
nothing as of nowI regularly use kubectl
Manage my whole environment, I also use CI/CD processes to manage this but find it easier in a pinch to still use kubectl
The full featured nature, support for jsonpath, support for labels, the bash completion it's very simple in design
I regularly as switching namespaces if there was an easier way to do this that would be helpful, I don't like attaching it to my context cause then when I switch terminal instances I'm still in the same namespace
I don’t use a graphical UI for Kubernetes
I use Helm
I have developed Charts for use with Helm
Yes
I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc)
YesregistryYes
It has a simple tool chain.
Adding variables feels obtuse, I'd like it to not use the tiller server if possible, using CRDs would be awesome
I use the community charts for demo purposes only
easy of accessnothingI do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless services, Message queues
UsuallySometimesSometimesNeverUsuallyNeverSometimesNot ApplicableHelm, ksonnetYesYes
CI processes updating ancillary tools
YesJenkins
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster, Deploy updates to my application to production
Strongly Positive
Thanks for all the amazing work you all do.
69
4/5/2018 14:47:20
I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
I do not use Jobs and/or CronJobs
I regularly use kubectl
I use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)
I do not use HelmI do not use KomposeI do not use Minikube
Software developed in-house
Stateless services, NoSQL databases, Message queues
UsuallyUsuallyUsuallyUsuallyUsuallyUsuallySometimesSometimes
fabric8 client, OpenShift templates
Our own. Http://skattetaten.github.io/aurora-openshift
When we startes 2.5 years ago there was bo good alternative.

OpenShift Templates are til limited for us.
YesYes
We started them before most of the above where available. Users are used to the power of AuroraConfig now
YesJenkins
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster
Jenkins. Ao (internal tool)
Strongly Positive
70
4/5/2018 14:47:38
I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
I use Jobs and/or CronJobs
I regularly use kubectl
I use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
Yeshelm-gcsYes
I use the community charts as a foundation or template for my own charts that I store elsewhere
I do not use KomposeI regularly use MinikubeMacOS, LinuxKVM2, xhyvedefault (localkube)v1.10.x, v1.9.xNoDocker
Software developed in-house, Open Source software
Stateless servicesUsuallySometimesSometimesSometimesSometimesSometimesUsuallyUsually
Ansible, Helm, Kinflate, Skaffold
YesYes
Container Builder, Jenkins, Spinnaker
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Positive
71
4/5/2018 14:48:10
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API
I supplement the core workload controllers with custom controllers
They handle the majority of scenarios quite well
I use Jobs and/or CronJobs
They do their
Better support for sidecar containers and something like end-step containers, something that fires off when the main containers have completed.
I regularly use kubectl
just about everything really outside of application driven interactions (app->k8s)
Warnings when working with a server that may have issues with certain versions/apis (1.10 client to 1.7 server)
I don’t use a graphical UI for Kubernetes
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use a version control system (e.g., git) instead of a repository with no index.yaml file
NoYes
The list is long, but v3 satisfies my issues.
I use the community charts as a foundation or template for my own charts that I store elsewhere
Some are built out quite well and require very little modification
I do not use KomposeI regularly use Minikube
super quick and easy to get up and going
more consistent with upstream kubernetes release, lots of little random issues that I think will be solved when fully over to kubeadm
Windows, MacOSVirtualBoxv1.9.xYesDocker
Software developed in-house, Open Source software
Stateless services, SQL databases, NoSQL databases, Message queues, Traditional Batch or streaming data processing, Machine Learning training or serving
SometimesSometimesSometimesSometimesNeverSometimesNot ApplicableUsuallyHelmYes
Drone, Gitlab CI, Jenkins, Travis CI
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Deploy updates to my application to production
Strongly Positive
72
4/5/2018 14:50:45
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
I use Jobs and/or CronJobs
I use kubectl only when there’s a features gap in other tools I’m using
Apply changes to Kubernetes objects, debug problems.
The declarative configuration management pattern enabled by the "apply" command.
I don’t use a graphical UI for Kubernetes
I do not use HelmI do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless servicesSometimesSometimesSometimesSometimesSometimesSometimesSometimesSometimesPuppetYesYesYesJenkins
Build container images, Push container images to a registry, Initially deploy my application to production, Deploy updates to my application to production
Generate Kubernetes manifest files, Test or lint my kubernetes object configuration, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster
Strongly Positive
73
4/5/2018 14:53:01
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes
I exclusively use the core workload controllers
Easy
I use Jobs and/or CronJobs
I regularly use kubectl
Manage deployment, rbac, statefull set
Easy to use
I don’t use a graphical UI for Kubernetes
NoneI am evaluating Helm
I have deployed Charts created by others
Yes
I use the community stable or incubator repositories
NoYes
I operate production applications from the community charts
I do not use Kompose
I occassionally use Minikube
LinuxVirtualBoxdefault (localkube)v1.9.x, v1.8.x, v1.7.xYesDocker
Software developed in-house, Open Source software
Stateless services, SQL databases, Traditional Batch or streaming data processing
UsuallyUsuallyUsuallyNeverNeverUsuallyUsuallyNever
Ansible, Helm, Helmfile, OpenShift templates, Terraform
NoNoYes
Container Builder, Gitlab CI, Jenkins
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Positive
74
4/5/2018 14:57:29
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
They cover most of the common use cases needed
Additional or more customizable deployment strategies.
I do not use Jobs and/or CronJobs
I regularly use kubectl
We generate manifests using helm and deploy them using kubectl or SPinnaker
It works well and the CLI api is very straightforward
An option for a bit more visibility during applies
I don’t use a graphical UI for Kubernetes
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
NoYes
Helm's Template capability solves our primary deployment hurdle with kubernetes manifests
I would like to conditionally render subcharts without having to make them explicit requirements that are collected by helm dependency update
I operate production applications from the community charts
the ease of use and version pinning
I do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless services, SQL databases, NoSQL databases, Message queues, Traditional Batch or streaming data processing
SometimesUsuallyUsuallyUsuallySometimesUsuallyUsuallyUsuallyHelmSpinnaker
We have large deployments so our biggest concerns are correctly generating manifests and getting visibility into their deployment
YesYes
for multi-datacenter deployments and to combine pieces of infrastructure necessary for our use cases
YesGitlab CI, Spinnaker
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Initially deploy my application to production, Deploy updates to my application to production
Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster
Strongly Positive
75
4/5/2018 14:58:02
I operate Kubernetes clusters for my organization, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
I use Jobs and/or CronJobs
I regularly use kubectl
I don’t use a graphical UI for Kubernetes
I do not use HelmI do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless servicesSometimesSometimesSometimesNeverSometimesSometimesUsuallyUsuallyPuppetYesYesYesJenkins
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Test or lint my Kubernetes object configuration, Initially deploy my application to production, Deploy updates to my application to production
Generate Kubernetes manifest files
Positive
76
4/5/2018 15:03:10
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
I use Jobs and/or CronJobs
I regularly use kubectl
Better authentication support
I use the Kubernetes Dashboard
updates without refreshing
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
NoNo
I use the community charts as a foundation or template for my own charts that I store elsewhere
Cassandra OperatorI do not use KomposeI do not use Minikube
Software developed in-house, Open Source software, Proprietary 3rd party solutions (e.g., Oracle database)
Stateless services, NoSQL databases, Message queues, Traditional Batch or streaming data processing, Machine Learning training or serving
UsuallySometimesSometimesNeverSometimesSometimesUsuallySometimesHelmNoNoYesBamboo, Gitlab CI
Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Strongly Positive
77
4/5/2018 15:04:26
I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API
I exclusively use the core workload controllers
Abstraction and automation
Less yaml
I do not use Jobs and/or CronJobs
I regularly use kubectl
Shortcuts. Less wordy instructions
I use the Kubernetes Dashboard
OverviewI am evaluating Helm
I have deployed Charts created by others
Yes
I use a repository service (Quay/App Registry, ChartMuseum, etc)
No
I don’t use the community charts
I do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless services, NoSQL databases
UsuallyUsuallyUsuallyNeverSometimesSometimesSometimesNeverHelmYesNoYesJenkins, Travis CI
Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster
Test upgrading my application, Initially deploy my application to production, Deploy updates to my application to production
Neutral
78
4/5/2018 15:20:16
I operate Kubernetes clusters for my organization
I exclusively use the core workload controllers
It cover reasonable scope from stateless to stateful.
I use Jobs and/or CronJobs
I regularly use kubectlfor everything
I like the convention of it. kubectl Verb Noun
I use both the Kubernetes Dashboard and another UI
I am evaluating Helm
I have deployed Charts created by others
Yes
I use the community stable or incubator repositories
NoNo
I operate production applications from the community charts
I used Kompose as one-time tool to bootstrap Kubernetes manifest.
I regularly use MinikubeLinuxVirtualBoxkubeadmv1.10.xYesDockerOpen Source softwareStateless servicesUsuallyUsuallySometimesUsuallyUsuallyUsuallyUsuallyUsuallyHelm, SkaffoldNoNoYesJenkins, Jenkins X
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production
Programatically update or alter Kubernetes manifest files, Test or lint my kubernetes object configuration, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy updates to my application to production
Strongly Positive
79
4/5/2018 15:22:19
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends), I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
generic building blocks
better deployment strategies and hooks available in standard deployments
I do not use Jobs and/or CronJobs
I regularly use kubectl
to generate, load, and manipulate resource spec files
kubectl edit
login / config / context switching needs to be cleaned up.
I use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)
it stays out of the way when you don't need it
Add a Web workflow for launching spec files by URL (CREATE FROM REMOTE FILE URL)
I do not use HelmI do not use KomposeI regularly use Minikube
It helps ensure that K8s is easy to try for free, minimal effort to get started. Nice onboarding experience.
More maintainersMacOS, LinuxVirtualBox, KVM2, KVM
default (localkube), kubeadm
v1.10.x, v1.9.x, v1.8.x, v1.7.x, v1.6.x
YesDocker, rkt, cri-o
Software developed in-house, Open Source software
Stateless services, SQL databases, NoSQL databases, Message queues, Traditional Batch or streaming data processing, Machine Learning training or serving
SometimesSometimesUsuallySometimesSometimesSometimesSometimesUsually
Ansible, OpenShift templates
s2isecurity, multi-tenancyYesYescan't find existingYes
CircleCI, Codeship, Gitlab CI, Jenkins, Travis CI
Test or lint my Kubernetes object configuration, Test upgrading my application
s2iPositive
80
4/5/2018 15:28:01
I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
support activeDeadlineSeconds so pods don't live too long
I use Jobs and/or CronJobs
Only way to get Helm lifecycle hooks
I regularly use kubectl
diagnosis of problems, manual testing
Bash completion of, e.g., pod names doesn't seem to work
I don’t use a graphical UI for Kubernetes
I use Helm
I have developed Charts for use with Helm
No
no unit test framework for named templates, merge is not k8s aware (poor at inserting sidecars into pods, elements in containers in pods, etc.), the patterns in incubator/common for abstracting out common tasks are convoluted and difficult to debug
I use a version control system (e.g., git) instead of a repository with no index.yaml file, I use charts stored in locations other than a repository or a version control system
NoYes
subcharts have the start of the ability to abstract out common tasks
Issue #3481, PR #3471, Issue #2492, better lifecycle hook support (for creating managing release-revision owned resources)
I use the community charts as a foundation or template for my own charts that I store elsewhere
There is a huge amount of copy-pasta across the community charts. Helm needs to be better at abstracting out common tasks.
I do not use Kompose
I occassionally use Minikube
Laptop-local development, the "docker-env" subcommand
easily store --extra-config settings rather than repeatedly provide them on every "start".
MacOSVirtualBoxdefault (localkube)v1.9.x
--extra-config=controller-manager.ClusterSigningCertFile="/var/lib/localkube/certs/ca.crt" --extra-config=controller-manager.ClusterSigningKeyFile="/var/lib/localkube/certs/ca.key"
NoDocker
Software developed in-house, Open Source software
Stateless services, NoSQL databases
NeverNeverSometimesSometimesNeverUsuallySometimesUsuallyHelmYesYes
They need to work with our security requirements and infrastructure.
YesJenkins
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Jenkins, Helm, in-housePositive
81
4/5/2018 15:29:49
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes
I exclusively use the core workload controllers
I do not use Jobs and/or CronJobs
I use kubectl only when there’s a features gap in other tools I’m using
I use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)
I do not use HelmI do not use Kompose
I occassionally use Minikube
MacOS, Linux
VirtualBox, VMware Fusion
default (localkube)v1.8.x, v1.7.xYesDocker
Software developed in-house, Open Source software
Stateless servicesSometimesSometimesSometimesSometimesSometimesSometimesSometimesSometimesspinnakerNoNoNoStrongly Positive
82
4/5/2018 15:34:44
I operate applications on Kubernetes, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
I use Jobs and/or CronJobs
I use kubectl only when there’s a features gap in other tools I’m using
I use the Kubernetes Dashboard
I use Helm
I have deployed Charts created by others
YesNoNo
I use the community charts as a foundation or template for my own charts that I store elsewhere
I do not use KomposeI regularly use MinikubeMacOSHyperVYesDocker
Software developed in-house
Stateless services, Machine Learning training or serving
UsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsually
Helm, Metaparticle, Skipper
YesYesNoPositive
83
4/5/2018 15:38:47
I operate Kubernetes clusters for my organization, I operate applications on Kubernetes, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
I use Jobs and/or CronJobs
They solve the problems of some repetitive tasks
There should be the ability to conjure up a job when it's service is referenced in the cluster(like systemd sockets)
I regularly use kubectl
I use the Kubernetes Dashboard
I am evaluating Helm
I have deployed Charts created by others
No
I don't find it's syntax intuitive like jinja's
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
NoNo
I use the community charts as a foundation or template for my own charts that I store elsewhere
I used Kompose as one-time tool to bootstrap Kubernetes manifest.
I occassionally use Minikube
LinuxKVM2default (localkube)v1.10.xYesDocker
Software developed in-house, Open Source software
Stateless services, SQL databases, pbx
UsuallySometimesNeverUsuallyUsuallyUsuallyUsuallyNot ApplicableAnsible
Integration with existing infrastructure
NoYesNoStrongly Negative
84
4/5/2018 15:40:14
I operate Kubernetes clusters for my organization
I supplement the core workload controllers with custom controllers
Not a lot of fuss, work pretty well.
more flexibility with statetulset controllers to actually manage statefulsets, more documentation about how to use them effectively. The kube state metrics make it difficult to effectively monitor statefulsets.
I use Jobs and/or CronJobs
ease of use
ability to spin up more than just pods - service, deployments etc. Would like to use jobs to run periodic or event based load tests, integration tests, etc.
I regularly use kubectl
Primarily for inspecting the state of the system, sometimes to apply/edit/etc.
multiple names including plurals for resource names is incredible!
I'd like to be able to have more support for context switching, like, out of the box it should support different shells working in different contexts. Overall, I think it requires a lot too much typing to use effectively, so anyone who uses it regularly ends up defining tons of helper aliases and functions.
I use both the Kubernetes Dashboard and another UI
It has a clean UI, very easy to set up. Mostly it just works.
Don't really care, I use it very little.
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use object storage, a static web server, or similar system for my repository
No
I briefly worked on one but never completed it.
Yes
It aallows for a uniform way to deploy any application into my cluster, including cluster/system level tools.
I'd like more verbose error messages. Even when running with --debug (--dry-run), I have seen yaml errors that produce no useful output, no templates are rendered. If it is a particularly large chart, good luck finding the problem! I'd like to see a lot more security best practices around the tiller. I haven't been actively looking in the last 6 months though so maybe it is better now.
I operate production applications from the community charts
Get up to speed on running/deploying a new application much quicker than starting from scratch on my own
Not sure.I do not use Kompose
I occassionally use Minikube
Easy to set up
Not sure, I haven't used in nearly a year.
MacOSVirtualBoxdon't rememberv1.7.xIngress controllerYesDocker
Software developed in-house, Open Source software
Stateless services, NoSQL databases
UsuallyUsuallyUsuallySometimesSometimesUsuallyUsuallyUsuallyHelm
It made the most sense coming from a CM/Chef heavy background
YesYes
Custom workflow -- I wanted a simple cli to install/upgrade any application in any cluster that operated on a helm-config monorepo. Every helm release has a directory in the tree with values, encrypted values, and release metadata (like chart name, version, etc), the cli takes all that info and does the right thing, so something like `captain upgrade dev/auth --set imageTag=1.0.1-abcd1234` gets translated into something that will decrypt any encrypted configuration, merge in the configuration passed on the command line and then `helm upgrade auth-dev-microservice myCoCharts/jvm-microservice --version 0.2.7 -f dev/auth/values.yaml -f dev/auth/values_secrets.yaml`.
YesDrone
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster
Initially deploy my application to production, Deploy updates to my application to production
Strongly Positive
I wish that more kubernetes developers would spend more time running production kubernetes clusters. It is not an easy task to keep up with the rapid pace of change. Even using kops, I've run into a number of problems trying to upgrade. Some of the issues were kops specific but others were because of changes to core kubernetes (for instance, upgrading from 1.6.x to 1.7.x was not possible for statefulsets until 1.6.9, the metadata/labeling scheme broke dns resolution of pods in statefulsets!)
85
4/5/2018 15:48:42
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes
I exclusively use the core workload controllers
Deployment controllers are excellent. Totally meet our needs.
Re-Scheduling
I use Jobs and/or CronJobs
I only use Jobs at the moment. Love that I can just create a container for a one off job and it gets done.
Would like to see a retry limit (forgive me if it's already in there) to stop it running wild with the retry amount.
I regularly use kubectl
Get Pods, Get logs, describe pods.
I LOVE KUBECTL!
Currently it meets all of my needs.
I don’t use a graphical UI for Kubernetes
I don't.I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file, I use charts stored in locations other than a repository or a version control system
NoYes
Love the templating. Really easy to see what version i'm deployed on.
Better integration for CI / CD
I use the community charts for demo purposes only
Really quick for me to get something up and running
More charts.I do not use KomposeI do not use Minikube
Software developed in-house
Stateless services, NoSQL databases, Message queues, Traditional Batch or streaming data processing
UsuallyUsuallyUsuallySometimesUsuallySometimesNeverNeverHelmKOPS
Really easy to use. We didn't want to go down a terraform / chef route.
YesYes
We just build scripts to help us get CI and CD
NoStrongly PositiveI LOVE KUBERNETES!!!!
86
4/5/2018 15:55:40
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
I use Jobs and/or CronJobs
I regularly use kubectl
I use both the Kubernetes Dashboard and another UI
I use Helm
I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc)
NoNo
I operate production applications from the community charts
I do not use Kompose
I occassionally use Minikube
MacOSVirtualBoxdefault (localkube)v1.9.xYesDocker
Software developed in-house, Open Source software
Stateless services, SQL databases
UsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyUsuallyHelmSealedSecrets
Ability to host secrets on version control
NoNoNoPositive
87
4/5/2018 15:56:45
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends), I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
I use Jobs and/or CronJobs
I think there are a great abstractions and can replace a lot of home made solutions to have scheduled tasks.
Even if they were new features, they had major problems (pods being recreated infinitely on failures) that were blockers and that could have had a dramatic impact on the cluster itself. I think those impact where underestimated by the community.
I regularly use kubectl
Operate applications and debug problems with the cluster (as an operator).
It is great and really interactive!
There is a lot of magic in kubectl client side and that's often surprising. I would love to see this removed and migrated as much as possible to server side.
I don’t use a graphical UI for Kubernetes
I do not use HelmI do not use Kompose
I occassionally use Minikube
It's really great to get started.
It's (used to be) a bit different from a standard kubernetes deployment which makes it impossible to use it do deploy cluster level things.
MacOSVirtualBoxdefault (localkube)v1.9.xNoDocker
Software developed in-house
Stateless servicesUsuallyUsuallyUsuallyNeverSometimesUsuallyNeverUsuallyYesYesYesJenkins, Travis CI
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Positive
88
4/5/2018 15:58:49
I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends)
I supplement the core workload controllers with custom controllers
Pretty orthotrgonal to each other
Allow controllers to have tempaltes for other entites as well (ie custom resources)
I do not use Jobs and/or CronJobs
I regularly use kubectl
changes, listing, updating, adding plugin
good on the cli, provides all the features and power I need
pod based delivery of plugins, server side rendering support (I think this landed)
I use both the Kubernetes Dashboard and another UI
So close to kubectl. Close to what you can do.
An extension mechanism which is to the dashboard, what CRDs are to the API.
A _generic_ way to display CRDs in the dashboard.
I am evaluating Helm
I have developed Charts for use with Helm
Yes
I use the community stable or incubator repositories, I use a version control system (e.g., git) instead of a repository with no index.yaml file
NoNo
I use the community charts for demo purposes only
I do not use KomposeI regularly use Minikube
Simple! Works! Great showcase! It has all the important bits liek storage provisioner and dashbaord! And is so "vanilla" kube
multinode (optional) Then you can showcase everything!
LinuxKVM2default (localkube)v1.9.x, v1.8.x
featureGate=DevicePlugins
YesDocker, cri-oOpen Source softwareStateless servicesUsuallyUsuallyUsuallySometimesSometimesSometimesSometimesSometimes
Ansible, OpenShift templates
Ease of use (especially templates)
NoNoYesJenkins, Travis CI
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Deploy my application to a test cluster or namespace
Test or lint my kubernetes object configuration, Test upgrading my application
Positive
Thanks for the efforts put into this questionaire. They looedk good.
89
4/5/2018 16:04:29
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
Deployments meet my most common use cases. I barely use the others.
There are frustrating inconsistencies and special cases in Deployments -- like not being able to modify labels, changing API version (which broke tons of stuff for us), and kubectl commands that don't make it transparent what's really going on.
I use Jobs and/or CronJobs
Definitely meets my base case needs.
The documentation on the cron date formats should be real documentation, not a pointer to the Wikipedia entry for Cron. Also, when I delete a CronJob, it's unclear why the Jobs it creates don't get cleaned up too.
I regularly use kubectl
logs, exec, get. Debugging. Occasionally things that kubectl can do, but which the API server can't (grrrr).
I like kubectl exec.
I feel like kubectl is forced on me because random developers decided to do important/complex Kubernetes logic on the client side, and there's just no available alternative. Consequently, I prefer Helm for most of what kubectl tries to do because Helm is easier to use. I would rather NOT have to use kubectl to perform apply logic and other things where the code is oddly wrapped into the client instead of the API server.
I don’t use a graphical UI for Kubernetes
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
No
I want reusable libraries, and the syntax is yucky once charts reach moderate complexity
I use the community stable or incubator repositories, I use object storage, a static web server, or similar system for my repository, I use a version control system (e.g., git) instead of a repository with no index.yaml file, I use charts stored in locations other than a repository or a version control system
Yes
helm last, helm template, helm gpg
Yes
Easy to use, meets my needs, decent docs
Die, Tiller, Die.
I operate production applications from the community charts
Good assortment of deep Kubernetes stuff. Getting things like LEGO set up is HUGE for me. Also, it is a great example of good chart dev practices
I do not use KomposeI regularly use Minikube
9p and the volumes configuration is great. Once I have it working, it is great. It's easy to turn on features like RBAC and turn off things like Dashboard.
It feels like every single release breaks something. I defer updating until I have a free afternoon. The multiple bootstrappers is annoying, especially because some versions can only be deployed with certain bootstrappers (and this is mostly undocumented). The documentation is sparse, and I often have to read closed issues and source code to find simple things. Networking is sort of annoying sometimes (contrast with Docker's Kubernetes, where networking is automatic).
MacOS, Linux
VirtualBox, KVM2, xhyve
default (localkube), kubeadm, The fact that this is a question illustrates a problem.
v1.9.x, v1.8.x
apiserver.Authorization.Mode=RBAC
storage-provisioner, default-storageclass, addon-manager, kube-dns
NoDocker
Software developed in-house, Open Source software
Stateless services, NoSQL databases, Traditional Batch or streaming data processing, Machine Learning training or serving
SometimesSometimesSometimesSometimesNeverNeverSometimesUsuallyDraft, HelmYesThey do what I needYesYes
To integrate with our existing services
Yes
CircleCI, Jenkins, Brigade
Build container images, Push container images to a registry, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Test upgrading my application
github utlities, make, compilers, yarn, slack tools, docker (DinD), cloud services, linters, helm
Negative
90
4/5/2018 16:07:20
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API
I supplement the core workload controllers with custom controllers
I use Jobs and/or CronJobs
common way to extract or persist artifacts and logs
I regularly use kubectllogs, exec, etc
I don’t use a graphical UI for Kubernetes
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc)
NoYes
secure by default; remove tiller; align with k8s namespace philosophy
I use the community charts as a foundation or template for my own charts that I store elsewhere
storage classes are taken for granted breaking local development in some cases; rbac needs admin in some cases breaking dev/prod parity. useful "helm tests" would be ideal. integration with secret rotation
I do not use KomposeI regularly use MinikubeMacOSVirtualBox, xhyve
default (localkube), kubeadm
v1.10.x, v1.9.x, v1.8.xYesDocker, rkt
Software developed in-house, Open Source software, Proprietary 3rd party solutions (e.g., Oracle database)
Stateless servicesSometimesSometimesSometimesNeverUsuallyUsuallyUsuallyUsuallyHelm, Terraform
documentation; ease of use
YesNo
bootstrapping; certificate management; multi-tenant provisioning; expose cloud metadata to pod
NoStrongly Positiveistio is cool too
91
4/5/2018 16:17:51
I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends), I develop internal tools for running, managing, and validating applications that run on Kubernetes
I do not use the workload controllers
I do not use Jobs and/or CronJobs
I regularly use kubectl
I use kubectl exclusively to interact with cluster
segmentation of commands
reduction of verbosity of params for certain commands, ability to remember last set of related params, ability to add alias
I don’t use a graphical UI for Kubernetes
kubectlI use Helm
I have deployed Charts created by others
Yes
I use the community stable or incubator repositories
NoNo
I like the level of abstraction that it hides (similar to kubectl)
Customization relies heavily o n yaml config. Combination of template and yaml creates a new set of atifacts to maintain, now you have two problems.
I use the community charts for demo purposes only
Most of them feels really solid with little surprises.
I do not use KomposeI regularly use Minikube
Minikube works really hard at keeping the amount of commands low to get started and be productive
MacOSVirtualBoxv1.10.xDNS, dashboardNoDockerOpen Source software
Stateless services, Traditional Batch or streaming data processing, Machine Learning training or serving
UsuallyUsuallyNot ApplicableUsuallyUsuallyNot ApplicableUsuallyUsuallyNoNoNoStrongly Positive
Kubernetes is a great platform with more opportunities to come. I will continue to participate in the community to help find ways to make it super easy for developers to create distributed applications that runs on the platform.
92
4/5/2018 16:46:40
I operate applications on Kubernetes
I exclusively use the core workload controllers
I use Jobs and/or CronJobs
Ability to set-image on cronjobs. Ability to add labels to underlying job
I regularly use kubectl
I don’t use a graphical UI for Kubernetes
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
No
I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc), I use a version control system (e.g., git) instead of a repository with no index.yaml file
Yestemplate, ksonnetYes
I use the community charts for demo purposes only
I do not use KomposeI do not use Minikube
Software developed in-house, Open Source software
Stateless services, Traditional Batch or streaming data processing
UsuallySometimesUsuallySometimesUsuallySometimesUsuallyNeverHelm, jsonnet, ksonnetYesYesYesJenkins, Concourse
Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster
Test or lint my kubernetes object configuration, Test upgrading my application, Deploy updates to my application to production
Strongly Positive
93
4/5/2018 16:52:40
I operate applications on Kubernetes
I exclusively use the core workload controllers
SimplicityYes
I use Jobs and/or CronJobs
More simplicityI regularly use kubectlEverythingIt's power
I don’t use a graphical UI for Kubernetes
I do not use HelmI do not use Kompose
I occassionally use Minikube
SimplicityMacOSHyperkitdefault (localkube)v1.10.xNoDocker
Software developed in-house
Stateless services, Message queues, Traditional Batch or streaming data processing
UsuallyUsuallySometimesNot ApplicableSometimesNot ApplicableUsuallyUsually
Ansible, jsonnet, ksonnet, Terraform
NoNoYesJenkins
Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace
Positive
More support in toning resource will be appreciated
94
4/5/2018 16:54:40
I operate Kubernetes clusters for my organization, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I do not use the workload controllers
I use Jobs and/or CronJobs
I regularly use kubectleasy to use
I wish I could get JSON or YAML output for more queries.
I don’t use a graphical UI for Kubernetes
I use Helm
I have developed Charts for use with Helm, I have deployed Charts created by others
Yes
I use a repository service (Quay/App Registry, ChartMuseum, etc), I use a version control system (e.g., git) instead of a repository with no index.yaml file
NoNo
app registry with helm is kind of a PITA sometimes.
I use the community charts as a foundation or template for my own charts that I store elsewhere
They're a decent baseline from which to start in order to contribute back to the community after extending them
I do not use Kompose
I occassionally use Minikube
MacOS, LinuxVirtualBoxdefault (localkube)v1.8.xYesDocker, rkt
Software developed in-house, Open Source software
Stateless services, Traditional Batch or streaming data processing
SometimesSometimesSometimesSometimesUsuallySometimesUsuallySometimesHelm, jsonnetkubectx, kubensYesYes
usually the latter for now but contribution to the community is the goal
YesGitlab CI
Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace, Test upgrading my application, Initially deploy my application to production
Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Test or lint my kubernetes object configuration, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Deploy updates to my application to production
gitlab-ci with failfast, docker, helm
Positive
some of my answers are vague as I'm new to this shop and am still drinking from the firehose. I answered the best I could with the knowledge I currently have.
95
4/5/2018 17:13:31
I develop applications that interact with the Kubernetes API, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I supplement the core workload controllers with custom controllers
Flexibility
I do not use Jobs and/or CronJobs
I use kubectl only when there’s a features gap in other tools I’m using
apicontent assist
I use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)
I do not use HelmI do not use Kompose
I occassionally use Minikube
SimplicityWindows, MacOS, Linux
VirtualBox, xhyve, HyperV
default (localkube)v1.8.xYesDockerOpen Source software
Machine Learning training or serving
UsuallySometimesUsuallyUsuallySometimesUsuallyUsuallyUsually
Compose, fabric8-mvn-plugin, fabric8 client, OpenShift templates
NoNoYesJenkins, Jenkins X
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Deploy my application to a test cluster or namespace, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Positive
96
4/5/2018 17:18:37
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes
I exclusively use the core workload controllers
I do not use Jobs and/or CronJobs
I regularly use kubectl
object creation/status monitoring
remote cluster management
easier way to change between clusters.
I use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)
I do not use Helm
I used Kompose as one-time tool to bootstrap Kubernetes manifest.
I do not use Minikube
Software developed in-house, Open Source software
Stateless services, SQL databases
UsuallyUsuallyUsuallyUsuallyUsuallyNeverUsuallyUsually
Ansible, OpenShift templates
NoNoPositive
The one major issue that I find lacking is understanding why my pods don't run at times. The necessary searching via various files and logs to get it is frustrating.
97
4/5/2018 17:42:36
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I develop internal tools for running, managing, and validating applications that run on Kubernetes
I exclusively use the core workload controllers
I do not use Jobs and/or CronJobs
I regularly use kubectl
I use both the Kubernetes Dashboard and another UI
I use Helm
I have developed Charts for use with Helm
Yes
I use object storage, a static web server, or similar system for my repository
NoYes
I use the community charts for demo purposes only
I do not use KomposeI do not use Minikube
Software developed in-house
Stateless services, SQL databases, Traditional Batch or streaming data processing
UsuallySometimesUsuallyUsuallySometimesSometimesUsuallyNeverHelm, TerraformYesNoYesJenkins
Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Programatically update or alter Kubernetes manifest files, Test upgrading my application
Strongly Positive
98
4/5/2018 17:50:46
I operate Kubernetes clusters for my organization, I operate Kubernetes clusters to support my application development, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API, I develop extensions to Kubernetes (e.g., storage back-ends), I develop internal tools for running, managing, and validating applications that run on Kubernetes
I do not use the workload controllers
I do not use Jobs and/or CronJobs
I do not use kubectl
I don’t use a graphical UI for Kubernetes
Tectonic ConsoleI do not use HelmI do not use KomposeI regularly use MinikubeMacOS, LinuxKVM2, Hyperkitkubeadmv1.10.x, v1.9.xNoDocker, cri-oOpen Source softwareStateless servicesNeverNeverNeverNeverNeverNeverNeverNever
Compose, jsonnet, Kinflate, Skaffold
NoNoYes
Build container images, Push container images to a registry, Generate Kubernetes manifest files, Programatically update or alter Kubernetes manifest files, Test or lint my Kubernetes object configuration, Deploy my application to a test cluster or namespace, Test upgrading my application, Deploy my application to a staging or quality assurance (QA) cluster, Initially deploy my application to production, Deploy updates to my application to production
Strongly Negative
99
4/5/2018 17:53:03
I operate Kubernetes clusters for my organization, I operate applications on Kubernetes, we build custom k8s clusters with tk8
I exclusively use the core workload controllers
I use Jobs and/or CronJobs
I regularly use kubectl
for everything to deploy and manage
a better cheat sheet
I don’t use a graphical UI for Kubernetes
I do not use HelmI do not use KomposeI regularly use Minikubeeasy to use
multi node support with kubeadm
MacOSVirtualBox, xhyvedefault (localkube)v1.10.x, v1.9.xYesDocker
Software developed in-house, Open Source software
Stateless servicesUsuallySometimesUsuallySometimesUsuallySometimesUsuallySometimesKedge, Skaffoldthe old good make
we build clusters with make and kops and deploy apps with make as well
YesYes
We build tk8 based on Kuberspray with Ansible and Terraform support, please read the problem statement here:
https://github.com/kubernauts/tk8#problem-statement
NoStrongly PositiveThank You!
100
4/5/2018 18:03:21
I operate Kubernetes clusters for my organization, I operate applications on Kubernetes, I develop applications that interact with the Kubernetes API
I exclusively use the core workload controllers
Good fit for real world needs
Better integration of deployments with autoscaling
I use Jobs and/or CronJobs
It is very necessary concept
Seems to be a very un-loved area, and needs much better integration with HPC-type capabilities
I regularly use kubectl
Actually I mostly use Openshift's oc, which I use to manage and monitor the openshift cluster
awesome functionality, 'oc explain ...'
nothing really
I use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)
I do not use HelmI do not use Kompose
I occassionally use Minikube
Really I use Minishift, but I guess that counts. It's a nice simple way to get started and test things.
Better consistency with OpenShift proper e.g. wrt persistence
MacOS, LinuxVirtualBox, KVM, xhyveminishiftv1.7.x, v1.6.xNoDocker
Software developed in-house, Open Source software
Stateless services, SQL databases, NoSQL databases, Message queues, CI/CD, SSO, monitoring, logging, metrics
UsuallySometimesSometimesNeverNeverSometimesUsuallySometimes
Ansible, fabric8 client, OpenShift templates, Terraform
bash!YesYes
plug the gaps, join the pieces together
NoPositive
Loading...
 
 
 
Form Responses 1