1. 访问Rest API
直接访问Rest API一般有两种方式，一种是通过代理的模式，一种直接的http客户端访问，比较推荐第一种访问的方式。
1.1 代理模式
首先通过如下方式把代理运行起来：
screen kubectl proxy # 通过CTL+a+d组合键放在后台运行
然后就可以访问API了，比如：
1.2 非代理模式
这种访问模式是基于ServiceAccount资源并且需要提供认证token。
首先，获取token：
k8s_token=$(kubectl get secret $(kubectl get secrets | grep -i default | awk '{print $1}') -o yaml | grep token: | awk '{print $2}' | base64 -d)
其次，获取访问API的BaseURL：
最后，通过如下方式访问API：
不过这种方式可能有时需要角色绑定，类似下面这样：
kubectl create clusterrolebinding my_role --clusterrole=cluster-admin --serviceaccount=default:default
2. K8s集群Pod和Service访问策略
这里的访问一般可分为集群内部访问(比如Node访问Pod、Pod间互访等)和集群外部访问，下面就从这两种访问途径聊聊它们各自的实现方式。
2.1 集群内部访问
简单总结一下，大致会有下面几种实现的方式：
- hostNetwork
通过设置Pod的YAML的文件spec区域字段hostNetwork: true实现，其实质是实现了Pod和其所在的Node共享网络栈，如此就可以通过Node的任一IP加Pod服务的端口来实现对Pod服务的访问。
不过这种实现方式会存在两个缺点：Pod服务暴露的端口可能会与Node某个服务端口冲突；由于Pod的生命周期很短比如重启或者出现故障等原因，Pod经常会被调度到不同的Node，因此可能需要维护一个Pod和Node映射关系。
- hostPort
这是一种直接定义Pod网络的方式，直接将容器的端口与所调度的节点上的端口路由，这样用户就可以通过宿主机的IP加上来访问Pod了，如下是这种访问方式的一个实现样例：
...
spec:
containers:
- name: nginx_test
image: nginx:1.9.1
ports:
- containerPort: 80
hostPort: 8900
...
如此就能够通过$HOSTIP:8900来访问该Pod的服务了，不过这种实现方式仍存在hostNetwork访问实现的第二个缺点。
- Kubectl port-forward
在本地设置端口监听，实现对Pod端口转发，由于这种类型的转发端口是绑定在本地的，这种方式也仅适用于调试服务。
- ClusterIP类型的Service
这个是K8s默认使用Service的方式，通过一个固定的VIP和端口去访问Pod服务，同时提供负载均衡能力，不过仅限K8s内部集群访问，比如Pod间的访问，如下是实现一个http service的YAML定义的样例：
...
spec:
clusterIP: 10.110.14.69
externalTrafficPolicy: Cluster
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
run: httpd-app
sessionAffinity: None
...
通过kubectl create命令创建Service之后，我们可以通过如下命令看一下该Service的Endpoint资源信息：
从上图不难看出，该Service对应了后端的三个Pod，我们实际使用中通过10.110.14.69:80实现对后端HTTP服务的访问。
2.2 集群外部访问
- NodePort
基于ClusterIP的功能，为Service在K8s集群中的每个Node绑定一个端口(即NodePort)，这样就可以通过每个Node的IP加上这个端口去实现访问，kube-proxy会自动将流量以round-robin的方式转发给该service的每一个pod。
配置方法基本与ClusterIP类型的Service相同，只不过需要在spec区域加上字段type: NodePort，当然也可以指定具体的nodePort值(默认范围30000-32767)或者任其随机分配。
这种服务暴露方式，无法让你指定自己想要的应用常用端口，不过可以在集群上再部署一个反向代理作为流量入口。
- LoadBalancer
只能在Service内定义(作为一种Service type)，基于NodePort和公有云提供的负载均衡器，通过负载均衡器把外部请求转发到NodePort进而实现对Pod服务的访问。
kind: Service
apiVersion: v1
metadata:
name: my-nginx
spec:
type: LoadBalancer
ports:
- port: 80
selector:
run: my-nginx
name: my-nginx
创建好Service之后查看一下服务信息：
root@vinefu-dev:~#kubectl get svc my-nginx
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-nginx 10.97.121.42 10.13.242.236 80:30051/TCP 39s
如此对内可以通过10.97.121.42:80去访问；对外一方面可以通过Node IP加上端口30051访问，另一方面还可以通过EXTERNAL-IP 10.13.242.236:80去访问。
- Ingress
Ingress是授权入站连接到达集群服务的规则集合，提供了外部访问内部的入口，Ingress 支持将 Service 暴露到 Kubernetes 集群外，同时可以自定义 Service 的访问策略。Ingress 能够把 Service 配置成外网能够访问的 URL，也支持提供按域名访问的虚拟主机功能。例如，通过负载均衡器实现不同的二级域名到不同 Service 的访问。
另外要实现Ingress，需提前安装好对应的Ingress Controller。Ingress用作将原来需要手动配置的规则抽象成一个 Ingress 对象，使用 YAML 格式的文件来创建和管理。Ingress Controller用作通过与 Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，下面举一个典型的Ingress YAML定义样例：
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: test
spec:
rules:
- host: foo.bar.com
http:
paths:
- backend:
serviceName: s1
servicePort: 80
path: /bar
- host: bar.foo.com
http:
paths:
- backend:
serviceName: s2
servicePort: 80
path: /foo
通过kubectl create -f命令创建完Ingress对象后，只要服务（s1，s2）存在，Ingress controller就会将提供一个满足该Ingress的特定loadbalancer实现。
