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
