使用的是Kubersphere可视化管理工具，所以比起在命令行下面敲命令要方便不少。

 

通过图形化界面生成的Secret密钥对象Yaml文件如下，核心是type: kubernetes.io/dockerconfigjson以及kind: Secret

kind: Secret
apiVersion: v1
metadata:
  name: aliyun-docker-image-registry
  namespace: default
  annotations:
    kubesphere.io/alias-name: 阿里云私有容器镜像仓库
    kubesphere.io/creator: admin
data:
  .dockerconfigjson: >-
    eyJhdXRocyI6eyJodHRwczovL3JlZ2lzdHJ5LmNuLXNoYW5naGFpLmFsaXl1bmNzLmNvbSI6eyJ1c2VybmFtZSI6InJlZ0B5a2NhcmUuY24iLCJwYXNzd29yZCI6ImFiY2QxMjM0IiwiZW1haWwiOiIiLCJhdXRoIjoiY21WblFIbHJZMkZ5WlM1amJqcGhZbU5rTVRJek5BPT0ifX19
type: kubernetes.io/dockerconfigjson

这样的话，在K8S里面创建POD的时候，就可以选择这个私有镜像仓库中的容器镜像了，不过一般我们不直接创建POD，而是通过Deployment来间接创建POD，Deployment这玩意在K8S里面翻译成中文的话，应该叫部署，在Kubersphere工作台中给改了个名字叫“工作负载”，只要写Yaml文件就可以扩容、缩容、升级应用程序了，算是声明式部署应用程序了，比起以往需要运维人员手动到服务器上去搞，方便太多了。

只需要在Deployment的Yaml文件中声明要安装部署的容器镜像，以及副本数量，就可以自动部署目标应用程序（当然了，目标应用程序都需要预先做成容器镜像），而且K8S会时刻监控这些副本的健康状态，一旦发现宕机（比如所在物理主机崩溃），就会重新在其他机器上再部署一下这个副本，确保应用程序始终是我们期望的那样（什么叫我们期望的那样，我们的期望都写在Yaml文件中了），也就是说K8S帮忙监控，自动替换宕机或故障的应用程序实例。

比如我这里创建了一个Deployment，里面是Nginx，要求是4个Nginx一起组成集群。

 

[root@linux4 ~]# kubectl get pods -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP              NODE     NOMINATED NODE   READINESS GATES
nginx-deployment-66b6c48dd5-gqvss   1/1     Running   0          13d   10.233.115.97   linux4   <none>           <none>
nginx-deployment-66b6c48dd5-h28v8   1/1     Running   0          13d   10.233.115.99   linux4   <none>           <none>
nginx-deployment-66b6c48dd5-sj5jv   1/1     Running   0          13d   10.233.115.98   linux4   <none>           <none>
nginx-deployment-66b6c48dd5-zwh5g   1/1     Running   0          13d   10.233.115.96   linux4   <none>           <none>

 如果要调整副本数量，点击红色方框，

 再次查询这个pod数量，变成5个了，超级方便，但是呢，POD的IP地址是会发生变化的，所以客户端访问POD就存在了问题？

[root@linux4 ~]# kubectl get pods -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP               NODE     NOMINATED NODE   READINESS GATES
nginx-deployment-66b6c48dd5-gqvss   1/1     Running   0          13d   10.233.115.97    linux4   <none>           <none>
nginx-deployment-66b6c48dd5-h28v8   1/1     Running   0          13d   10.233.115.99    linux4   <none>           <none>
nginx-deployment-66b6c48dd5-k5tk2   1/1     Running   0          8s    10.233.115.109   linux4   <none>           <none>
nginx-deployment-66b6c48dd5-sj5jv   1/1     Running   0          13d   10.233.115.98    linux4   <none>           <none>
nginx-deployment-66b6c48dd5-zwh5g   1/1     Running   0          13d   10.233.115.96    linux4   <none>           <none>

 K8S中的服务

将运行在一组 Pod 上的应用程序暴露为网络服务，也就是说上面5个POD都躲在即将创建的Service后面，这个Service是一个抽象的概念，是一个虚拟的东西，并不是一个实实在在运行着的进程，这一点要注意。

记住核心要点：创建1个K8S里面的Service对象的时候，给这个Service分配一个内部集群范围内全局唯一的IP地址，集群内部可以通过该 IP 访问服务。此访问类型适用于大多数服务。此外，集群外部也可以通过 NodePort 和 LoadBalancer 访问服务。比如下面的默认的一个服务，看它的IP地址，这个IP地址在物理机上是可以ping的通的，但是换台非K8S集群中的主机，比如你的工作电脑上，是无法ping过去的。

[root@linux4 ~]# kubectl get services -o wide
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE   SELECTOR
kubernetes   ClusterIP   10.233.0.1   <none>        443/TCP   48d   <none>

 创建K8S中的Service对象

 老样子，图形化方式创建，省的写Yaml（太繁琐了），先给服务取名字，这个名字是随便取的，同时选择服务所在的项目（这个项目的概念是Kubersphere里面的概念，其实对应的是K8S里面的namespace）

这一步是很重要的，一个服务必须和一个Deployment关联起来，这里我们选择之前创建的Deployment，而且Kubersphere的界面上做了标签式优化，分成无状态Deployment、有状态的Deployment以及DaemonSet，很方便区分，当Deployment比较多的时候，就很容易查找。

这个所谓的LabelSelector是K8S里面搞出来的概念，类似于SQL查询一样，通过kv形式的label，找到目标Deployment，我个人觉得并不是什么出彩的设计。

 

  

 鼠标点点点，就可以生成Service资源对象的Yaml文件，比特么手写要强太多了。

apiVersion: v1
kind: Service
metadata:
  namespace: default
  labels:
    app: nginx-service
    author: andycui
    create_date: '2021-09-09'
  name: nginx-service
  annotations:
    kubesphere.io/alias-name: nginx-service-alias
    kubesphere.io/description: 这是用于让外部客户端能够访问到k8s上的nginx，所以创建的一个Service，Service的IP是集群范围内全局唯一且固定的。
spec:
  sessionAffinity: None
  selector:
    app: nginx
  template:
    metadata:
      labels:
        app: nginx-service
        author: andycui
        create_date: '2021-09-09'
  ports:
    - name: http-web-port
      protocol: TCP
      targetPort: 80
      port: 5500
  type: NodePort

创建成功后，再看看，多了一个Service资源对象了，名称：nginx-service，注意看它的Type是NodePort，然后它的CLUSTER-IP，这个IP地址永远不会改变，在注意看它的PORT（S），之前创建Service的时候指定的是5500端口，但是因为这个Service的IP地址是集群范围内的IP地址，并不是外部客户端访问时可以路由的IP地址，所以必须通过所在宿主机的iptables进行映射才可以真正访问到这个5500端口，我们来看看很重要的细节，就是这个30891端口是何方神圣？

[root@linux4 ~]# kubectl get services -o wide
NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE   SELECTOR
kubernetes      ClusterIP   10.233.0.1      <none>        443/TCP          48d   <none>
nginx-service   NodePort    10.233.42.191   <none>        5500:30891/TCP   9s    app=nginx

[root@linux4 ~]# netstat -antlp | grep 30891
tcp        0      0 0.0.0.0:30891           0.0.0.0:*               LISTEN      60489/kube-proxy    

原来是通过宿主机上的kube-proxy进程提供的端口映射，而且可以看到宿主机上的30891端口也确实被打开了，那么理论上来讲，现在访问 http://宿主机IP:30891，就可以访问到这个集群内的nginx-service的5500端口了，然后对5500端口的访问有会被负载均衡到后面对应的5个POD上去，这5个POD里面都有nginx容器实例在运行，容器实例是运行在80端口，各个容器运行在各自的80端口，互不影响。

[root@linux4 ~]# ps -aux | grep kube-proxy
root      60489  0.1  0.4 744608 33168 ?        Ssl  9月07   2:21 /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf --hostname-override=linux4