7 ms·

the hype around k8s is unreal..... But should everyone even learn k8s? A lot of the core features of k8s and container orchestration is getting abstracted away

the hype around k8s is unreal..... But should everyone even learn k8s? A lot of the core features of k8s and container orchestration is getting abstracted away at a rapid pace with more things being built on top of k8s. I see this at my current company where we have a ton of ops people who have only ever used vmware....with cloud migration and container focused workflows being the standard now they are fearing like they are left behind. So I see a lot of them learning to code, trying to learn k8s, trying to become more devops with automation. Its quite a steep learning curve. But by the time they catch up to this technology I have a feeling it will become less important to administer k8s directly.

pibefision 7y ago
Maybe like Databases. Not all companies need a DBA today.
thewarrior 7y ago
Short answer: Yes you should (If you're in DevOps).
discordianfish 7y ago
> lot of the core features of k8s and container orchestration is getting abstracted away I see this too and it worries me. You should rarely have to do this. CRDs tend to get overused. I'd encourage everyone to think twice before adding a custom controller. Vanilla k8s (with cloud-provider integration) is powerful, useful, and complex as it is.
- deforciant 7y ago
  totally agree :) I have been running Kubernetes in production for several years now on multiple projects. So far I had no need to use any CRDs or even Helm. Just well maintained deployments, services, secrets and ingress manifests.
  - streetcat1 7y ago
    So how do you run stateful workloads? E.g. postgres or mysql?
    - zinclozenge 7y ago
      Generally speaking, you probably shouldn't run databases in k8s unless you need to scale them dynamically, or cloud disk performance is acceptable to you. Having said that, k8s is getting a lot of support for running databases on local disks. A lot of newsql databases (CockroachDB, TiDB, Yugabyte, Vitess, etc) are shipping with strong k8s support/integration.
      - jinqueeny 7y ago
        As a matter of fact, we recently released the 1.0 GA version of TiDB Operator: https://github.com/pingcap/tidb-operator https://github.com/pingcap/tidb-operator
  - RexM 7y ago
    I've started trying to learn more about kubernetes by setting up some personal services and it seems like everything I find online points to some helm chart to install. I think because I don't fully understand k8s, yet, helm seems too magical. It's abstracting away what I already don't understand and doesn't feel right. For now, I've been focusing on writing my manifests and applying them with kubectl to get a feel for what's going on under the hood. Maybe a time will come where it's a tool that I'll need to reach for, though.
- nfg 7y ago
  Let me ask you a question if I may: I have a server app I’m running on k8s, it’s stateful and external users connect to it (over grpc). Users connect to a specific server which is identified by ID, this is important and can’t be easily rearchitected. I also expose an API to spin up servers for new ids which users can then connect to. At present I’m doing this by having my “controller” api (which is just an app running in a pod which exposes a rest api then makes calls to the k8s api) create a new deployment+service per server and then add an ingress for that service. I’ve been considering taking the k8s functionality from my controller and putting it in a new CRD + controller. Is there a better way to do this? I feel like I’m fighting the system somewhat with my current approach and yet I don’t see a simple answer using vanilla k8s primitives. I feel like what I want is scalable statefulsets that automatically create an service+ingress to each pod created but nothing seems to offer that. My use-case seems simple and common, so how is everyone else solving this problem.
  - cuongt 7y ago
    You may want to look into operators. It seems to address your requirements nicely.
hclaria 7y ago
because once you know how k8s works, you gain so much time and have to deal with much less low-value problems.. I couldn't go back to the old way
Townley 7y ago
That push towards growth is real across both sides of the developer-administrator spectrum (I know many experienced developers struggling through React/Vue, ETL pipeline tools, or more devops than they'd prefer). Across the board, it's partially fad and hype, but it's also because these workflows really are better. On the k8s side, a containerized architecture gives developers peace of mind in their local environments, makes you more provider-agnostic, and has the potential to scale more easily. A sysadmin who can provide all of those is valuable, and deciding if that value is worth the learning curve is an individual decision. But to whatever extent the "resume-driven-development" aspect of container orchestration hype is distorting the market, it does seem to be in service of a better (if more complicated) toolset.
- eropple 7y ago
  > a containerized architecture gives developers peace of mind in their local environments ...unless you use cloud-specific services, which almost everybody should be doing because the management load of self-hosted alternatives is very high. Correctly care-and-feeding a message queue or a log store is so much more work than creating an SQS queue or a Kinesis shard, especially when you are not running a company centered around managing a message queue or a log store. Which you probably aren't. Localstack exists as an AWS stub for local development, but it sure isn't great and the impedance mismatch is pretty high--just trying to write Pulumi code that can target either it or AWS proper is an exercise in frustration. Don't get me wrong: containers as a better way to ship "statically linked" applications are great. But none of the container-orchestration stuff seems out of the "hype" stage from anything I've seen as a consultant or as a line developer; I've never-not-once found a reason to reach for k8s on any major cloud provider. I guess it's OpenStack 2.0 for on-premises deployments, and in that light there's definitely some value, but your cloud provider is doing a lot of work that you're already effectively paying for by being in that ecosystem--for most users (who can't hire somebody like me) it's worth using it.
  - streetcat1 7y ago
    I think that you might be able to replace SQS specific queues with knative eventing. This should provide some insulation from aws specific services.
druddha 7y ago
> But should everyone even learn k8s? Of course not. Different orgs will approach this problem differently. At my company, someone on our infra/devops team made pretty good abstractions eight years ago, and now we're using those same abstractions on top of K8s. So our devs really don't need to know anything about the substrate. But when I go to conferences and meetups, I talk to folks who basically expose the entirety of K8s to devs and expect them to self-serve.
mercules 7y ago
Not everyone should learn k8s. It is concerning to see people become desperate to learn to code so as to not be "left behind", this will likely lead to some very disenfranshised individuals in the future
blackoil 7y ago
~everyone should learn it, though not everyone should use it. k8s allows new deployment patterns and app structures. A senior dev. should know enough about it, that when a right opportunity comes they should be able to identify it.
ar_lan 7y ago
VMware announced Project Pacific two days ago at VMworld which targets this usecase you are mentioning - https://blogs.vmware.com/vsphere/2019/08/introducing-project-pacific.html https://blogs.vmware.com/vsphere/2019/08/introducing-project...

pibefision 7y ago

Maybe like Databases. Not all companies need a DBA today.

thewarrior 7y ago

Short answer: Yes you should (If you're in DevOps).

discordianfish 7y ago

> lot of the core features of k8s and container orchestration is getting abstracted away I see this too and it worries me. You should rarely have to do this. CRDs tend to get overused. I'd encourage everyone to think twice before adding a custom controller. Vanilla k8s (with cloud-provider integration) is powerful, useful, and complex as it is.

deforciant 7y ago
totally agree :) I have been running Kubernetes in production for several years now on multiple projects. So far I had no need to use any CRDs or even Helm. Just well maintained deployments, services, secrets and ingress manifests.
- streetcat1 7y ago
  So how do you run stateful workloads? E.g. postgres or mysql?
  - zinclozenge 7y ago
    Generally speaking, you probably shouldn't run databases in k8s unless you need to scale them dynamically, or cloud disk performance is acceptable to you. Having said that, k8s is getting a lot of support for running databases on local disks. A lot of newsql databases (CockroachDB, TiDB, Yugabyte, Vitess, etc) are shipping with strong k8s support/integration.
    - jinqueeny 7y ago
      As a matter of fact, we recently released the 1.0 GA version of TiDB Operator: https://github.com/pingcap/tidb-operator https://github.com/pingcap/tidb-operator
- RexM 7y ago
  I've started trying to learn more about kubernetes by setting up some personal services and it seems like everything I find online points to some helm chart to install. I think because I don't fully understand k8s, yet, helm seems too magical. It's abstracting away what I already don't understand and doesn't feel right. For now, I've been focusing on writing my manifests and applying them with kubectl to get a feel for what's going on under the hood. Maybe a time will come where it's a tool that I'll need to reach for, though.
nfg 7y ago
Let me ask you a question if I may: I have a server app I’m running on k8s, it’s stateful and external users connect to it (over grpc). Users connect to a specific server which is identified by ID, this is important and can’t be easily rearchitected. I also expose an API to spin up servers for new ids which users can then connect to. At present I’m doing this by having my “controller” api (which is just an app running in a pod which exposes a rest api then makes calls to the k8s api) create a new deployment+service per server and then add an ingress for that service. I’ve been considering taking the k8s functionality from my controller and putting it in a new CRD + controller. Is there a better way to do this? I feel like I’m fighting the system somewhat with my current approach and yet I don’t see a simple answer using vanilla k8s primitives. I feel like what I want is scalable statefulsets that automatically create an service+ingress to each pod created but nothing seems to offer that. My use-case seems simple and common, so how is everyone else solving this problem.
- cuongt 7y ago
  You may want to look into operators. It seems to address your requirements nicely.

hclaria 7y ago

because once you know how k8s works, you gain so much time and have to deal with much less low-value problems.. I couldn't go back to the old way

Townley 7y ago

That push towards growth is real across both sides of the developer-administrator spectrum (I know many experienced developers struggling through React/Vue, ETL pipeline tools, or more devops than they'd prefer). Across the board, it's partially fad and hype, but it's also because these workflows really are better. On the k8s side, a containerized architecture gives developers peace of mind in their local environments, makes you more provider-agnostic, and has the potential to scale more easily. A sysadmin who can provide all of those is valuable, and deciding if that value is worth the learning curve is an individual decision. But to whatever extent the "resume-driven-development" aspect of container orchestration hype is distorting the market, it does seem to be in service of a better (if more complicated) toolset.

eropple 7y ago
> a containerized architecture gives developers peace of mind in their local environments ...unless you use cloud-specific services, which almost everybody should be doing because the management load of self-hosted alternatives is very high. Correctly care-and-feeding a message queue or a log store is so much more work than creating an SQS queue or a Kinesis shard, especially when you are not running a company centered around managing a message queue or a log store. Which you probably aren't. Localstack exists as an AWS stub for local development, but it sure isn't great and the impedance mismatch is pretty high--just trying to write Pulumi code that can target either it or AWS proper is an exercise in frustration. Don't get me wrong: containers as a better way to ship "statically linked" applications are great. But none of the container-orchestration stuff seems out of the "hype" stage from anything I've seen as a consultant or as a line developer; I've never-not-once found a reason to reach for k8s on any major cloud provider. I guess it's OpenStack 2.0 for on-premises deployments, and in that light there's definitely some value, but your cloud provider is doing a lot of work that you're already effectively paying for by being in that ecosystem--for most users (who can't hire somebody like me) it's worth using it.
- streetcat1 7y ago
  I think that you might be able to replace SQS specific queues with knative eventing. This should provide some insulation from aws specific services.

druddha 7y ago

> But should everyone even learn k8s? Of course not. Different orgs will approach this problem differently. At my company, someone on our infra/devops team made pretty good abstractions eight years ago, and now we're using those same abstractions on top of K8s. So our devs really don't need to know anything about the substrate. But when I go to conferences and meetups, I talk to folks who basically expose the entirety of K8s to devs and expect them to self-serve.

mercules 7y ago

Not everyone should learn k8s. It is concerning to see people become desperate to learn to code so as to not be "left behind", this will likely lead to some very disenfranshised individuals in the future

blackoil 7y ago

~everyone should learn it, though not everyone should use it. k8s allows new deployment patterns and app structures. A senior dev. should know enough about it, that when a right opportunity comes they should be able to identify it.

ar_lan 7y ago

VMware announced Project Pacific two days ago at VMworld which targets this usecase you are mentioning - https://blogs.vmware.com/vsphere/2019/08/introducing-project-pacific.html https://blogs.vmware.com/vsphere/2019/08/introducing-project...