Update FAQ.md

Looks like there's also this scenario that can prevent CAS from scaling down. It's been especially observed with Calico-typha.

1.	Calico-typha will use a hostPort configuration to listen a port on host by design. This means only max 1 pod of calico-typha can exist on the same node.
2.	Calico-typha is a deployment, which has a “auto-scale” configuration from the tigera operator to set its replica count according to node count.
3.	When scaling down, cluster-autoscaler will try to find another node that can schedule the pod, however it will be blocked due to (1), as every other node also have typha scheduled.

cluster-autoscaler/FAQ.md

@@ -89,6 +89,7 @@ Cluster Autoscaler decreases the size of the cluster when some nodes are consist
   * are not run on the node by default, *
   * don't have a [pod disruption budget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#how-disruption-budgets-work) set or their PDB is too restrictive (since CA 0.6).
 * Pods that are not backed by a controller object (so not created by deployment, replica set, job, stateful set etc). *
+* Pods with a hostPort configuration - causing the scheduler to fit only one of those pods per node. Scale-down might not work as the existing nodes will already have a pod on them and can't schedule the new one.
 * Pods with local storage **. *
     - unless the pod has the following annotation set:
       ```