1.创建Service

（1）通过命令创建svc ：kubectl expose deployment <deployment_name>
（2）通过配置文件创建svc：

  1. # 
  2. apiVersion: v1
  3. kind: Service
  4. metadata:
  5.   name: <deployment_name>
  6. spec:
  7.   ports:
  8.     - port: 81
  9.       targetPort: 80
  10.   selector:
  11.     app: <deployment_name>

2.EndPoint

EndPoint是Kubernetes集群中的一个资源对象，存储在etcd中，用来记录一个service对应的所有pod的访问地址。

3.从集群外部访问Pod或Service

1.将容器应用的端口号映射到物理机
（1）通过设置容器级别的hostPost，将容器应用的端口号映射到物理机上：

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: webapp
  5.   labels:
  6.     app: webapp
  7. spec:
  8.   containers:
  9.     - name: webapp
  10.       image: tomcat
  11.       ports:
  12.         - containerPort: 8080
  13.           hostPort: 8081

（2）通过设置Pod级别的hostNetwork=true，该Pod中所有容器的端口号都将被直接映射到物理机上。在设置hostNetwork=true时需要注意，在容器的ports定义部分如果不指定hostPort，则默认hostPort等于containerPort，如果指定了hostPort，则hostPort必须等于containerPort：

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: webapp
  5.   labels:
  6.     app: webapp
  7. spec:
  8.   hostNetwork: true
  9.   containers:
  10.     - name: webapp
  11.       image: tomcat
  12.       ports:
  13.         - containerPort: 8080
  1.  配置好后可通过 `curl 192.168.113.129:8081` 命令访问。<br />**2.将Service的端口号映射到物理机**<br />（1）通过设置**nodePort**映射到物理机，同时设置Service的类型为NodePort：
  1. apiVersion: v1
  2. kind: Service
  3. metadata:
  4.   name: app
  5. spec:
  6.   type: NodePort
  7.   ports:
  8.     - port: 8080
  9.       targetPort: 8080
  10.       nodePort: 30010
  11.   selector:
  12.     app: webapp

（2）通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置Service场景。在下面的例子中，status.loadBalancer.ingress.ip设置的146.148.47.155为云服务商提供的负载均衡的IP地址。对该Service的访问请求将会通过LoadBalancer转发到后端Pod上，负载分发的实现方式则依赖于云服务商提供的LoadBalancer的实现机制：

  1. apiVersion: v1
  2. kind: Service
  3. metadata:
  4.   name: my-service
  5. spec:
  6.   ports:
  7.     - port: 80
  8.       targetPort: 9376
  9.       nodePort: 30010
  10.       protocol: TCP
  11.   clusterIP: 10.0.171.239
  12.   loadBalancer: 78.11.24.19
  13.   type: loadBalancer
  14.   selector:
  15.     app: webapp
  16. status:
  17.   loadBalancer:
  18.     ingress:
  19.       - ip: 146.148.47.155

4.DNS服务

作为服务发现机制的基本功能，在集群内需要能够通过服务名对服务进行访问，这就需要一个集群范围内的DNS服务来完成从服务名到ClusterIP的解析。
DNS服务在Kubernetes的发展过程中经历了3个阶段。
在Kubernete1.2版本时，DNS服务是由SkyDNS提供的，它由四个容器组成：kube2sky、skydns、etcd和healthz。kube2sky容器监控Kubernetes中Service资源的变化，根据Service的名称和IP地址信息生成DNS记录，并将其保存到etcd中；skydns容器从etcd中读取DNS记录，并为客户端容器应用提供DNS查询服务；healthz容器提供对skydns服务的健康检查功能。
在Kubernetes1.4版本开始，SkyDNS组件便被KubeDNS替换，主要考虑是SkyDNS组件之间通信较多，整体性能不高。KubeDNS由3个容器组成：kubedns、dnsmasq和sidecar，去掉了SkyDNS中etcd存储，将DNS直接保存在内存中，以提高查询性能。kubedns容器监控Kubernetes中Service资源的变化，根据Serivce的名称和IP地址生成DNS记录，并将DNS记录保存在内存中；dnsmasq容器从kubedns中获取DNS记录，提供DNS缓存，为客户端容器应用提供DNS查询服务；sidecar提供对kubedns和dnsmasq服务的健康检查功能。
从Kubernetes1.11版本开始，Kubernetes集群的DNS服务由CoreDNS提供。CoreDNS是CNCF基金会的一个项目，是用Go语言实现的高性能、插件式、易扩展的DNS服务端。
CoreDNS支持自定义DNS记录及配置upstream DNS Server，可以统一管理Kubernetes基于服务的内部DNS和数据中心的物理DNS。
CoreDNS没有使用多个容器的架构，只用一个容器便实现了KubeDNS内3个容器的全部功能。
详细创建过程及使用，查看《Kubernetes权威指南》470页。