191–200 of 433 posts
Earlier quoted context omitted.
Is that yaml not an array of strings? ["x","y","z"]
It's not, y is treated as boolean true.
[1] https://yaml-online-parser.appspot.com/?yaml=foo%3A+%0A-+x%0...
Earlier quoted context omitted.
I hear you about feeling dumb. I think some early decisions in the k8s ecosystem led to a lot of wasted time and effort, and this frustration. YAML: significant whitespace is always unwelcome but YAML also introduces unexpected problems, like how it deals with booleans. For example, say you have this array: foo: - x - y - z You might think this is an array of strings, but you'd be wrong. It's also difficult to read t…
for what its worth, and if im not mostaken, there is some support for JSON, ie. kubectl get deployment xyz -o json
Earlier quoted context omitted.
> all 3 major clouds offer "canned" k8s services that you can set up in a ridiculously short amount of time with Terraform and your CI platform of choice I don't agree. I spun up a Kubernetes cluster in Azure, which was indeed easy. But then I had to figure out how to write the correct deployment scripts to deploy my docker containers to it, and how to configure all the security stuff. After more than a week of tryin…
You're not dumb, you're just new to it, and it's fundamentally hard stuff anyways, and if you can find a higher-level abstraction that lets you get work done faster, then all the better. However, the question is comparing Kubernetes to traditional VM-based infrastructure (especially with pet nodes) whereas you're comparing Kubernetes to a higher-level abstraction. For what it's worth, deploying in Kubernetes is prett…
* shell interactions with quotes * double quotes * interpolating into image namespace with no autocomplete * easy to forget an argument * do you get autocomplete against the deployment name?
Comparison: C# declaration of a complex type - it's less complex than the `kubectl` command above, but IDEs offer way more support to get it right.
* var x = new List>()
This will light up warnings if you get anything wrong;
You get: * go to definition of `CustomType` * autocomplete on classnames * highlighting on type mismatches * warnings about unused vars. * if you initialize the var, the IDE will try hard to not let you do it wrong
So structurally,
1) in the code realm, for doing minor work we have really strong guarantees,
2) in deployment realm, even though it's likely going to hit customers harder, the guarantees are weaker.
I think this is behind the feeling that the k8s system is not ready yet.
It's true that moving away from mutable state is a sea change that is (very) slowly engulfing the industry. But the tide is still very far out. The cloud is a pile of mutable state, leading to the same system instability and maintenance headaches that existed before the cloud, requiring new skills and workers to deal with. Redesigning the cloud to be immutable will take decades of re-engineering by vendors, and even when it's done, we'll still need economies of scale to reduce headcount.
Earlier quoted context omitted.
My second job in large-scale software was at Google, which used the "DevOps model" since before DevOps was named. I have no need to read a blog on it. You want the person who designs the car to know what a car is , and to be able to diagnose basic issues like "the fuel gauge says 'empty' and engine won't start". And there's no analogy to an Indy car driver in software, every distributed system is self-driving. The mo…
throwaway787544 deleted their reply to this post. My response was as follows: --- > So you're familiar with Six Sigma then? Value stream mapping? TPS? > W.E. Deming? Martin Fowler? There's more to DevOps than deployments > and CI/CD. None of those have any relationship to DevOps. > I haven't worked at Google, but I expect somebody gave you some tools > and some access to cloud infra and said "good luck". I was on Bor…
As an outsider, that command looks really easy to mess up.
* shell interactions with quotes
* double quotes
* interpolating into image namespace with no autocomplete
* easy to forget an argument
* do you get autocomplete against the deployment name?
* var x = new List>()
You get:
* go to definition of `CustomType`
* autocomplete on classnames
* highlighting on type mismatches
* warnings about unused vars.
* if you initialize the var, the IDE will try hard to not let you do it wrong
1) in the code realm, for doing minor work we have really strong guarantees,
2) in deployment realm, even though it's likely going to hit customers harder, the guarantees are weaker.
I think this is behind the feeling that the k8s system is not ready yet.
Earlier quoted context omitted.
You can now do something similar with Bunnyshell.com It Handles the devops jobs for dev teams. Full disclosure, I work for Bunnyshell.
In the absence of any description of what “something similar” or “handles the devops jobs” actually means, this comes across as spam, not informative.
Bunnyshell makes it easy to create and manage environments. (EaaS - environments as a service)
You connect your k8s cluster(s) and git accounts/repos, it reads the docker-compose files and creates deployments on the cluster.
You don’t need to know or write Kubernetes manifests, those are created for you.
You also get auto updates and ephemeral/preview environments (when a PR is created against the branch of your env, Bunnyshell deploys a new env with the proposed changes).
You are not restricted to creating resources only on the cluster, you can use Terraform for any resource that is external to the cluster ( like S3 buckets, RDS instances, anything Terraform can handle).
Hope this helps,
Earlier quoted context omitted.
> all 3 major clouds offer "canned" k8s services that you can set up in a ridiculously short amount of time with Terraform and your CI platform of choice I don't agree. I spun up a Kubernetes cluster in Azure, which was indeed easy. But then I had to figure out how to write the correct deployment scripts to deploy my docker containers to it, and how to configure all the security stuff. After more than a week of tryin…
You're not dumb, you're just new to it, and it's fundamentally hard stuff anyways, and if you can find a higher-level abstraction that lets you get work done faster, then all the better. However, the question is comparing Kubernetes to traditional VM-based infrastructure (especially with pet nodes) whereas you're comparing Kubernetes to a higher-level abstraction. For what it's worth, deploying in Kubernetes is prett…
This a stretch, but to me Kubernetes is like the C programming language for infra. If you look at the entire software stack today, drill down (all the turtles), and you will eventually find C (everything goes back to libc or a C/C++ kernel). I assume any commercial (or non-!) "higher-level abstraction" for infra is already (or will be soon) built on top of Kubernetes. I am OK with it.
I write this post as someone who is uber-techincal, but I know nothing about actually using Kubernetes. I can do vanilla "hand-coded/snowflake" infra just fine in my constrained, private cloud environments, but nothing that scales like Kubernetes.
Earlier quoted context omitted.
It's not, y is treated as boolean true.
Is that a k8s thing? Because when I load it in this page[1] it comes out as a string... [1] https://yaml-online-parser.appspot.com/?yaml=foo%3A+%0A-+x%0...
Earlier quoted context omitted.
Drift, as the other child comment mentions, but also loss of version control. I do not want to have to trawl through someone's shell history to figure out what they changed, nor do I want to have to redirect `kubectl get foo -o yaml` output into diff. If everything is in code, and you have a reasonable branching strategy, it's much easier to control change, to rollback bad merges, to run pre-hooks like security check…
You know kubectl has a built in diff subcommand?
Earlier quoted context omitted.
The declarative approach is a more sustainable way to run Kubernetes. If you define some desired state in manifests and apply them to a cluster, they can be applied again to new clusters or the same one and Kubernetes will attempt to maintain the desired state. This state can be version controlled, written in stone, whatever you prefer and it can always be attained. When administrators start issuing imperative comman…
I find this to be a common misconception, stemming from a misunderstanding of what "declarative" means (especially common when people are discussing tools like Terraform). Firstly as you point out, there is a record of the state Kubernetes is being asked to maintain: it's in the API server as the spec of each resource. Secondly, using `kubectl` "patch" in the manner described is not making changes to the cluster stat…
[0] https://kubernetes.io/docs/tasks/manage-kubernetes-objects/i...