chore: Typo in node_efficiency.md (#655)

Author: askulkarni2

content/scalability/docs/node_efficiency.md

@@ -28,7 +28,7 @@ Using node sizes that are slightly larger (4-12xlarge) increases the available s
 
 ![Node size](../images/node-size.png)
 
-Large nodes sizes allow us to have a higher percentage of usable space per node. However, this model can be taken to to the extreme by packing the node with so many pods that it causes errors or saturates the node. Monitoring node saturation is key to successfully using larger node sizes. 
+Large nodes sizes allow us to have a higher percentage of usable space per node. However, this model can be taken to the extreme by packing the node with so many pods that it causes errors or saturates the node. Monitoring node saturation is key to successfully using larger node sizes. 
 
 Node selection is rarely a one-size-fits-all proposition. Often it is best to split workloads with dramatically different churn rates into different node groups. Small batch workloads with a high churn rate would be best served by the 4xlarge family of instances, while a large scale application such as Kafka which takes 8 vCPU and has a low churn rate would be better served by the 12xlarge family.   
 
@@ -264,4 +264,4 @@ To sum up the section, it is easy to conflate the following concepts:
 * Utilization and Saturation  
 * Linux performance rules with Kubernetes Scheduler logic
 
-Great care must be taken to keep these concepts separated. Performance and scale are linked on a deep level. Unnecessary scaling creates performance problems, which in turn creates scaling problems. 
+Great care must be taken to keep these concepts separated. Performance and scale are linked on a deep level. Unnecessary scaling creates performance problems, which in turn creates scaling problems.