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