Kubernetes从私有镜像仓库拉取镜像创建POD

使用的是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

 

 

  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值