> Both Westerners and Taiwanese should be more optimistic about the defense of Taiwan than is now normal.
> Yes, the Taiwanese Army projects that it can only hold off its enemy for two weeks after the landing—but the PLA also believes that if it cannot defeat the Taiwanese forces in under two weeks, it will lose the war!
To expand on the sibling comment by nrmitchi, in Kubernetes you don't scale your worker nodes by CPU or memory. Instead you scale your pods by CPU or memory. Running the cluster autoscaler ensures that when you run out of space to schedule a new pod new worker nodes are brought up. It also works the other way; when your nodes are being underutilized for a while, the autoscaler will kill some nodes (and the scheduler will automatically handle placing any pods on those nodes onto other nodes).
Right, I see that in the CA docs. This doesn't work with our business requirements since our workloads are spikey and we don't want to wait around for pods not being able to be scheduled to start more nodes.
A contrived example is imagine if for every gmail user that logs into gmail google spins up a pod for the user. No imagine if there wasn't any capacity to schedule a pod for a user that is logging in. That user would either be denied or have to wait for an instance to come up and then the pod to be scheduled. Not ideal.
Yes, this is my biggest problem with the autoscaler as well. I opened an issue about this almost a year ago, looks like they're finally getting around to addressing it: https://github.com/kubernetes/autoscaler/pull/77
That's only if you use VPC networking. If you use external networking, you can deploy a networking Daemonset (Weave, Flannel, etc.) and there's no 50 node limit.
I tried Weave but ultimately had to abandon it, as there were too many issues in resolving DNS directly to containers. Kubernetes resolves DNS to a virtual IP that in turns maps to the container IPs, which I found to be a much better approach.
My initial work with it was pre-docker networking. Admittedly, I need to spend more time with Kubernetes, but the rapid evolution and multiple solutions to service discoverability, load balancing, and networking in the Docker eco-system is a bit of a challenge to keep on top of and figure out what's best/right for the situation. I suspect, near term, the solution is "what works for me now, I'll figure out something else as I have time/down the road."
On page 17 of the Solar System book I want to rotate the globe but can't manage to do that without also initiating a page flip, which is pretty annoying.
Also, the formula rendering on page 21 is not quite right (Firefox).
Touch it very lightly, like a feather. Or hold it strongly and then roll it along with the page, then take your fingers off. It should work. That it is curling up is the expected behavior so you're just fine there!
Mathjax is loading/rendering a bit incorrectly on FF, for we're hammered right now. Will fix!
I think that non-nullable types by default are one of Dart's biggest missed opportunities, so I'm really hoping that the Dart team ends up adopting this.
This is also a really great example of the DEP system in action. DEPs (Dart Enhancement Proposals) allow anyone to suggest improvements to the Dart platform, and work with the Dart team to determine if it can be accepted and implemented. This means that individual community members can advance the language forward and that's exactly what's happening here. The author of the proposal, Patrice Chalin, is not on the Dart team but that hasn't stopped him from creating an awesome proposal that has earned praise from Dart team members.
https://foreignpolicy.com/2018/09/25/taiwan-can-win-a-war-wi...
> Both Westerners and Taiwanese should be more optimistic about the defense of Taiwan than is now normal.
> Yes, the Taiwanese Army projects that it can only hold off its enemy for two weeks after the landing—but the PLA also believes that if it cannot defeat the Taiwanese forces in under two weeks, it will lose the war!