1，为什么不使用round-robin DNS？
因为DNS有缓存，不会清理，无法负载均衡
ipvs代理模式，这种模式，kube-proxy会监视Kubernetes Service 对象和Endpoints，调用netlink接口以相应地创建ipvs规则并定期与Kubernetes Service 对象和Endpoints对象同步ipvs规则，以确保ipvs状态与期望一致。访问服务时，流量将被重定向到其中一个后端Pod
与iptables类似。ipvs于netfilter的hook功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着ipvs可以更快的重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs为负载均衡算法提供了更多选项，例如：
rr：轮询调度。
lc：最小连接数。
dh：目标哈希。
sh：嘻哈源。
sed：最短期望延迟。
nq：不排队调度。
ClusterIP
clusterIP主要在每个node节点使用iptables，将发向clusterIP对应端口的数据。转发到kube-proxy中。然后kube-proxy自己内部实现有负载均衡的方法。并可以查询到这个service下对应pod的地址和端口，进而把数据转发给对应的pod的地址和端口。
为了实现上图的功能，主要需要以下几个组件的协同工作。
apiserver用户通过kubectl命令向apiserver发送创建service命令，apiserver接受到请求后将数据存储到etcd中。
kube-proxy kubernetes的每个节点中都有一个叫做kube-porxy的进程。这个进程负责感知service，pod的变化。并将变化的信息写入本地的iptables规则中。
iptables使用NAT等技术将virtualIP。的流量转至endpoint中。
Headless Service
有时不需要或不想要负载均衡。，以及单独的Service IP。遇到这种情况。可以通过指定Cluster IP（spec.clusterIP）的值为"None"来创建Headless Service。这类Service并不会分配Cluster IP,kube-proxy不会处理他们，而且平台也不会为他们进行负载均衡和路由。
通过这种去绑定。
kubectl get pod -n kube-system
kubectl get pod -n kube-system -o wide
kubectl get pod
kubectl get pod -o wide
NodePort
nodePort的原理在于在node上开了一个端口。将向该端口的流量导入到kube-proxy，然后有kube-proxy进一步到给对应的pod。
master\]vim myapp-service.yaml apiVersion: v1 kind: Service metadate: name: myapp namespace: default spec: type: NodePort selector: app: myapp release: stable ports: name: http port: 80 targetPort: 80 查询流程 iptables -t nat -nvl KUBE-NODEPORTS ## LoadBalancer loadBalancer和nodePort其实是一种方式。区别在于loadBalancer比nodePort多了一步，就是可以调用cloud provider去创建LB来向节点导流。  LAAS流量服务，特别贵，云服务器搭建的k8s ## ExternalName 这种类型的Service通过返回CNAME和他的值，可以将服务映射到externalName字段的内容（例如：hub.atguigu.com）ExternalName Service是Service的特例。他没有selector，也没有定义任何的端口和Endpoint。相反的。对于运行在集群外部的服务。它通过返回该外部服务的别名。这种方式来提供服务。 kind:Service apiVersion: v1 metadata: name : my-service-1 namespace: default spec: type: ExternalName externalName: my.database.example.com 当查询主机my-service.defalut.cluster.local(SVC_NAME.NAMESPACE。svc.cluster.local) 时，集群的DNS服务将返回一个值my.database.example.com的CNAME记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在DNS层，而且不会进行代理或转发。 ## 资料信息   ## ingress  ## Ingress HTTP代理访问    vim ingress.http.yaml kubectl apply -f ingress.http.yaml kubectl get svc curl 10.102.54.180 kubectl apply -f ingress1.ymal  进入容器的命令 kubectl exec 容器名称 -n 名称 -it -- /bin/bash 根据不同的域名实现不同的虚拟主机 ### 创建证书，以及cert存储方式 openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN-nginxsvc/0=nginxsvc" kubectl create secret tls tls-secret --key tls,key --cert tls.crt ### deployment.service.IngressYaml文件 APIVersion：extensions/v1betal kind: Ingress metadata: name: nginx-test spec: tls: - hosts - foo.bar.com secretName: tls-secret rules: - host: foo.bar.com http: paths: / backend: serviceName: nginx-svc servicePort: 80 ## Nginx进行BasicAuth     