I really really like Steampipe to do this kind of query: https://steampipe.io, which is essentially PostgreSQL (literally) to query many different kind of APIs, which means you have access to all PostgreSQL's SQL language can offer to request data.
* it's super easy to request multiple Kubernetes clusters transparently: define one Steampipe "connection" for each of your clusters + define an "aggregator" connection that aggregates all of them, then query the "aggregator" connection. You will get a "context" column that indicates which Kubernetes cluster the row came from.
* it's relatively fast in my experience, even for large result sets. It's also possible to configure a caching mechanism inside Steampipe to speed up your queries
* it also understands custom resource definitions, although you need to help Steampipe a bit (explained here: https://hub.steampipe.io/plugins/turbot/kubernetes/tables/ku...)
Last but not least: you can of course join multiple "plugins" together. I used it a couple of times to join content exposed only in GCP with content from Kubernetes, that was quite useful.
The things I don't like so much but can be lived with:
* Several columns are just exposed a plain JSON fields ; you need to get familiar with PostgreSQL JSON operators to get something useful. There's a page in Steampipe's doc to explain how to use them better.
* Be familiar also with PostgreSQL's common table expressions: there are not so difficult to use but makes the SQL code much easier to read
* It's SQL, so you have to know which columns you want to pick before selecting the table they come from ; not ideal from autocompletion
* the Steampipe "psql" client is good, but sometimes a bit counter intuitive ; I don't have specific examples but I have the feeling it behaves slightly differently than other CLI client I used.
All in all: I think Steampipe is a cool tool to know about, for Kubernetes but also other API systems.
I like Makefiles too :) I use them more or less as a command runner, not often to build new targets based on sources (sometimes still).
In particular, I like:
* The ubiquity: it's easily available almost everywhere I touch and if not, it's usually a package install away.
* The auto completion: I often define variables with default values at the top, but they can be both easily discoverable and their values can be changed just by typing `make VAR<tab>=foobar ...`
* Chaining commands: make targets can be chained with `make target1 target2 target3 ...`. They will execute in the order specified. If I run this too often, I can usually create a 'ew make target that chains them all.
Make is definitely not perfect and could be simpler. My biggest griefs are:
* The abscons list of built-in variable. I can only remember a few of them ("dollar duck `$<` being my favorite), but they are not great to search in the docs and my brain is limited.
* The "one line = one shell" is a bit of a PITA for the use case I have. I usually move more complicated script put of Makefiles.
I thought I would have been bitten by the M4 indentation more often, but it's not really a problem for me anymore at this point (my editor _knows_ Makefiles since it's so ubiquitous and does the right thing)
I have Just on my list of things to check, one day...
Is there any announcement for this new Hyper disk feature? That's something I was interested for a long time and I would have missed it if not for this HN post :D
As a follow-up of the availability topic: what's the best to simulate a zone outage on GCP?
Typicality, for this kind of disks (or previously "regional persistent disks"), you want to test that whatever automation you have for failing over to the secondary zone works correctly.
It would be great also to be able to test other kind of failures at the zone level.
What is the pattern to use on Lambda if you actually have to call out other services, which may, sometimes, take a long time to answer?
Do you make requests with a shorter timeout and have your Lambda fail when it triggers?
Do you delegate long calls to a non-Lambda service?
Interesting discussion about `jj split` and how it opens up a GUI tool to select what changes you want to pick.
I'm using `git gui` a lot, I think about everydays, to pick up exact what I want to commit or amend my current work. It's not a very fancy tool, but it ships with git by default and I feel it's really underused and could actually make people's life easier for editing undergoing work...
I wrote a few applications using both the official Kubernetes client and the asyncio variant from Tomasz. Both have the same problems to me (that you exposed on the comparison page):
The documentation is really terrible (it's even non-existent for kubernetes-asyncio). For the official client, it's hidden deep inside the repository, across hundreds of files (592 at the moment); half the link cross doc don't work, there are rendering issues, etc. It's really a gigantic mess.
The API is extremely verbose, directly the underlying Kubernetes API exposed to Python. It gets the job done and it's better than shell script, but the verbosity + the total lack of a decent documentation (cf. above) makes it hard to use and see what you can do with it. Most of the time, you have to fire the REPL and try a bunch of calls until it makes sense. I like that most of the responses are proper objects, but they display as dict in the REPL and of course, the responses format are not documented in the doc :)
Last but not least: they both lack support for fancy authentication mechanism. We go to Kubernetes through a fancy proxy that require specific TLS settings + an external exec plugin to get the credentials.
The official Kubernetes client should have the right support (for what we need at least) in the next major version but the asyncio variant not yet (I made a PR to fix this, but this requires a new version of aiohttp which is not released yet...) Both clients are very similar for the autogenerated code, but also subtly different for all the things around so you can't really expect 100% that what works on one will work on the other.
I'm not sure how kr8s works with this fancy auth system, but at least for the first 2 points, it seems like a huge win, I'll give it a try!
I'm surprised to see DigiCert name coming that often.
I know they are a major certificate player and that it really helped they supported (signed) Let's Encrypt intermediate certificate for instance (also others, as the article mention), but I don't really understand what do they gain from this? In th end, customers now have more choice, and possibly many free alternatives to DigiCert itself. I guess this kind of people may not all have created certificates through DigiCert in the first place, but I still feel I'm missing something here.
That can be useful because the doc website turns into some kind of sandbox where you can tweak directly the test function and see the result without having to write the code yourself.
The documentation tools are not as advanced as Go's and as far as I know, there's no way to "run the examples" yourself.
It's a great way to write tests for some functions though, to me the sweet spot is for small, without side effects functions. It's totally possible for bigger functions but then all the initialization code and assertions can easily get in the way and make the documentation not super clear.
To be honest, the first Andor episode is really slow and I also almost dropped it right there, but the rest of the show is actually quite good (so far).
For those who are implementing these security guidelines: how do you ensure they have been correctly implemented?
Do you have any kind of static check program that can check beforehand that you are going to deploy a hardened kubernetes cluster? Do you have a "live" checker that can verify the actual configuration of a running cluster? Does it run all the time oronce in a while?
Also , if you have an automated way of verifying your configuration, which program do you use?
I only know about Chef's Inspec and the CIS profiles that are available online, but the experience wasn't extraordinary and I was wondering what is used in the wild?
I heard a lot about design systems the past few months, would one of you have a recommendation for a good read that would explain the challenges and/or the process to create such a system?
I also discovered K6 a few days ago, it looked quite nice and could be a good replacement for our Gatling tests.
We were initially looking for something slightly different though: we were interested to have perhaps less tests, but tests that would run much much more often (like every seconds or couple of seconds), in a continuous manner. Tue goal was to have something at the same time like a healtcheck (is it still working), like a performance test (does it answer in a timely manner) and like a validation test (does it answer the right result - the endpoints we wanted to test do "complex calculations").
Our best answer so far was to wrap K6 in an infinite loop, but I wonder if there could be something smarter.
I think this was the promise of Docker's InfraKit [1] (now DeployKit), to have your infrastructure constantly monitored and adjusted depending on the configuration you pushed into it.
Sadly it didn't go anywhere and it's now archived.
They have a Kubernetes plugin at https://hub.steampipe.io/plugins/turbot/kubernetes and there are a couple of things I really like:
* it's super easy to request multiple Kubernetes clusters transparently: define one Steampipe "connection" for each of your clusters + define an "aggregator" connection that aggregates all of them, then query the "aggregator" connection. You will get a "context" column that indicates which Kubernetes cluster the row came from. * it's relatively fast in my experience, even for large result sets. It's also possible to configure a caching mechanism inside Steampipe to speed up your queries * it also understands custom resource definitions, although you need to help Steampipe a bit (explained here: https://hub.steampipe.io/plugins/turbot/kubernetes/tables/ku...)
Last but not least: you can of course join multiple "plugins" together. I used it a couple of times to join content exposed only in GCP with content from Kubernetes, that was quite useful.
The things I don't like so much but can be lived with:
* Several columns are just exposed a plain JSON fields ; you need to get familiar with PostgreSQL JSON operators to get something useful. There's a page in Steampipe's doc to explain how to use them better. * Be familiar also with PostgreSQL's common table expressions: there are not so difficult to use but makes the SQL code much easier to read * It's SQL, so you have to know which columns you want to pick before selecting the table they come from ; not ideal from autocompletion * the Steampipe "psql" client is good, but sometimes a bit counter intuitive ; I don't have specific examples but I have the feeling it behaves slightly differently than other CLI client I used.
All in all: I think Steampipe is a cool tool to know about, for Kubernetes but also other API systems.