k8s環(huán)境下Skywalking容器化部署

前言

首先需要說明一下，本篇內容緊接上一篇文章《Skywalking部署及使用》，由于是在其基礎上進行的容器化改造，所以前提條件與上文相同，部署的是skywalking的6.5.0版本，elasticsearch使用的是6.8.2版本，并且不包含elasticsearch的部署過程。

另外，我在動手之前也了解了skywalking官方的k8s部署實現(xiàn)，地址是https://github.com/apache/skywalking-kubernetes，官方是采用helm進行的部署，但我自己使用后發(fā)現(xiàn)沒法正常下載依賴，由于該庫還比較新可能是還處于調整階段吧，所以暫時放棄了這種方式，仍采用傳統(tǒng)的基于yaml文件的方式進行部署。

ServiceAccount創(chuàng)建

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不具備該權限，因此需要創(chuàng)建一個具有該權限的ServiceAccount，因為要跨namespace進行操作，因此我創(chuàng)建的是ClusterRole類型的ServiceAccount，名為skywalking-oap-sa，后續(xù)會用到，yaml的具體內容如上所述，看不懂的話自行補課K8S的rbac機制。

oap-server部署

官方默認提供了鏡像，鏡像名稱是apache/skywalking-oap-server，想要了解鏡像的更多信息，可以參考https://hub.docker.com/r/apache/skywalking-oap-server。

部署的過程中發(fā)現(xiàn)官方鏡像的時區(qū)采用的是UTC，而我們k8s中的服務清一色都采用的CST，這會導致agent采集的信息和oap-server的時區(qū)不一致，所以我對官方鏡像進行了一點小改動，將官方鏡像設置了新時區(qū)后生成了我的定制鏡像，并上傳到了公司的私有鏡像倉庫中，具體的dockerfile如下所示。

FROM docker.io/apache/skywalking-oap-server:6.5.0

# 時區(qū)修改為東八區(qū)
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環(huán)境變量進行傳參的方式，主要傳的是和es相關的參數(shù)。SW_CLUSTER我之前傳的是kubernetes，然后發(fā)現(xiàn)日志中一直刷There is no available remote server for now, ignore the streaming data until the cluster metadata initialized.的錯誤，也沒法正確創(chuàng)建es中的索引，猜測是少傳了一些參數(shù)，之后改成了standalone就一切正常了，配合創(chuàng)建的service一起使用也能起到集群的效果，暫時沒發(fā)現(xiàn)有什么問題。

另外，官方提供了SW_L0AD_CONFIG_FILE_FROM_VOLUME這個環(huán)境變量，設置為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

# 時區(qū)修改為東八區(qū)
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一樣， 為了修改時區(qū)，首先仍然是基于官方鏡像創(chuàng)建自己的鏡像，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的方式，環(huán)境變量中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的監(jiān)控頁面了。

agent加載

由于沒找到官方的agent鏡像，只好自己動手做了一個。首先下載apache-skywalking-apm-6.5.0.tar.gz安裝包并解壓，保證apache-skywalking-apm-bin文件夾和創(chuàng)建的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的配置信息，雖然有些參數(shù)啟動時我們會動態(tài)傳入，如oap-server的地址，但如果每個參數(shù)都要動態(tài)傳入的話就太繁瑣了，所以類似日志目錄、日志級別這些參數(shù)都應提前設置好，具體這里就不展開了，可以參考上一篇文章。

鏡像生成后上傳至私有鏡像倉庫，我的鏡像命名為hub.komect.com:10443/hmall/skywalking-agent。

通過上述方式生成的鏡像只有不到20M，因此可以通過sidecar方式將agent掛載到需要監(jiān)控的業(yè)務deployment中，無需改動業(yè)務鏡像，只改動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的鏡像，二是通過volumes把agent文件夾掛載到業(yè)務容器中。這里我傳了一個環(huán)境變量SKYWALKING_ADDR用于動態(tài)傳入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

由于我的業(yè)務中工程啟動是在業(yè)務的dockerfile中通過ENTRYPOINT定義的，所以加載agent這里也要相應修改，需要傳入agent的絕對路徑，oap-server的地址和業(yè)務模塊在skywalking中展示的名稱，具體如上所示。

總結

到此為止對Skywalking的容器化部署改造算是基本完成了，并且借助k8s的特性也基本能夠保證skywalking的高可用了。但目前的配置都較為簡單，預計可能還需要對一些參數(shù)進行調整，比如可能還要添加告警規(guī)則，這樣的話就要考慮目前通過環(huán)境變量傳入配置的方式是否合理了。

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發(fā)布，文章內容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

推薦閱讀更多精彩內容