kubernetes介绍

一、Kubernetes管理文件介绍

Kubernetes最常用的配置文件格式为yaml格式,yaml因为支持注释,可以很好的表示复杂的数据格式,正在越来越多地被其它程序作为配置文件来使用。

Yaml(发音/ˈjæməl/)格式介绍

缩进

Yaml只支持空格作为缩进,不支持tab作为缩进。可以使用两个空格或者四个空格表示一层,但是整个yaml文件必须统一,要么全部使用两个空格作为缩进要么全部使用四个空格作为缩进,不允许混合使用。

注释

Yaml使用#作为一行的注释,当yaml碰到以#开头的行时将作为注释对待。

字典数据结构

字典数据结构使用key:value格式,例如:

apiVersion: v1
kind: ConfigMap
metadata:
  name: dns

解释为: 键值 apiVersion值为 v1, 键值 kind值为 ConfigMap, 键值 metadata值又为一个字典数据结构。

数组数据结构

例如:

favAnimals:
  - cat
  - dog
  - elephant

键值favAnimals的值为一个数组,这个数组值为 cat, dog, elephant。

一个更复杂的yaml结构解释

apiVersion: v1
kind: Service
metadata:
  name: sms
spec:
  selector:
    run: deployment-sms
  ports:
  - protocol: TCP
    name: http
    port: 18000
    targetPort: 8000

键值apiVersion值为 v1,键值kind值为Service,键值metadata值为 name: sms,键值 spec值为

  selector:
    run: deployment-sms
  ports:
  - protocol: TCP
    name: http
    port: 18000
    targetPort: 8000

键值 ports值为一个数组,这个数组有一个值,值为

    protocol: TCP
    name: http
    port: 18000
    targetPort: 8000

多个yaml文件合并为一个

Kubernetes支持多个yaml文件合为一个文件编写,每个yaml块使用 --- 分隔。合并的yaml文件有先后顺序之分,如果有依赖关系的话,被依赖的yaml文件必须放在前面。

二、Kubernetes简介

Kubernetes优势

Kubernetes是一个集中的容器container管理环境,它提供一种更加方便的资源管理办法,方便服务快捷地做到扩展和伸缩以满足业务量的变化需求。

Kubernetes架构

Kubernetes是master+node节点架构,我们业务系统的容器只运行在node上面。

Master节点用于kubernetes任务分配调度,运行的组件有:kube-apiserver, etcd, kube-scheduler, cloud-controller-manager。

Node机器运行的组件有:kubelet, kube-proxy, 以及运行时的容器Container Runtime。

 Kubernetes api

Kubernetes api完整地定义了kubernetes使用的对象参数,v1.12版本api定义地址:

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.12/

Kubectl客户端

Kubectl是最常用到的命令,它用于跟apiServer通讯,把yaml里配置的对象在kubernetes集群里生效。它也用于查看kubernetes对象的状态。

三、业务系统进kubernetes

业务系统一般比较关心,配置文件如何解决,日志如何解决,如何运行镜像,现在就这些比较关心的问题进行讨论。

定义配置文件

Kubernetes的ConfigMap对象用于把配置参数映射到kubernetes集群里的方式,这些业务参数或者environment环境变量都将定义在yaml文件里,以原子最小单位的形式供其它要使用它们的系统重复使用。

Y_DNS解决

Openresty需要使用resolver xxx.xxx.xxx.xxx; 指令来指定DNS服务器用来解析域名。一般我们在run.sh里定义Y_DNS环境变量的方式把DNS传入使用start.lua来生成resolver.conf的方式来定义openresty的resolver。解决办法,把Y_DNS作为ConfigMap定义到kubernetes系统。

dns-config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: dns
data:
  Y_DNS: 172.0.0.1

解释:

第1行,定义apiVersion,apiVersion是kubernetes api必须的元素。

第2行,定义类别kind,这是一个ConfigMap类别,用于定义配置参数。

第3行,定义ConfigMap的一些基本元数据,其中name是metadata里必须定义的,给这个ConfigMap起一个名字为dns,后续在其它yaml里可以使用这个名字来引用我们定义的配置信息。所以定义名字时应该具有唯一性。

第5行,data后面的将是该dns ConfigMap的具体内容。

第6行,我们定义了一个ConfigMap变量YBS_DNS,它的值是 172.0.0.1,这是一个kubernetes集群DNS。

device配置文件解决

device配置文件有两层目录,一层在/sms目录下,一层在/device/status目录下,一层目录下的配置文件放在一个yaml文件里,这样才能够后续映射到不同的目录里。

下面截取了device-config.yaml部分代码

  ---
 apiVersion: v1
 kind: ConfigMap
 metadata:                                                                                                                                                                                    
   name: device-conf
 data:
   addr.ini: |
     [addr]
     sms_url = http://sms.default.svc.cluster.local:18000/sms/print
 ---
 apiVersion: v1
 kind: ConfigMap
 metadata:
   name: device-status-conf
 data:
   device_status.ini: |
     [status]
     1 = ok

解释:

第1行,因为把device两个yaml配置放在了一个文件里,使用---分隔表示一个文件的内容。

第2行,同样的,定义了apiVersion

第3行,定义kind的,为ConfigMap类别

第4,5行,定义metadata,主要定义了name名字,注意该名字的唯一性。

第7行开始为ConfigMap的数据data,注意这儿跟dns-config.yaml里不同,它定义了一个配置文件样式, addr.ini : | 前面addr.ini为配置文件的名字,后续在其它yaml文件里引用映射到一个目录下,那么该文件名就是addr.ini,后面的 | 表示后续的内容为addr.ini文件的数据。

同理,从10行以后是定义的/device/status目录下的配置文件内容。

sms配置文件

 ---
 apiVersion: v1
 kind: ConfigMap
 metadata:
   name: configmap-sms
 data:
   client.ini: |
     [jpush]
     key=aa
     secret=76basdt                                                                                                                                                      
   mysql.ini: |
     [config]
     host=mysql.ws.com
     port=3306

定义模块运行参数

Kubertnetes的一大优势就是能够定义业务系统的运行份数,动态伸缩,下面我们来看下定义sms运行状态的一种新kubernetes类型Deployment。

sms Deployment

sms-deployment.yaml

 ---
 apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: deployment-sms
 spec:
   replicas: 2
   template:
     metadata:
       labels:
         run: deployment-sms
     spec:
       containers:
       - name: deployment-sms
         image: registry:5000/sms:20210101
         env:
           - name: Y_DNS
             valueFrom:
               configMapKeyRef:
                 name: dns
                 key : Y_DNS
         ports:
         - containerPort: 8000
         volumeMounts:
         - name: volume-sms
           mountPath: /home/openresty/openresty/nginx/sms/conf
           readOnly: true

         - name: volume-log
           mountPath: /data/log
       volumes:
      
       - name: volume-sms
         configMap: 
           name: configmap-sms

       - name: volume-log
         hostPath:
           path: /data/log

解释:

第1行,yaml内容分隔符。

第2行,定义apiVersion

第3行,该对象的类别为Deployment,Deployment对象用于定义业务系统的运行状态信息。

第4,5行,定义该对象的一些metadata,其中我们定义了该对象的名字。

第6行,spec定义该Deployment的一些规范。

第7行,replicas定义该业务系统将要运行的份数,我们定义为运行2份。

第8行,template内容定义要运行的业务系统的模板信息。

第11行,定义运行的container名字,这儿的名字在14行定义。

第13行,定义运行的container数组,这儿数组里定义了一个container。

第14行,该container的名字是deployment-sms,第11行填的名字就是这儿定义的名字。

第15行,要启动container的镜像名称。

第16至21行,前面dns-config.yaml里定义的dns ConfigMap变量。

第22,23行,定义container启动的端口。

第24至37行,定义mount挂载的卷。

我们先看30至37行,我们定义了两个volume,32行至34行volume的名字为 volume-sms,它引用的是前面sms ConfigMap的配置参数。35行至37行volume的名字为volume-log,它引用的是一个物理路径 /data/log。

我们再来看24至29行,这儿我们来使用下面定义的volume,第25至27行,我们使用下面定义的volume-sms,也就是使用了一个ConfigMap,我们把这个ConfigMap内容挂载到到container容器的路径/home/openresty/openresty/nginx/sms/conf,这样我们就把ini的配置文件挂到了该目录下,并且设置了只读权限。第28,29行,我们使用了下面定义的volume-log,这是一个物理路径,我们把它挂载到container里的/data/log。

总结:我们在sms Deployment里定义了sms要运行的份数,使用的环境变量,配置文件要挂载的目录,日志文件的目录这些关键的信息。

sms Service

在前面我们定义了sms的运行时,那么现在sms运行起来了,是否就可以供device等系统使用了呢?答案是否定的,kubernetes规定内部的HTTP(S)服务要供kubernetes内部系统使用的话,必须把它expose为一个service服务。下面我们来看下一个service要如何定义。

 ---
 apiVersion: v1
 kind: Service
 metadata:
   name: sms
 spec:
   selector:
     run: deployment-sms
   ports:
   - protocol: TCP
     name: http
     port: 18000
     targetPort: 8000

第3行,我们定义了它的种类为service。

第5行,我们定义了该service的名字。

第7,8行,我们使用了selector选择了一个运行时容器,就是前面定义的deployment-sms运行时容器。

第10至13行,我们定义了该service expose的端口,第10,11行说明它是一个http的服务,第13行容器内监听的端口是8000,第12行我们把该服务暴露为18000端口,这样外部使用该sms服务将使用18000端口。

device调用sms的URL配置

device因为需要调用sms,而sms也部署在kubernetes里,前面说到如果kubernetes内部的服务要被其它系统调用的话,必须把被调用的系统expose为一个service,那么这个service的域名也是有一定讲究的,它的域名组成为 service名字.default.svc.cluster.local,这样device配置文件里定义的sms配置实际为 sms.default.svc.cluster.local:18000。

device Deployment

device同理我们要先定义一个运行时来运行它的容器,也即定义一个deployment,同理在该deployment里我们需要定义device运行时使用的环境变量,运行的镜像名称,要挂载的配置文件路径,日志挂载目录等。我们来看下device deployment的定义:

 apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: deployment-device
 spec:
   replicas: 2
   template:
     metadata:
       labels:
         run: deployment-device
     spec:
       containers:                                                                                                                                                                                                                        
       - name: deployment-device
         image: registry:5000/device:20210101
         env:
           - name: Y_DNS
             valueFrom:
               configMapKeyRef:
                 name: dns
                 key : Y_DNS
           - name: Y_CONFIG_URL
             value: http://127.0.0.1:8000/ini/
         ports:
         - containerPort: 8000
         volumeMounts:
         - name: device-conf
           mountPath: /home/openresty/openresty/nginx/ini/device
           readOnly: true
         - name: device-status-conf
           mountPath: /home/openresty/openresty/nginx/ini/device/status
           readOnly: true
         - name: log
           mountPath: /data/log
       volumes:
       - name: device-conf
         configMap:                                                                                                                                                                           
           name: device-conf
       - name: device-status-conf
         configMap:
           name: device-status-conf
       - name: log
         hostPath:
           path: /data/log

第4行,我们给这个deployment定义了一个名字。

第6行,我们定义了device容器运行的复制份数为2份。

第12至43行,我们定义了要运行的容器内容。

第13行,我们给要运行的容器定义名字为deployment-device。第10行这里run运行的就是该容器的名字。

第14行,定义要运行的镜像版本号。

第15行,定义env环境变量到容器里。后面的16至22行都是环境变量的定义。

第16至20行,我们使用了前面dns-config.yaml里的ConfigMap来映射到环境变量Y_DNS。

第21,22行,我们定义了另一个环境变量Y_CONFIG_URL,它的值为http://127.0.0.1:8000/ini/。

第23,24行定义了容器里服务使用的端口,也即nginx.conf里面监听的端口。

第34至43行,我们先定义使用的volume。

第25至33行,我们把要使用的volume挂载到容器目录里。

至此device系统也已经运行起来了,前面说kubernetes内部的服务要供内部系统使用要定义一个service,那么kubernetes内部的系统要供kubernetes外部服务调用呢?答案是要定义一个NodePort来供外部调用,或者定义一个Ingress来供外部调用。

device NodePort

 ---
 apiVersion: v1
 kind: Service
 metadata:
   name: device
 spec:
   type: NodePort
   selector:
     run: deployment-device
   ports:
   - protocol: TCP
     name: http
     port: 8000                                                                                                                                                                                
     targetPort: 8000
     nodePort: 30072

第3行,其实这儿定义的类别还是Service类别,但是与前面device service的区别。

第5行,为这个Service定义个名字。

第6至15行,定义该service的spec。

第7行,定义它的类型为NodePort,供kubernetes外部系统调用。

第8,9行,选择前面定义的容器运行时名字。

第10,15行定义该NodePort对外提供服务的端口。

第14行,前面运行时容器nginx.conf监听的端口。

第13行,kubernetes内部系统可以访问的映射端口。

第15行,外部服务访问该服务的外部监听端口。

device Ingress

 ---
 apiVersion: v1
 kind: Service
 metadata:
   name: device-service
   namespace: {{ namespace }}
 spec:
   selector:
     run: device
   ports:
   - protocol: TCP
     name: http
     port: 8000
     targetPort: 8000
 
 ---
 apiVersion: extensions/v1beta1
 kind: Ingress
 metadata:
   name: device-ingress
   namespace: {{ namespace }}
 spec:
   rules:
   - host: k8s.{{ namespace }}.com
     http:
       paths:
       - path: /device
         backend:
           serviceName: device-service
           servicePort: 30072

第7至14行,定义该service的spec,不需要再声明类型为NodePort。

第14行,前面运行时容器nginx.conf监听的端口。

第13行,kubernetes内部系统可以访问的映射端口。

第18行,类别是Ingress类别。

第24行,访问地址。

第27行,待转发的uri。

第29行,转发的Service服务名称,对应第5行的名称。

第30行,外部服务访问该服务的外部监听端口。

四、小结

环境变量env

环境变量的声明有两种方法,方法一在容器运行时Deployment里直接定义,该方法直观,缺点是这样定义的环境变量只能供该Deployment使用。方法二是使用ConfigMap定义,在运行时容器Deployment里引用该ConfigMap作为环境变量,该方法的好处是可以供其它对象统一调用,如果要修改只需要修改一个地方就可以全部生效。

配置文件ConfigMap

配置文件可以使用ConfigMap原样定义,后面在运行时容器Deployment里映射到容器的相应目录即可。

运行时容器Deployment

Deployment定义了一个容器运行时的参数,运行的副本个数,使用的镜像版本,使用的环境变量,映射的目录。

Kubernetes内部调用的Service

一个系统以Deployment的方式把容器运行起来了,如果它要供kubernetes内部系统调用的话,必须暴露端口等参数,以Service的形式定义。Kubernetes其它系统要使用该内部服务的话则以kubernetes内部域名的形式配置在参数里。

外部系统访问Kubernetes内服务

Kubernetes内系统要能够被外部系统调用的话,必须定义一个Service,并且为NodePort的形式把端口映射出去。

五、Kubernetes常用命令

  • 获取所有命名空间上的pod:

        kubectl get pod -o wide --all-namespaces

  • 查看pod IP时使用:

        kubectl get services

  • 查看dsecp-sso-server-w5tx2 日志:

        kubectl describe --namespace=default po ips

  • 通过yaml文件创建:

        kubectl create -f xxx.yaml (不建议使用,无法更新,必须先delete)
        kubectl apply -f xxx.yaml(创建+更新,可以重复使用)

  • 通过yaml文件删除:

        kubectl delete -f xxx.yaml

  • 查看kube-system namespace下面的pod/svc/deployment 等等(-o wide 选项可以查看存在哪个对应的节点):

        kubectl get pod/svc/deployment -n kube-system

  • 查看所有namespace下面的pod/svc/deployment等等:

        kubectl get pod/svc/deployment --all-namcpaces

  • 重启pod(无法删除对应的应用,因为存在deployment/rc之类的副本控制器,删除pod也会重新拉起来):

        kubectl get pod -n kube-system

  • 查看pod描述:

        kubectl describe pod XXX -n kube-system

  • 查看pod 日志 (如果pod有多个容器需要加-c 容器名):

        kubectl logs xxx -n kube-system

  • 删除应用(先确定是由说明创建的,再删除对应的kind):

        kubectl delete deployment xxx -n kube-system

  • 根据label删除:

        kubectl delete pod -l app=flannel -n kube-system

  • 扩容:

        kubectl scale deployment spark-worker-deployment --replicas=8

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值