K8S系列学习之Service实战

Kubernetes学习路上的那些事儿，很有必要分享出来

 

什么是Service

还是先看看官网上的定义和解释。

 

简单的理解，Service就是k8s中暴露给外部环境访问集群内部服务的接口，优雅的说法就是k8s集群的“交际之花”，接地气的说法就是个“看门老大爷”，不过这位“老大爷”可不是真的老，也算是k8s的后起之秀。

前几帖讲了Pod、RC、RS、Deployment，虽说都创建了Nginx容器，但我们并不能直接通过Pod的IP地址加容器端口实现访问Nginx欢迎页面，这是因为k8s集群考虑到安全性，把内部和外部做了隔离，通过Service实现解耦。

本帖就来实战如何通过外部网络访问k8s集群内Pod中的Nginx容器。

 

实操过程

实验准备：

由于我的移动云账号出现问题，导致我无法正常使用之前利用云主机搭建的k8s集群，又只能在本地搭建环境了。

还是使用VirtualBox创建CentOS 7虚拟机，然后在虚拟机上搭建k8s实验环境。意外的发现，如果只是为了学习，单Master节点也能玩得转，不一定必须要添加Node节点。只需要在Master节点上设置一下即可，具体命令如下：

kubectl taint nodes --all node-role.kubernetes.io/master-

然后就可以愉快的在Master节点上创建k8s资源了，一台虚拟机搞定。（注意：这只是作为学习或者开发环境使用，实际生产环境肯定要集群部署）

 

步骤一：编写Service资源的yaml文件。名字就叫svc-test.yaml，具体代码如下：

svc-test.yaml
apiVersion: v1
kind: Service
metadata:
  name: webapp
spec:
  ports:
  - port: 81
    targetPort: 80
  selector:
    app: nginx
  type: NodePort

由于Service本身不是创建Pod资源的，还需要再编写一个Deployment资源的yaml文件，通过Deployment创建Pod，Pod中创建nginx容器。为了方便，就直接使用上一贴中的Deployment的yaml文件，即deployment-test.yaml，具体代码如下：

deployment-test.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

详细的代码解释如下：

 

步骤二：创建并启动Service及Deployment。Deployment创建后，会产生两个Pod副本，每个Pod中会创建一个nginx容器，容器端口是80，也是nginx默认的端口。Service创建后，会根据selector中的标签对（app: nginx），选择对应的Pod，也就是通过Deployment创建的Pod。

kubectl apply -f deployment-test.yaml
kubectl apply -f svc-test.yaml

 

步骤三：验证结果。因为创建的Service类型是NodePort，所以集群外部访问nginx欢迎页面，需要在浏览器中键入如下地址：

192.168.100.8:32454       //192.168.100.8是本Node的IP地址，32454是Service对外暴露的端口。

 

可以正常访问到nginx的欢迎页面，说明实验成功。

 

实验总结

以上实验演示的是NodePort类型的Service，实际上Service还有其它类型，分别用于不同业务场景，以下借用网络帖子，简单介绍下其它几种类型的Service。

以下内容来自于网络（链接：https://zhuanlan.zhihu.com/p/157565821 ）

1. ClusterIP类型的Service，主要是用于集群内部访问。

 

2. NodePort类型的Service，用于外部访问集群内部资源，如本实验演示。

 

3. LoadBalancer类型的Service。也是用于外部访问集群内部资源的，只是前端再增加一个负载均衡，可以使用公有云厂商的负载均衡，也可以自行搭建。

 

4. ExternalName类型的Service，也是外部访问集群内部资源的，只是通过DNS解析来实现。