关于k8s:kubernetes集群外服务映射到内部时为何请求service却一直拒绝

有时会遇到局部服务在集群内部，比方中间件和存储，想要通过k8s集群间接连贯两种形式，一种就是间接通过IP地址连贯；另外一种就是把内部地址映射到集群外部作为一个service来拜访，这样长处很显著前期如果资源IP地址有变更间接在线更新。
看到这，我是想马上间接测试下，创立了一个service和endpoints 如下：

---
apiVersion: v1
kind: Service
metadata:
  name: solr-cloud
  namespace: yp-test
spec:
  ports:
    - protocol: TCP
      name: solr-port
      port: 9090
      targetPort: 9090
  type: ClusterIP
  clusterIP: 

---
apiVersion: v1
kind: Endpoints
metadata:
  name: solr-cloud
  namespace: yp-test
subsets:
  - addresses:
    - ip: 192.168.11.229
    ports:
    - port: 9090

kubectl apply -f solr-endpoint.yaml 执行胜利了
而后通过集群外部pod来拜访刚刚创立的service，发现回绝，然而间接申请IP是通的。

再kubectl describe svc,ep solr-cloud -n yp-test查看如下：

Name:              solr-cloud
Namespace:         yp-test
Labels:            <none>
Annotations:       Selector:  <none>
Type:              ClusterIP
IP:                10.96.78.185
Port:              solr-port  9090/TCP
TargetPort:        9090/TCP
Endpoints:         
Session Affinity:  None
Events:            <none>


Name:                 solr-cloud
Namespace:            yp-test
Labels:               <none>
Annotations:          Subsets:
  Addresses:          192.168.11.229
  NotReadyAddresses:  <none>
  Ports:
    Name     Port  Protocol
    ----     ----  --------
    <unset>  9090  TCP

Events:  <none>

能够发现Endpoints为空也就是endpoints 并没有绑定到外部service上。
为何会这样？
后面的配置貌似也没任何问题，通过和官网文档比照，仔细的敌人可能会发现，service配置里spec.ports有个name（之前写service习惯会把port再定义个name）.
先去掉这个name再从新创立试试

没问题，去掉name，申请service通了。

总结：

serivce和endpoints关联是通过metadata.name来关联的，官网文档也是这么说的。集体猜测，那么当有spec.ports.name时，endpoints中端口ports进行关联时匹配不了，为了再次验证我的猜测，在endpoints中也减少一个一样的name，后果真就关联上了。所以，咱们创立时肯定要留神些细节，一种就是去掉spec.ports.name，或者endpoints同样减少上ports.name。