1.创建deployment
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deploy namespace: default spec: replicas: 3 selector: matchLabels: app: myapp release: stabel template: metadata: labels: app: myapp release: stabel env: test spec: containers: - name: myapp image: wangyanglinux/myapp:v2 imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 |
|
1 2 |
当前创建了deployment,deployment调用ReplicaSets(Rs)创建了3个pod. 当前这三个pod只能通过pod自身ip来访问,外部无法访问到这三个pod |
2.为deployment创建service
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
apiVersion: v1 kind: Service metadata: name: myapp namespace: default spec: type: ClusterIP #svc类型 就算不指定默认也是ClusterIP selector: #匹配如下标签的pod来进行访问，匹配不到是访问不了的 这里起作用的就是selector(选择器) app: myapp release: stabel ports: - name: http port: 80 #前端访问端口 targetPort: 80 #后端真实服务使用端口 |
|
1 |
为上面的myapp-deploy创建了service（svc）svc通过selector选择器筛选出和自己标签(myapp)一致的pod加入自身这个service |
|
1 2 |
给我们生成了一个类型为ClusterIP的service，这个service有一个ClusterIP，其实就一个VIP 通过这个ip我们可以访问到pod 访问机制是按pod顺序轮循 |
Headless Service（特殊的clusterIP)）
|
1 2 |
有时不需要或不想要负载均衡，以及单独的 Service IP 。遇到这种情况，可以通过指定 Cluster IP(spec.clusterIP) 的值为 “None” 来创建 Headless Service 。这类 Service 并不会分配 Cluster IP， kubeproxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: v1 kind: Service metadata: name: myapp namespace: default spec: selector: app: myapp clusterIP:"None" ports: - name: http port: 80 targetPort: 80 |
你会发现CLUSTER IP地址是为None 为空的，那么我现在访问这个地址，或者说我访问这个服务会怎样？
svc一旦创建成功后，会被写入到 coredns 中
|
1 2 3 4 5 6 7 |
svc创建成功会有个主机名,主机名会被写入到coredns, 他的写入的格式体是：svc名称 + 当前命名空间 + 当前集群的域名(集群域名我没没改过,默认就是svc.cluser.local. ) 通过我们当前的coredns的地址进行解析出一个域名 dig -t A myapp-headservice.default.svc.cluster.local. @10.244.0.34 dig命令需要安装 yum -y install bind-utils |
1.首先获取下dns的地址信息
|
1 |
kubectl get pod -n kube-system -o wide |
通过dig命令解析一下
|
1 2 3 4 |
#kube-dns dig -t A myapp-headservice.default.svc.cluster.local. @10.244.0.34 #core-dns dig @10.244.0.34 myapp-headservice.default.svc.cluster.local. |
回车你可以看到，myapp-headservice.default.svc.cluster.local. 指向了各个node节点
然后你就可以通过域名访问了
NodePort
|
1 2 |
nodePort 的原理在于在 node 上开了一个端口，将向该端口的流量导入到 kube-proxy，然后由 kube-proxy 进 一步到给对应的 pod。（能够将内部服务暴露给外部的一种方式) |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
apiVersion: v1 kind: Service metadata: name: myapp namespace: default spec: type: NodePort #svc类型 就算不指定默认也是ClusterIP selector: #匹配如下标签的pod来进行访问，匹配不到是访问不了的 这里起作用的就是selector(选择器) app: myapp release: stabel ports: - name: http port: 80 #前端访问端口 targetPort: 80 #后端真实服务使用端口 |
NodePort端口固定
|
1 2 |
# 固定范围在kube-apiserver配置文件下参数 --service-node-port-range=30000-50000 |
固定端口设置实例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
# 通过配置yaml文件固定端口 apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: A ports: - protocol: TCP port: 80 targetPort: 8080 # 固定端口数值，必须是配置文件范围内 nodePort: 30001 # 网络类型 type: NodePort |
现在使用外部ip+随机端口(32604)访问，
且每个节点ip+随机端口(32640)都可以访问，因为所有节点都开启了这个随机端口
LoadBalancer
|
1 2 3 |
loadBalancer 和 nodePort 其实是同一种方式。都是向外部暴露一个端口，以提供访问，区别在于 loadBalancer 比 nodePort 多了一步，就是可以调用 cloud provider 去创建 LB 来向节点导流，通俗说就是前面端口访问加了负载均衡 LoadBalancer(收费服务，负载均衡需要收费，按流量收费的，很贵) |
ExternalName
|
1 2 3 |
这种类型的 Service 通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容( 例如： hub.cctv.com )。ExternalName Service 是 Service 的特例，它没有 selector，也没有定义任何的端口和 Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务 |
|
1 2 3 4 5 6 7 8 |
kind: Service apiVersion: v1 metadata: name: my-service-1 namespace: default spec: type: ExternalName externalName: hub.cctv.com #改成ip地址也可以 |
当查询主机 my-service.defalut.svc.cluster.local ( SVC_NAME.NAMESPACE.svc.cluster.local )时，集群的 DNS 服务将返回一个值 my.database.example.com 的 CNAME 记录。访问这个服务的工作方式和其他的相 同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发
创建完成后，我们解析一下
|
1 2 3 4 5 |
解析域名格式： svnName + 命名空间 + 当前集群的域名(集群域名我没没改过,默认就是svc.cluser.local. ) @当前的coredns的地址ip dig -t A my-service-1.default.svc.cluster.local @corednsIP 其实就是做了个DNS的别名操作. 域名hub.cctv.com就是DNS的别名 |
待补充…
- 本文固定链接: https://www.yoyoask.com/?p=2192
- 转载请注明: shooter 于 SHOOTER 发表
这个作者貌似有点懒，什么都没有留下。