前言
首先需要說明一下,本篇內容緊接上一篇文章《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)境變量傳入配置的方式是否合理了。