美文网首页docker. k8sSkyWalking
k8s环境下Skywalking容器化部署

k8s环境下Skywalking容器化部署

作者: 海涛_meteor | 来源:发表于2020-01-07 11:10 被阅读0次

    前言

    首先需要说明一下,本篇内容紧接上一篇文章《Skywalking部署及使用》,由于是在其基础上进行的容器化改造,所以前提条件与上文相同,部署的是skywalking的6.5.0版本,elasticsearch使用的是6.8.2版本,并且不包含elasticsearch的部署过程。

    另外,我在动手之前也了解了skywalking官方的k8s部署实现,地址是https://github.com/apache/skywalking-kubernetes,官方是采用helm进行的部署,但我自己使用后发现没法正常下载依赖,由于该库还比较新可能是还处于调整阶段吧,所以暂时放弃了这种方式,仍采用传统的基于yaml文件的方式进行部署。

    ServiceAccount创建

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: skywalking-oap-sa
      namespace: skywalking
    
    ---
    
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: skywalking-clusterrolebinding
    subjects:
    - kind: Group
      name: system:serviceaccounts:skywalking
      apiGroup: rbac.authorization.k8s.io
    roleRef:
      kind: ClusterRole
      name: skywalking-clusterrole
      apiGroup: rbac.authorization.k8s.io
    ---
    
    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: skywalking-clusterrole
    rules:
    - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "watch", "list"]
    

    由于需要对pods进行操作,但我使用的默认ServiceAccount不具备该权限,因此需要创建一个具有该权限的ServiceAccount,因为要跨namespace进行操作,因此我创建的是ClusterRole类型的ServiceAccount,名为skywalking-oap-sa,后续会用到,yaml的具体内容如上所述,看不懂的话自行补课K8S的rbac机制。

    oap-server部署

    官方默认提供了镜像,镜像名称是apache/skywalking-oap-server,想要了解镜像的更多信息,可以参考https://hub.docker.com/r/apache/skywalking-oap-server

    部署的过程中发现官方镜像的时区采用的是UTC,而我们k8s中的服务清一色都采用的CST,这会导致agent采集的信息和oap-server的时区不一致,所以我对官方镜像进行了一点小改动,将官方镜像设置了新时区后生成了我的定制镜像,并上传到了公司的私有镜像仓库中,具体的dockerfile如下所示。

    FROM docker.io/apache/skywalking-oap-server:6.5.0
    
    # 时区修改为东八区
    RUN apk add --no-cache tzdata
    ENV TZ=Asia/Shanghai
    RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
    
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: oap
      namespace: skywalking
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: oap
      template:
        metadata:
          labels:
            app: oap
            release: skywalking
        spec:
          serviceAccountName: skywalking-oap-sa
          containers:
          - name: oap
            image: hub.komect.com:10443/hmall/skywalking-oap-server:6.5.0
            imagePullPolicy: Always
            livenessProbe:
              tcpSocket:
                port: 12800
              initialDelaySeconds: 15
              periodSeconds: 20
            readinessProbe:
              tcpSocket:
                port: 12800
              initialDelaySeconds: 15
              periodSeconds: 20
            ports:
            - containerPort: 11800
              name: grpc
            - containerPort: 12800
              name: rest
            resources:
              requests:
                memory: 1Gi
              limits:
                memory: 2Gi
            env:
            - name: JAVA_OPTS
              value: "-Xmx2g -Xms2g"
            - name: SW_CLUSTER
              value: standalone
            - name: SKYWALKING_COLLECTOR_UID
              valueFrom:
                fieldRef:
                  fieldPath: metadata.uid
            - name: SW_STORAGE
              value: elasticsearch
            - name: SW_STORAGE_ES_CLUSTER_NODES
              value: 172.28.51.131:9200
            - name: SW_NAMESPACE
              value: hmall
            - name: SW_ES_USER
              value: elastic
            - name: SW_ES_PASSWORD
              value: XXXXXX
          imagePullSecrets:
          - name: harbor-secret
    

    oap-server采用deployment的形式进行部署,镜像名称和serviceAccount就不多说了,按照上面提到的填写就可以了,剩下主要就是原来虚拟机方式部署时congfig文件夹下的配置文件如何加载的问题。

    我这里采用的是通过env环境变量进行传参的方式,主要传的是和es相关的参数。SW_CLUSTER我之前传的是kubernetes,然后发现日志中一直刷There is no available remote server for now, ignore the streaming data until the cluster metadata initialized.的错误,也没法正确创建es中的索引,猜测是少传了一些参数,之后改成了standalone就一切正常了,配合创建的service一起使用也能起到集群的效果,暂时没发现有什么问题。

    另外,官方提供了SW_L0AD_CONFIG_FILE_FROM_VOLUME这个环境变量,设置为true后配合configmap中挂载application.yaml等配置文件的方式,也可以起到加载配置的效果。这种方式相当于把原来config文件夹下的配置文件全部放进了configmap中,稍显臃肿,由于我暂时没有这么强的定制化配置需求,暂时就不考虑使用该方式了。

    apiVersion: v1
    kind: Service
    metadata:
      name: oap
      namespace: skywalking
      labels:
        service: oap
    spec:
      ports:
      - port: 12800
        name: rest
      - port: 11800
        name: grpc
      selector:
        app: oap
    

    最后,通过service把oap-server的11800和12800端口开放出去,供ui和agent使用,oap-server的部署就算完成了。

    ui部署

    FROM docker.io/apache/skywalking-ui:6.5.0
    
    # 时区修改为东八区
    RUN apk add --no-cache tzdata
    ENV TZ=Asia/Shanghai
    RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
    

    和oap-server一样, 为了修改时区,首先仍然是基于官方镜像创建自己的镜像,dockerfile如上所示

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: ui-deployment
      namespace: skywalking
      labels:
        app: ui
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: ui
      template:
        metadata:
          labels:
            app: ui
        spec:
          containers:
          - name: ui
            image: hub.komect.com:10443/hmall/skywalking-ui:6.5.0
            imagePullPolicy: Always
            ports:
            - containerPort: 8080
              name: page
            resources:
              requests:
                memory: 1Gi
              limits:
                memory: 2Gi
            env:
            - name: SW_OAP_ADDRESS
              value: oap:12800
          imagePullSecrets:
          - name: harbor-secret
    

    ui的部署也是采用deployment的方式,环境变量中SW_OAP_ADDRESS的地址和端口对应的是oap的service地址。

    apiVersion: v1
    kind: Service
    metadata:
      name: ui
      namespace: skywalking
      labels:
        service: ui
    spec:
      ports:
      - port: 8080
        name: page
        nodePort: 31234
      type: NodePort
      selector:
        app: ui
    

    ui的service用于提供外部访问页面,为了方便采用了nodeport的方式对外开放。部署完成后通过http://ip:31234的方式就能正常访问skywalking的监控页面了。

    agent加载

    由于没找到官方的agent镜像,只好自己动手做了一个。首先下载apache-skywalking-apm-6.5.0.tar.gz安装包并解压,保证apache-skywalking-apm-bin文件夹和创建的dockerfile处于同一目录下,dockerfile内容如下所示。

    FROM busybox:latest 
    
    ENV LANG=C.UTF-8
    
    RUN set -eux && mkdir -p /opt/skywalking/agent/
    
    ADD apache-skywalking-apm-bin/agent/ /opt/skywalking/agent/
    
    WORKDIR /
    

    这里有一点要注意,解压后要先进入apache-skywalking-apm-bin/agent/config目录,修改好agent.config的配置信息,虽然有些参数启动时我们会动态传入,如oap-server的地址,但如果每个参数都要动态传入的话就太繁琐了,所以类似日志目录、日志级别这些参数都应提前设置好,具体这里就不展开了,可以参考上一篇文章。

    镜像生成后上传至私有镜像仓库,我的镜像命名为hub.komect.com:10443/hmall/skywalking-agent

    通过上述方式生成的镜像只有不到20M,因此可以通过sidecar方式将agent挂载到需要监控的业务deployment中,无需改动业务镜像,只改动deployment的yaml就可以,具体需要改动的部分如下:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: $DEPLOYMENT_NAME
      name: $DEPLOYMENT_NAME
      namespace: hmall
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: hui-mall-gateway-docker
      template:
        metadata:
          labels:
            app: hui-mall-gateway-docker
        spec:
          initContainers:
          - name: init-agent
            image: hub.komect.com:10443/hmall/skywalking-agent:latest
            command:
            - 'sh'
            - '-c'
            - 'set -ex;mkdir -p /skywalking/agent;cp -r /opt/skywalking/agent/* /skywalking/agent;'
            volumeMounts:
            - name: agent
              mountPath: /skywalking/agent
          containers:
          - env:
            - name: SKYWALKING_ADDR
              value: $SKYWALKING_ADDR
                   ***部分省略***
            volumeMounts:
            - name: agent
              mountPath: /opt/skywalking/agent 
          volumes:
          - name: agent
            emptyDir: {}
    

    可以看到主要是两部分需要改动,一是通过initContainers初始化加载agent的镜像,二是通过volumesagent文件夹挂载到业务容器中。这里我传了一个环境变量SKYWALKING_ADDR用于动态传入oap-server的地址。

    FROM openjdk:8-jdk
    VOLUME /tmp
    ARG JAR_FILE
    ADD target/${JAR_FILE} app.jar
    RUN apt-get install -y tzdata \
        && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \
        && dpkg-reconfigure -f noninteractive tzdata
    ENTRYPOINT exec java $JAVA_OPTS -Dapp.id=$APP_ID \
    -javaagent:/opt/skywalking/agent/skywalking-agent.jar \
    -Dskywalking.agent.service_name=$APP_ID \
    -Dskywalking.collector.backend_service=$SKYWALKING_ADDR -jar /app.jar
    

    由于我的业务中工程启动是在业务的dockerfile中通过ENTRYPOINT定义的,所以加载agent这里也要相应修改,需要传入agent的绝对路径,oap-server的地址和业务模块在skywalking中展示的名称,具体如上所示。

    总结

    到此为止对Skywalking的容器化部署改造算是基本完成了,并且借助k8s的特性也基本能够保证skywalking的高可用了。但目前的配置都较为简单,预计可能还需要对一些参数进行调整,比如可能还要添加告警规则,这样的话就要考虑目前通过环境变量传入配置的方式是否合理了。

    相关文章

      网友评论

        本文标题:k8s环境下Skywalking容器化部署

        本文链接:https://www.haomeiwen.com/subject/bmrractx.html