前言
首先需要说明一下，本篇内容紧接上一篇文章《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的镜像，二是通过volumes把agent文件夹挂载到业务容器中。这里我传了一个环境变量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的高可用了。但目前的配置都较为简单，预计可能还需要对一些参数进行调整，比如可能还要添加告警规则，这样的话就要考虑目前通过环境变量传入配置的方式是否合理了。
