Kubernetes follows a client-server architecture with a server node (master) composed of etcd cluster, kube-apiserver, kube-controller-manager, cloud-controller-manager, scheduler and  Client (worker) nodes are composed of kube-proxy and kubelet components.
Master:
API Server: The communication hub for all cluster components. It exposes the Kubernetes API
Scheduler: Assigns you app to a worker node. Auto-detects which pod to assign to which node based on resource requirements, hardware constraints, etc
Controller Manager: Maintains the cluster. Handles node failures, replicating components, maintaining the correct number of pods etc
etcd: Data store that stores the cluster configuration
Worker:
Kubelet: Runs and manages the containers on the node and talks to API servers.
Container Runtime: The program that runs your containers (docker, rkt, containerd)
Kube-Proxy: Load balances traffic between application components.
Kube-proxy Modes:
Kube-Proxy can run in three modes: userspace, iptables and IPVS.
The userspace mode is old and inefficient. The packet is compared against iptables rule and then forwarded to a pod named kube-Proxy, which operates as an application to forward packet to backend pods.
The iptables mode is better since it uses the kernel feature of iptables, which is fairly mature. kube-proxy manages iptables rule based on the service yaml of Kubernetes.
IPVS (IP Virtual Server) is a beta feature in Kubernetes 1.9. 1. kube-proxy ipvs mode provides benefits such as performance enhancement to kube-proxy, when compared with traditional methods of using iptables and userspace mode. IPVS running on a host acts as a load balancer at the front of a cluster of real servers.