k8s的初步部署zipkin和elk

文章目录

[隐藏]

• 一、界面部署
  • 1、创建
  • 2、设置创建的参数
  • 3、部署

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 [email protected]    这行命令是创建了一个名为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中调整数量，如图所示：

第二步：

原文出处：csdn -> https://blog.csdn.net/qq_20989105/article/details/80811357