danielmartins

Judging by the poor hardware quality of some Google Pixel generations, I'm not putting my money anywhere near this thing.

Edit: spelling

I had a Pixel 6a with Graphene OS for a year before the phone started to glitch and eventually die. It ran pretty hot; sometimes it was hard to even hold the phone in my hands without burning myself.

I could not get a replacement as I bought the phone in a foreign country (Google doesn’t sell Pixels here in Brazil).

So as much as I love the idea of running a more private phone, I found the hardware extremely fragile and poorly designed, so I will not buy from them again anytime soon.

Here’s mine!

https://danielfm.me

After years of neglect, I updated the theme, translated all pages to Portuguese and finally posted something new. I hope to continue this and maybe start making it an habit.

Thanks!

Looks awesome, amazing work!

Any particular/strong reason for choosing Zig for this?

Not as generally available as I thought, and for the looks of it, feels just as "hacky" as the preview with respect to the user experience. For some reason, I was expecting more from them.

You can annotate any Service of type LoadBalancer in order to configure various aspects[1] of the associated ELB, including which ACM-managed certificate you want to attach to each listener port.

[1] https://github.com/kubernetes/kubernetes/blob/master/pkg/clo...

This is not true, if you run Debian / CentOS7 / Ubuntu, out of the box the settings are good. The thing you don't want to do is start to modify the network stack by reading random blogs.

I agree these are good defaults, but they are not meant to work well for all kinds of workloads. And yes, if things are working for you they way they are, that's okay; there's no need to change anything.

On the other hand, I personally don't know anyone who runs production servers of any kind on top of unmodified Linux distros.

TLS termination at the Ingress Controller and by default unencrypted from there to the service endpoint?

We are doing TLS termination at the ELB (we're running on AWS).

Interesting discussion here: https://github.com/kubernetes/ingress/issues/257

Great, thanks!

Regarding ways of updating of the NGINX upstreams without requiring a reload, I was just made aware of modules like ngx_dynamic_upstream[1]. I'm sure there are other ways to address this in a less disruptive way than reloading everything, so this is probably something that could be improved in the future.

[1] https://github.com/cubicdaiya/ngx_dynamic_upstream

No. By default, the NGINX ingress controller routes traffic directly to pod IPs (the Service endpoints):

https://github.com/kubernetes/ingress/tree/master/controller...

Why would any sane Op/Inf/SRE choose not to have at least account-level isolation - is it only a matter of cost due to under-utilization?

In our particular case, yes, pretty much. We are a small company with a small development team, so even if I would want to split accounts to different teams, we would end up having one account for 2-3 users, which doesn't make a lot of sense now.

This is a great read. I know the single cluster for all env is something that is sort of popular but it's always made me uncomfortable for the reasons stated in the article but also for handling kube upgrades. I'd like to give upgrades a swing on a staging server ahead of time rather than go straight to prod or building out a cluster to test an upgrade on.

I've been doing patch-level upgrades in-place since the beginning, and never had a problem. For more sensitive upgrades, this is what I do: create a new cluster using based on the current state in order to test the upgrade in a safe environment before applying it to production.

And for even more risky upgrades, I go blue/green-like by creating a new cluster with the same stuff running in it, and gradually shifting traffic to the new cluster.

Could you share which version of NGINX you found the issue with the reloads? Which version the fix was released?

I'm using 0.9.0-beta.13. I first reported this issue in a NGINX ingress PR[1], so the last couple of releases are not suffering from the bug I reported in the blog post.

I find it interesting/brave that you use a single cluster for several environments.

I'm not working for a big corporation, so dev/staging/prod "environments" are just three deployment pipelines to the same infrastructure.

As of now, things are running smoothly as they are, but I might as well use different clusters for each environment in the future.

[1] https://github.com/kubernetes/ingress/pull/1088

OP didn't mention what Linux distro he's using and what are all of the OS-level configs he changed in the end of the day.

I'm using Container Linux, and yes, I did a few modifications, but I intentionally left them out of the blog post as someone would be tempted to use them as-is.

I'll share more details in that regard if more people seem interested.

Nice article.

You said you are using this toy cluster to play around with monitoring as well, so could you share more details in that area, for instance:

- How much resources does Kubernetes components take from your rpi boards?

- Did you have to do any tweaking in order to make everything run smoothly?

No, these 'development' environments point to other services in 'staging'.

We currently only run stateless apps on Kubernetes. All databases are hosted elsewhere (RDS, MongoDB Cloud, etc)

It' not open source, but I'll try to sell the idea to our CTO. :)

Just to give you more details about its inner workings, this function is written in JavaScript that gets called when certain events come from GitHub ('pull_request', 'status', and 'push'), and uses kubectl to modify the corresponding deployments depending on the event.

Nothing fancy there, trust me.

There's no problem in sticking with your current solution if it's working for you.

I didn't try it because, as mentioned in the footnotes, ECS isn't available for the some of the regions we use, but if you look around, you can find comparisons between the two[1].

I'll probably give ECS a go when (if?) Amazon enables it globally.

[1] https://railsadventures.wordpress.com/2015/12/06/why-we-chos...

Thanks, man! :)

That's true if you reference each service via its external ELB CNAME (or a Route53 DNS that points to it); however, Kubernetes comes with a built-in DNS server that you can use to discover the endpoint IP addresses in the pod CIDR (all pods are in the same subnet via the overlay network).

By default, all ELBs created by Kubernetes are external, and they load balance traffic to every node in the cluster to the service port (each service gets its own port number which is the same in every node).

I believe the reason why people tend to restrict the cluster access to just a handful of people is because - at least for now - these tools lack proper ways to control access to specific resources by specific groups of people. I mean, there are ways to do that in Kubernetes today[1], but the setup is kept as an exercise to cluster operators.

I don't know for sure, but this is less of a problem in some distributions, such as OpenShift[2].

Once this problem is solved, there's no reason to "shield" the cluster from devs.

[1] http://kubernetes.io/docs/admin/authorization/

[2] https://docs.openshift.com/enterprise/3.0/admin_guide/config...