kubernates的部署

一、界面部署

1、创建
点击右上角创建按钮

这里写图片描述
2、设置创建的参数
选择创建的方式可以为输入yaml配置,上传yaml文件和界面配置。
①界面创建
这里写图片描述
应用名称
这个是部署pod的名称
- 容器镜像
输入要部署的容器的镜像地址
- 容器组个数
这个参数是k8s要保证运行的pod数量,如果指定3,它会创建3个Pod,并且持续监控它们。如果某个Pod不响应,那么Replication Controller会替换它,保持总数为3。如果之前不响应的Pod恢复了,现在就有4个Pod了,那么Replication Controller会将其中一个终止保持总数为3。
- 服务
选择内部或者外部,内部服务将使得集群外部请求不能访问到pod,外部则会暴露nodePort使得外部机器可访问,服务中的端口类型共有3种:

1)nodePort
 外部机器可访问的端口。
比如一个Web应用需要被其他用户访问,那么需要配置type=NodePort,而且配置nodePort=30001,那么其他机器就可以通过浏览器访问scheme://node:30001访问到该服务,例如http://node:30001
 例如MySQL数据库可能不需要被外界访问,只需被内部服务访问,那么不必设置NodePort
2)targetPort
 容器的端口(最根本的端口入口),与制作容器时暴露的端口一致(DockerFile中EXPOSE),例如docker.io官方的nginx暴露的是80端口。
3)port
 kubernetes中的服务之间访问的端口,尽管mysql容器暴露了3306端口(参考https://github.com/docker-library/mysql/的DockerFile),但是集群内其他容器需要通过33306端口访问该服务,外部机器不能访问mysql服务,因为他没有配置NodePort类型

- 保密字典
当要拉取私有服务器的镜像的时候需要用户名密码,在k8s中这个是通过配置保密字典secret来实现的。
K8s 中Secret是一个包含少量敏感信息如密码,令牌,或秘钥的对象。这些信息可能被保存在 pod 定义或者 docker 镜像中,把这些信息保存在 Secret对象中,可以在这些信息被使用时加以控制,并可以降低信息泄露的风险。
创建保密字典的方式有很多种,我是通过命令行的方式配置的:

kubectl create secret docker-registry regsecret --docker-server=repo.gildata.com --docker-username=chenyang --docker-password=xxxx --docker-email=chenyang@gildata.com

这行命令是创建了一个名为regsecret的保密字典,--docker-server表示为仓库地址,--docker-username是用户账户,--docker-password为账户密码,--docker-email用户邮箱。

这个配置完之后,在k8s的界面上就可以看到我们配置的保密字典:
这里写图片描述
在界面上选择的时候可以点击下面的高级按钮选择相应的保密字典:
这里写图片描述
选择刚刚创建的保密字典:
这里写图片描述
这样私有仓库的镜像就可以拉取了。

②yaml配置
1)zipkin的Deployment配置:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: zipkin
spec:
  replicas: 1
  template:
    metadata:
      labels:
        k8s-app: zipkin
    spec:
      containers:
      - name: zipkin
        image: openzipkin/zipkin
        ports:
          - containerPort: 9411
            hostPort: 9411

我在这里直接用Deployment来管理pod,Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法,用来替代以前的ReplicationController来方便的管理应用。典型的应用场景包括:

  • 定义Deployment来创建Pod和ReplicaSet
  • 滚动升级和回滚应用
  • 扩容和缩容
  • 暂停和继续Deployment

把这段配置文件提交在k8s管理界面的yaml文件框里面,或者直接是提交本地yaml文件,这两种方法大同小异。

附:k8s的pod的配置所有选项介绍:

 # yaml格式的pod定义文件完整内容:
 apiVersion: v1          #必选,版本号,例如v1
 kind: Pod             #必选,Pod
 metadata:             #必选,元数据
   name: string          #必选,Pod名称
   namespace: string       #必选,Pod所属的命名空间
   labels:             #自定义标签
     - name: string       #自定义标签名字
   annotations:          #自定义注释列表
     - name: string
 spec:                #必选,Pod中容器的详细定义
   containers:           #必选,Pod中容器列表
   - name: string        #必选,容器名称
     image: string       #必选,容器的镜像名称
     imagePullPolicy: [Always | Never | IfNotPresent]  #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像,否则下载镜像,Nerver表示仅使用本地镜像
     command: [string]       #容器的启动命令列表,如不指定,使用打包时使用的启动命令
     args: [string]         #容器的启动命令参数列表
     workingDir: string      #容器的工作目录
     volumeMounts:         #挂载到容器内部的存储卷配置
     - name: string         #引用pod定义的共享存储卷的名称,需用volumes[]部分定义的的卷名
       mountPath: string     #存储卷在容器内mount的绝对路径,应少于512字符
       readOnly: boolean     #是否为只读模式
     ports:              #需要暴露的端口库号列表
     - name: string         #端口号名称
       containerPort: int    #容器需要监听的端口号
       hostPort: int        #容器所在主机需要监听的端口号,默认与Container相同
       protocol: string      #端口协议,支持TCP和UDP,默认TCP
     env:              #容器运行前需设置的环境变量列表
     - name: string        #环境变量名称
       value: string       #环境变量的值
     resources:          #资源限制和请求的设置
       limits:           #资源限制的设置
         cpu: string       #Cpu的限制,单位为core数,将用于docker run --cpu-shares参数
         memory: string      #内存限制,单位可以为Mib/Gib,将用于docker run --memory参数
       requests:         #资源请求的设置
         cpu: string       #Cpu请求,容器启动的初始可用数量
         memory: string      #内存清楚,容器启动的初始可用数量
     livenessProbe:        #对Pod内个容器健康检查的设置,当探测无响应几次后将自动重启该容器,检查方法有exec、httpGet和tcpSocket,对一个容器只需设置其中一种方法即可
       exec:             #对Pod容器内检查方式设置为exec方式
         command: [string]   #exec方式需要制定的命令或脚本
       httpGet:            #对Pod内个容器健康检查方法设置为HttpGet,需要制定Path、port
         path: string
         port: number
         host: string
         scheme: string
         HttpHeaders:
         - name: string
           value: string
       tcpSocket:            #对Pod内个容器健康检查方式设置为tcpSocket方式
          port: number
        initialDelaySeconds: 0   #容器启动完成后首次探测的时间,单位为秒
        timeoutSeconds: 0      #对容器健康检查探测等待响应的超时时间,单位秒,默认1秒
        periodSeconds: 0       #对容器监控检查的定期探测时间设置,单位秒,默认10秒一次
        successThreshold: 0
        failureThreshold: 0
        securityContext:
          privileged: false
     restartPolicy: [Always | Never | OnFailure] #Pod的重启策略,Always表示一旦不管以何种方式终止运行,kubelet都将重启,OnFailure表示只有Pod以非0退出码退出才重启,Nerver表示不再重启该Pod
     nodeSelector: obeject     #设置NodeSelector表示将该Pod调度到包含这个label的node上,以key:value的格式指定
     imagePullSecrets:         #Pull镜像时使用的secret名称,以key:secretkey格式指定
     - name: string
     hostNetwork: false        #是否使用主机网络模式,默认为false,如果设置为true,表示使用宿主机网络
     volumes:              #在该pod上定义共享存储卷列表
     - name: string          #共享存储卷名称 (volumes类型有很多种)
       emptyDir: {}          #类型为emtyDir的存储卷,与Pod同生命周期的一个临时目录。为空值
       hostPath: string        #类型为hostPath的存储卷,表示挂载Pod所在宿主机的目录
         path: string        #Pod所在宿主机的目录,将被用于同期中mount的目录
       secret:             #类型为secret的存储卷,挂载集群与定义的secre对象到容器内部
         scretname: string  
         items:     
         - key: string
           path: string
       configMap:          #类型为configMap的存储卷,挂载预定义的configMap对象到容器内部
         name: string
         items:
         - key: string
           path: string    

2)service配置

在pod成功部署之后,就需要为这个pod配置service。

Kubernete Service 是一个定义了一组Pod的策略的抽象,我们也有时候叫做宏观服务。这些被服务标记的Pod都是(一般)通过label Selector决定的。

举个例子,我们假设后台是一个图形处理的后台,并且由3个副本。这些副本是可以相互替代的,并且前台并不需要关心使用的哪一个后台Pod,当这个承载前台请求的pod发生变化时,前台并不需要直到这些变化,或者追踪后台的这些副本,这些都是通过服务来定位追踪的。

简单地说,服务就是请求到pod的一座桥梁,请求并不需要关心自己会请求到哪个pod,这些对于用户和请求来说都是不可见的,用户也不会感觉到这是一个集群,一个请求过来,service会自动分配到哪个pod上。

service的yaml配置文件:

apiVersion: v1
kind: Service
metadata:
 name: zipkin
 labels:
   k8s-app: zipkin
spec:
 type: LoadBalancer
 ports:
 - port: 9411
   targetPort: 9411
   nodePort: 30002
 selector:
  k8s-app: zipkin

2)ConfigMap配置

ConfigMap用于保存配置数据的键值对,可以用来保存单个属性,也可以用来保存配置文件。ConfigMap跟secret很类似,但它可以更方便地处理不包含敏感信息的字符串。

简单的说,相对于docker-compose的配置文件在文件目录下面,k8s的配置文件放到了自己的配置字典里面。

下面是ConfigMap的配置

apiVersion: v1
kind: ConfigMap
metadata:
  name: logstash-config
  namespace: default
data:
  logstash.yml: |
    http.host: "0.0.0.0"
    path.config: /usr/share/logstash/pipeline
  logstash.conf: |
    input {
        tcp {
            port => 5000
            codec => json_lines {
                charset => "UTF-8"
            }
        }
    }
    output {
        elasticsearch {
            hosts => "elasticsearch:9200"
        }
    }

logstash-config表示配置字典的名称。

data里面每一个key-value键值对都会生成一个文件,key为文件名,value为内容。

同样的,在点击上传之后,会在配置字典菜单中生成相应的配置字典。如图所示:
这里写图片描述

这样就可以在deployment中引用这个配置字典:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: logstash
spec:
  replicas: 1
  template:
    metadata:
      labels:
        k8s-app: logstash
    spec:
      containers:
      - name: logstash
        image: docker.elastic.co/logstash/logstash:6.2.3
        ports:
          - containerPort: 5000
            hostPort: 5000
        env:
          - name: ES_JAVA_OPTS
            value: "-Xmx256m -Xms256m"
        volumeMounts:
          - name: logstash-volume1   #volumes中配的volume名字
            mountPath: /usr/share/elasticsearch/config   #在容器内部的配置文件存放地址
          - name: logstash-volume2   #volumes中配的volume名字
            mountPath: /usr/share/logstash/pipeline     #在容器内部的配置文件存放地址
        imagePullSecrets:
          - name: regsecret   #  保密字典
      volumes:
      - name: logstash-volume1  #这个是现在自定义的volume的名字,方便在volumeMounts中引用
        configMap:
          name: logstash-config   #这个就是之前配的配置字典
          items:
          - key: logstash.yml  #配置字典里面对应的key
            path: config
      - name: logstash-volume2   #这个是现在自定义的volume的名字,方便在volumeMounts中引用
        configMap:
          name: logstash-config   #这个就是之前配的配置字典
          items:
          - key: logstash.conf   #配置字典里面对应的ke
            path: pipeline

3、部署

配置好之后点击部署,然后查看概况,状态图都为绿色,容器组的状态为running,这样就部署成功了,如图:
这里写图片描述
可以进行访问Zipkin,输入http://10.106.0.51:32552,这里的32552即为nodePort:
这里写图片描述
当在后期需要调整node的数量的时候,可以在deployment中调整数量,如图所示:
这里写图片描述
第二步:
这里写图片描述

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐