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 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?

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.

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 occassionally use Minikube

It was really easy to install & set up

Software developed in-house, Open Source software

Custom Kubernetes controllers + CRDs

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

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 use the Kubernetes Dashboard

Software developed in-house, Open Source software

Stateless services, Traditional Batch or streaming data processing

Ansible, Skaffold, Terraform

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

Applying changes to Kubernetes objects.

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

A little more predictability in refresh behaviors.

I have developed Charts for use with Helm, I have deployed Charts created by others

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

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

The only way to run Kubernetes for free on my laptop easily.

Software developed in-house, Open Source software

Stateless services, SQL databases, NoSQL databases, Message queues, Traditional Batch or streaming data processing

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.

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

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

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 have developed Charts for use with Helm, I have deployed Charts created by others

I use the community stable or incubator repositories, I use object storage, a static web server, or similar system for my repository

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

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 occassionally use Minikube

it works locally, recently with even better hypervisor

ingress controller, registry

Software developed in-house

they were the simplest to start with
they were ones of the most supported by community

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

I do not use the workload controllers

I do not use Jobs and/or CronJobs

I don’t use a graphical UI for Kubernetes

Software developed in-house

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 don’t use a graphical UI for Kubernetes

I have deployed Charts created by others

I use the community stable or incubator repositories

I use the community charts for demo purposes only

I occassionally use Minikube

Stateless services, Traditional Batch or streaming data processing

Draft, generator-kubegen, Helm, OpenShift templates

CircleCI, Gitlab CI, Travis CI

Build container images, Programatically update or alter Kubernetes manifest files, Test upgrading my application

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 use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)

I used Kompose as one-time tool to bootstrap Kubernetes manifest.

Software developed in-house, Open Source software

Stateless services, SQL databases, NoSQL databases

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

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

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 have deployed Charts created by others

I use the community stable or incubator repositories

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

Software developed in-house, Open Source software

Stateless services, SQL databases, Message queues

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 use the Kubernetes Dashboard

I have developed Charts for use with 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

I use the community charts for demo purposes only

Software developed in-house, Open Source software

Draft, Helm, Metaparticle, Skaffold

CircleCI, Jenkins, Jenkins X, Travis CI

Build container images, Push container images to a registry

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

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

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)

Software developed in-house

Stateless services, Traditional Batch or streaming data processing

Ansible, kubecfg, Terraform

Because I want easy git push to running in prod.

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

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

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

Software developed in-house, Open Source software, Proprietary 3rd party solutions (e.g., Oracle database)

Stateless services, SQL databases, NoSQL databases

Bosh is the best tol for immutable infrastructure

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

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.

interacting with my k8s cluster

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 have developed Charts for use with 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

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 occassionally use Minikube

i'd like minikube to be a better representation of a real multi-node cluster

default (localkube), kubeadm

Software developed in-house, Open Source software

Stateless services, Traditional Batch or streaming data processing

Helm, jsonnet, ksonnet, kubecfg

Build container images, Push container images to a registry, Programatically update or alter Kubernetes manifest files

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 don’t use a graphical UI for Kubernetes

I have developed Charts for use with Helm, I have deployed Charts created by others

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

I operate production applications from the community charts

Software developed in-house, Open Source software

Stateless services, NoSQL databases

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

I operate Kubernetes clusters for my organization

I exclusively use the core workload controllers

I use Jobs and/or CronJobs

I don’t use a graphical UI for Kubernetes

I occassionally use Minikube

Software developed in-house, Open Source software

Stateless services, SQL databases

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

Support needed in the back end or config for multi-location scaling and deployment.

I do not use Jobs and/or CronJobs

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 occassionally use Minikube

It's an easy and free demo of a cluster.

Software developed in-house, Open Source software

Stateless services, SQL databases, NoSQL databases

We only need very simple deploy tools currently, and most existing tools are very complex.

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

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 occassionally use Minikube

it's ok for local development

less resource consumption

various alpha settings from time to time

Software developed in-house

Stateless services, Machine Learning training or serving

It doesn't require our developers to write and manage templates

It gives us a way to control our own custom environment in a centralized manner, yet still provides total freedom to engineering teams.

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

I operate Kubernetes clusters for my organization

I exclusively use the core workload controllers

I use Jobs and/or CronJobs

Distributed cron jobs are amazing

Lots of things but I like the dashboard way better

I use the Kubernetes Dashboard

Excise which namespace you're in a little more prominently

I have deployed Charts created by others

I use the community stable or incubator repositories

ARM support and competition

I operate production applications from the community charts

Local dev environment simplification

Software developed in-house, Open Source software

Ansible, Skaffold, Terraform

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

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 have developed Charts for use with Helm, I have deployed Charts created by others

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

I operate production applications from the community charts

Software developed in-house, Open Source software

Stateless services, Message queues, Traditional Batch or streaming data processing

Helm, ksonnet, Terraform

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

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

Apply changes and get objects

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 have developed Charts for use with 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

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

Better vetting of some charts (But that's rather easy to do with a PR if an error occurs)

Easily bootstrap a dev environment locally

Keep more up to date with latest K8s versions and appropriate addons

default (localkube), kubeadm

addon-manager, dashboard, default-storageclass, freshpod, heapster, ingress, kube-dns, registry, storage-provisioner, metrics-server

SQL databases, Traditional Batch or streaming data processing

Easy to design a CI/CD pipeline around, rather than a supplied CI/CD solution

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

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)

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

I use a version control system (e.g., git) instead of a repository with no index.yaml file

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 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

default (localkube), kubeadm

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

Patch shortcomings in existing tools and bridge transitions from one tool to another

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

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.

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

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 have developed Charts for use with Helm, I have deployed Charts created by others

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

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

It's unclear what the upgrade policy is; I'd like them to be stable over years.

Software developed in-house, Open Source software

Stateless services, SQL databases, Traditional Batch or streaming data processing

http://github.com/aarondl/kctl

Just the basics, more or less

Bridging existing external things with kubernetes

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

I am not using minikube because it needed better support for storage.

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

easier way to "set current namespace" so i dont have to type -n ALL THE TIME

I use the Kubernetes Dashboard

I have developed Charts for use with Helm, I have deployed Charts created by others

I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc)

I operate production applications from the community charts

Software developed in-house, Open Source software

Stateless services, SQL databases, NoSQL databases

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

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 use the Kubernetes Dashboard

better authentication support

I have developed Charts for use with 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

I operate production applications from the community charts

I occassionally use Minikube

Software developed in-house, Open Source software

Stateless services, Traditional Batch or streaming data processing

to automatically attach additional metadata to deployed resources

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

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

Provide better support for bootstrapping and self-hosting clusters (kubeadm)

I do not use Jobs and/or CronJobs

get, create, replace, apply, rollout status, rollout undo, whatever

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 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).

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

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!

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 have developed Charts for use with Helm, I have deployed Charts created by others

I use the community stable or incubator repositories, I use object storage, a static web server, or similar system for my repository

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

Software developed in-house, Open Source software, Proprietary 3rd party solutions (e.g., Oracle database)

Stateless services, SQL databases, NoSQL databases

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

To manage everything actually

I don’t use a graphical UI for Kubernetes

Default kubernetes dashboard

I have developed Charts for use with Helm

I use charts stored in locations other than a repository or a version control system

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

I occassionally use Minikube

Disable swap and local volume

Dashboard,heapster,kubedns,kubeproxy, all the default add-ons

Software developed in-house, Open Source software, Proprietary 3rd party solutions (e.g., Oracle database)

Stateless services, Statefull application

Thanks for making such a good improvement to kubernetes

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

A success/failure notification system built in (slack/email/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 have developed Charts for use with Helm, I have deployed Charts created by others

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

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

More "how to make this public chart production ready"

Great for development environments

An OSX dropdown app that tells you the status, IP addresses, etc

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

Ansible, Helm, kubecfg, Skipper, Terraform

Quality of life improvements, locking down clusters, etc

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

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 don’t use a graphical UI for Kubernetes

Software developed in-house, Open Source software

Stateless services, Message queues

Programmability, closeness to JSON, conciseness

Safety, predictability, auditability

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

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.

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 have developed Charts for use with Helm, I have deployed Charts created by others

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

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

Quality of the community, number of available apps, usability.

Kubernetes is awesome. I love the direction the community is going.

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 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.

I have developed Charts for use with Helm, I have deployed Charts created by others

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

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.

I occassionally use Minikube

Easy to get running, easy to use.

Software developed in-house, Open Source software

Stateless services, Message queues, Traditional Batch or streaming data processing

Helm for templating and installs around differing environments. Ksync for fast development on the cluster.

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).

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.

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

Everything to do with cluster management

CLI discoverability and output flexibility

I use both the Kubernetes Dashboard and another UI

More management capability

I have developed Charts for use with Helm, I have deployed Charts created by others

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

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).

Software developed in-house, Open Source software

Stateless services, SQL databases

They are either designed to deploy to Kubernetes (Helm) or conceptualize Kubernetes as an infrastructure medium for generic deployments (Ansible/Terraform)

Working from existing legacy deployment systems toward more native processes.

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.

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

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

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

Software developed in-house, Open Source software

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.

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

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

It's a good tool but need better user experience

better config management

I don’t use a graphical UI for Kubernetes

I have deployed Charts created by others

I use the community stable or incubator repositories

I use the community charts for demo purposes only

I occassionally use Minikube

A good tool to taste kubernetes

VirtualBox, VMware Fusion, KVM, xhyve

Software developed in-house, Open Source software

Ansible, OpenShift templates

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

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

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.

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

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 have developed Charts for use with Helm, I have deployed Charts created by others

I use the community stable or incubator repositories, I use object storage, a static web server, or similar system for my repository

*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

For my purposes they are fine. I think they should aim to be good starting points.

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

Software developed in-house, Open Source software

Stateless services, Message queues

helper applications and scripts are always(*) necessary to fit things together, particularly when doing CI/CD

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

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

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)

Stateless services, SQL databases, NoSQL databases

Ansible, OpenShift templates

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

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

create and manage objects. explore the environment

I use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)

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

I occassionally use Minikube

self contained and reproducible for demos/tutorials

Software developed in-house, Open Source software

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

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

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).

Bug fixed that prevents non-root pods to access pv (fsgid ignored).

Software developed in-house, Open Source software

Stateless services, Message queues, Traditional Batch or streaming data processing

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

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

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

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 have deployed Charts created by others

I use the community charts for demo purposes only

I occassionally use Minikube

Software developed in-house, Open Source software

need production ready solutions,

Our tools were built 2 years ago before other tools(helm) were ready. We want standardization, solid integration with github and ci tools

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

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 use the Kubernetes Dashboard

I use the community charts as a foundation or template for my own charts that I store elsewhere

Software developed in-house, Open Source software

Stateless services, Traditional Batch or streaming data processing

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

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

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

I have developed Charts for use with Helm, I have deployed Charts created by others

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

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

Software developed in-house, Open Source software

Stateless services, SQL databases, NoSQL databases, Message queues, Traditional Batch or streaming data processing

developed in house and released publicly

If we can't find opensource solutions, we build (or upstream) to get them.

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

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

RBAC, deployments, debugging

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 have developed Charts for use with Helm

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

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 occassionally use Minikube

Software developed in-house

Stateless services, SQL databases, NoSQL databases, Message queues

So we can add opinionated deployments and enforce internal policies.

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

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 use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)

I have developed Charts for use with Helm, I have deployed Charts created by others

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

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'

it's really getting better, seamless local operation

Software developed in-house, Open Source software

Stateless services, NoSQL databases, Traditional Batch or streaming data processing

Build container images, Push container images to a registry, Deploy my application to a test cluster or namespace, Initially deploy my application to production

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 use the Kubernetes Dashboard

Approachable for less cli-oriented people

Integration with cluster auth provider (ie OIDC/Oauth2)

I have developed Charts for use with 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

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...

Software developed in-house, Open Source software

Stateless services, SQL databases, NoSQL databases, Message queues

Custom workflows, ease of use (template away options that shouldn't be changed)

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

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 do not use Jobs and/or CronJobs

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 have developed Charts for use with Helm, I have deployed Charts created by others

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

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

Software developed in-house, Open Source software

Stateless services, Traditional Batch or streaming data processing

Ansible, Draft, fabric8 client, Helm

Ease the inhouse ci CD pipeline for applications

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

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 occassionally use Minikube

VirtualBox, VMware Fusion

Software developed in-house

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

I use the Kubernetes Dashboard

I have developed Charts for use with Helm, I have deployed Charts created by others

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

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 occassionally use Minikube

current localkube service is not that easy to kill. the asme experience as docker edge on macos would be nice to see on linux.

Software developed in-house, Open Source software

Stateless services, SQL databases, NoSQL databases, Message queues

Helm is a most general and easy to use tool.

Cistome workflows, CRDs, custom resources

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

This a great survey, thank you for doing this.

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 the Kubernetes Dashboard

More details about what caused readiness or liveness probes to fail.

I have deployed Charts created by others

I use the community stable or incubator repositories

I operate production applications from the community charts

I occassionally use Minikube

Software developed in-house

Stateless services, Message queues, Prometheus.

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

Thanks for your awesome work.

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 have deployed Charts created by others

I use the community charts for demo purposes only

Software developed in-house, Open Source software

SQL databases, NoSQL databases, Message queues, Traditional Batch or streaming data processing, Machine Learning training or serving

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

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

Inspecting cluster objects

coherent set of tools for inspecting cluster

command completion when specifying namespaces

I use the Kubernetes Dashboard

I have developed Charts for use with Helm, I have deployed Charts created by others

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

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.

apiserver.Authorization.Mode=RBAC

Software developed in-house

Stateless services, Message queues

Managing automated application lifecycle

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

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

Event triggered jobs (yep, hard to express what/how you trigger upon, parameters, etc)

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

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.

default (localkube), kubeadm

Used to add RBACs (c.a. 1.6~1.7) , none nowadays or maybe if I want/need to explicitly test some new feature

Software developed in-house, Open Source software

Stateless services, NoSQL databases

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.

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

Thanks for the awesome work !, truly cloud-native computing FOR THE MASSES :)

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

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.

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 have developed Charts for use with 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

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

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

Seems to be stable, easy to extend, easy to install, and popular enough that we don't need to worry about it going away.

Can't find existing tools to do our job.

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

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 don’t use a graphical UI for Kubernetes

Software developed in-house, Open Source software

Stateless services, SQL databases

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 work in a similar fashion to linux cron

Ability to specify timezone

All interaction with the cluster/all mentioned above

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

Software developed in-house

Stateless services, Message queues

Template j2 configurations before pushing to kubernetes

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

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

Keep kops more up to date with current version release

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 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 have developed Charts for use with 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

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

Software developed in-house, Open Source software

Stateless services, NoSQL databases, Traditional Batch or streaming data processing

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.

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

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.

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 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 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

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 occassionally use Minikube

Software developed in-house

Stateless services, Traditional Batch or streaming data processing, Machine Learning training or serving

Except for Helm, I already knew those tools

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

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

I have developed Charts for use with Helm, I have deployed Charts created by others

I use the community stable or incubator repositories, I use object storage, a static web server, or similar system for my repository

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)

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

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

default (localkube), kubeadm

Stateless services, Traditional Batch or streaming data processing, Machine Learning training or serving

https://github.com/ahmetb/kubectx

I write tools to run applications on kubernetes, but I am not a system administrator that manages these applications.

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

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.

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

I have developed Charts for use with Helm, I have deployed Charts created by others

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

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

I'd like to see best practices and "how to create charts" better documented to help me create my own charts

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

default (localkube), kubeadm

--memory all the damn time

heapster, ingress - wish there was a load balancer

Software developed in-house, Open Source software

Stateless services, SQL databases, NoSQL databases, Message queues

Draft, Helm, ksonnet, Skaffold

validating the charts I generate within Helm before they hit a live cluster

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

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.

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

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

I have developed Charts for use with Helm, I have deployed Charts created by others

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

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 tested releases. One out of 3 is buggy

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

Draft, fabric8 client, Helm, Helmfile, Kedge, Skaffold, Terraform

Problems solved. Stability. Community

Tools for on premise deployments without requiring Kubernetes knowledge

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

Thank you guys for your great work!

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

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 have developed Charts for use with Helm, I have deployed Charts created by others

I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc)

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 occassionally use Minikube

nice for testing things locally

Software developed in-house, Open Source software

Stateless services, SQL databases, Message queues, Machine Learning training or serving

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

I operate Kubernetes clusters for my organization

I exclusively use the core workload controllers

I do not use Jobs and/or CronJobs

I don’t use a graphical UI for Kubernetes

I don’t use the community charts

Open Source software, Proprietary 3rd party solutions (e.g., Oracle database)

Stateless services, SQL databases

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

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

Allow restart policy/limits. Allow Guaranteed single run (with or without failures).

Intuitive/consistent sub commands and options

Better support for sort/filter. Simpler alternatives to jsonpath and gotemplate.

I use the Kubernetes Dashboard

consolidated views for logs/stats/events using label selectors. For example live tailing logs for all pods in a service.

I have developed Charts for use with Helm, I have deployed Charts created by others

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

Simple UX, decent dependency management, leads to better contracts with app devs

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 occassionally use Minikube

Simple & Powerful dev environment

v1.10.x, v1.9.x, v1.8.x, v1.7.x

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

Simple flexible tools, battle tested. Do not change the native experience too much

Mostly around local development (so tooling around draft currently) and advanced deployment strategies (doing A/B tests, canaries etc)

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

Great community, great product. If we keep this up another 2-3 years I believe it will be de facto standard for application management

I develop applications that interact with the Kubernetes API

I do not use the workload controllers

I use Jobs and/or CronJobs

Inspect my cluster, deploy stuff, debug stuff.

I don’t use a graphical UI for Kubernetes

Software developed in-house

Stateless services, SQL databases

Great community; works well

Need existing tools can't fill

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

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

Manage, debuggen, deploy tests

Compatibility to multiple versions

Definition of compatibility to api

I don’t use a graphical UI for Kubernetes

I have deployed Charts created by others

I don’t use the community charts

I occassionally use Minikube

Software developed in-house, Open Source software

Stateless services, SQL databases, NoSQL databases, Message queues

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

Resource saving when job ends

Easy common commands like logs view on pods of a deployment

I use the Kubernetes Dashboard

Simplicity, resource based

Better monitoring and metrics

I have deployed Charts created by others

I use the community stable or incubator repositories

I use the community charts for demo purposes only

I occassionally use Minikube

Software developed in-house, Open Source software

Stateless services, SQL databases, NoSQL databases, Message queues

Custom workflow involving external multi-tenant services

Kubernetes gave me a new opportunity to my business

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

pluggable extensions easy to deploy on existing cluster

I do not use Jobs and/or CronJobs

I use the Kubernetes Dashboard

Simplify using rbac and metric api without heapster

I have developed Charts for use with Helm, I have deployed Charts created by others

Need better security for secrets

I use the community stable or incubator repositories

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

Regular updates, better docs

Software developed in-house

Stateless services, SQL databases

Standardized deployment

Generate Kubernetes manifest files

Too hard to upgrade between versions. Should be much easier.

I operate applications on Kubernetes

I do not use the workload controllers

I do not use Jobs and/or CronJobs

better error messages, esp when trying to run against older cluster

I don’t use a graphical UI for Kubernetes

I don’t use the community charts

Software developed in-house, Open Source software

Stateless services, Machine Learning training or serving

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

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

I use Jobs and/or CronJobs

The easy of use, most other orchestrators don't have full support for these components

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 have developed Charts for use with Helm

I use the community stable or incubator repositories, I use a repository service (Quay/App Registry, ChartMuseum, etc)

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

Software developed in-house, Open Source software

Stateless services, Message queues

CI processes updating ancillary tools

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

Thanks for all the amazing work you all do.

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 use a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)

Software developed in-house

Stateless services, NoSQL databases, Message queues

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.

We started them before most of the above where available. Users are used to the power of AuroraConfig now

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

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 a different UI instead of the Kubernetes Dashboard (e.g. one provided by OpenShift, Tectonic, Weave Cloud)

I have developed Charts for use with 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

I use the community charts as a foundation or template for my own charts that I store elsewhere

Software developed in-house, Open Source software

Ansible, Helm, Kinflate, Skaffold

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

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

Better support for sidecar containers and something like end-step containers, something that fires off when the main containers have completed.

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 have developed Charts for use with Helm, I have deployed Charts created by others

I use a version control system (e.g., git) instead of a repository with no index.yaml file

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

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

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

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

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

Software developed in-house, Open Source software

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

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 use Jobs and/or CronJobs

Manage deployment, rbac, statefull set

I don’t use a graphical UI for Kubernetes

I have deployed Charts created by others

I use the community stable or incubator repositories

I operate production applications from the community charts

I occassionally use Minikube

Software developed in-house, Open Source software

Stateless services, SQL databases, Traditional Batch or streaming data processing

Ansible, Helm, Helmfile, OpenShift templates, Terraform

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

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

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 have developed Charts for use with 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

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

Software developed in-house, Open Source software

Stateless services, SQL databases, NoSQL databases, Message queues, Traditional Batch or streaming data processing

We have large deployments so our biggest concerns are correctly generating manifests and getting visibility into their deployment

for multi-datacenter deployments and to combine pieces of infrastructure necessary for our use cases

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

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 don’t use a graphical UI for Kubernetes

Software developed in-house, Open Source software

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

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

Better authentication support

I use the Kubernetes Dashboard

updates without refreshing

I have developed Charts for use with 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

I use the community charts as a foundation or template for my own charts that I store elsewhere

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

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

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

I do not use Jobs and/or CronJobs

Shortcuts. Less wordy instructions

I use the Kubernetes Dashboard

I have deployed Charts created by others

I use a repository service (Quay/App Registry, ChartMuseum, etc)

I don’t use the community charts

Software developed in-house, Open Source software

Stateless services, NoSQL databases

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

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 like the convention of it. kubectl Verb Noun

I use both the Kubernetes Dashboard and another UI

I have deployed Charts created by others

I use the community stable or incubator repositories

I operate production applications from the community charts

I used Kompose as one-time tool to bootstrap Kubernetes manifest.

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

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

better deployment strategies and hooks available in standard deployments

I do not use Jobs and/or CronJobs

to generate, load, and manipulate resource spec files

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)

It helps ensure that K8s is easy to try for free, minimal effort to get started. Nice onboarding experience.

default (localkube), kubeadm

v1.10.x, v1.9.x, v1.8.x, v1.7.x, v1.6.x

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

Ansible, OpenShift templates

CircleCI, Codeship, Gitlab CI, Jenkins, Travis CI

Test or lint my Kubernetes object configuration, Test upgrading my application

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

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 have developed Charts for use with Helm

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

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 occassionally use Minikube

Laptop-local development, the "docker-env" subcommand

easily store --extra-config settings rather than repeatedly provide them on every "start".

--extra-config=controller-manager.ClusterSigningCertFile="/var/lib/localkube/certs/ca.crt" --extra-config=controller-manager.ClusterSigningKeyFile="/var/lib/localkube/certs/ca.key"

Software developed in-house, Open Source software

Stateless services, NoSQL databases

They need to work with our security requirements and infrastructure.

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

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 occassionally use Minikube

VirtualBox, VMware Fusion

Software developed in-house, Open Source software

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 have deployed Charts created by others

I use the community charts as a foundation or template for my own charts that I store elsewhere

Software developed in-house

Stateless services, Machine Learning training or serving

Helm, Metaparticle, Skipper

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