Regarding the alb-ingress-controller blackholing traffic with an IP target type ingress, check out support for pod readiness gates: https://kubernetes-sigs.github.io/aws-alb-ingress-controller.... Assuming you're using a rolling deployment, old pods won't be stopped until the new ones are added to the ALB target group and are in a healthy state. This has eliminated the small number of ELB 500s we'd see on deploys.
If you ever open-source your rightsizing scripts, I think a lot of people (including myself) would find that useful. While the vertical pod autoscaler attempts to solve this problem, it's incompatible with horizontal pod autoscalers based on CPU and memory, and thus unusable in a lot of cases. Going with a semi-automated solution might be ideal.
Okay, will do. Resolution of internal hostnames by their FQDN works fine if I set my VPN client (Tunnelblick) to rewrite /etc/resolv.conf. That said, the search domain is not carried into the VM, so name resolution by hostname does not work. Also, Tunnelblick has a name resolution mode that does split DNS (i.e. preserves DHCP-set DNS servers and only forwards DNS requests for the internal domain to the VPN DNS servers). This mode doesn't work at all. Would it be possible to allow forwarding of DNS requests to the host machine like with Virtualbox (VBoxManage modifyvm "VM name" --natdnshostresolver1 on)? I feel like that would simplify things greatly.
This is another issue that's been preventing my adoption of Docker for Mac: https://forums.docker.com/t/docker-pull-not-using-correct-dn.... The fact that DNS resolution over a VPN still doesn't work correctly makes me wonder how production-worthy this release is. It's a pretty common thing people want to do in my experience.
One feature I was hoping to see in this release was the ScheduledJobs controller. I remember seeing it mentioned in one of the RCs; did it get pushed back? This would be useful for those of us who want a more highly available cron-like system running on top of Kubernetes.