Edit: spelling

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.

Comments URL: https://news.ycombinator.com/item?id=46886563

Points: 1

# Comments: 0

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.

Comments URL: https://news.ycombinator.com/item?id=46601441

Points: 2

# Comments: 0

Any particular/strong reason for choosing Zig for this?

Comments URL: https://news.ycombinator.com/item?id=20460148

Points: 2

# Comments: 0

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

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.

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

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

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.

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.

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

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.

Comments URL: https://news.ycombinator.com/item?id=15238672

Points: 177

# Comments: 49

Comments URL: https://news.ycombinator.com/item?id=14346549

Points: 2

# Comments: 0

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?