本章节介绍如何通过kubectl创建Deployment, 实现Deployer服务端的部署。
kubectl create ns mindie
ClusterRole和ClusterRoleBinding用于授予Deployer服务端访问Kube API-Server的权限,用户需自行准备以下yaml文件(比如:ms-role.yaml)。
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: ms-role rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create", "delete", "get", "patch"] - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "patch"] - apiGroups: [""] resources: ["configmaps"] verbs: ["get", "create", "delete"] - apiGroups: [""] resources: ["services"] verbs: ["get", "delete", "create"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: ms-role-bind subjects: - kind: User name: kubeclient # 集群用户名,该值为MindIE MS与Kube API-Server通信的客户端证书的CN字段值。 apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: ms-role apiGroup: rbac.authorization.k8s.io
参数 |
说明 |
---|---|
rules |
必填。 resources:Kubernetes资源,MindIE MS业务过程需要具备以下resources的操作权限。
|
ClusterRoleBinding中subjects参数的name |
必填。 Kubernetes集群的用户名称,需要用户自定义。当创建该用户后,Kube API-Server将授予该用户rules参数中指定的权限。 Deployer服务端作为客户端向Kube API-Server发送HTTPS请求,Kube API-Server会检验客户端证书的CN字段,如果与该name一致,将授予上述操作权限。所以用户在使用Deployer服务端之前,需要先准备由集群中间CA签发的客户端证书,详情请参见签发其他证书。 |
使用以下命令创建Role资源。
kubectl apply -f ms-role.yaml
如显示以下回显则表示Role创建成功。
apiVersion: apps/v1 kind: Deployment metadata: name: ms-server namespace: mindie labels: app: ms-server spec: replicas: 1 selector: matchLabels: app: ms-server template: metadata: labels: app: ms-server spec: terminationGracePeriodSeconds: 5 automountServiceAccountToken: false nodeSelector: masterselector: dls-master-node #MindIE MS服务端需部署在Kubernetes管理节点上,节点标签必须选择为masterselector: dls-master-node containers: - image: {镜像名称}:{镜像版本} #内容和用户自定义的镜像名称和镜像版本一致 imagePullPolicy: IfNotPresent name: mindie-ms securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true runAsUser: {UID} #容器用户ID,和Dockerfile的UID一致 runAsGroup: {UID} #容器所属组ID,和Dockerfile的UID一致。 capabilities: drop: ["ALL"] seccompProfile: type: RuntimeDefault volumeMounts: - name: dir1 mountPath: /var/log/mindie-ms - name: dir2 #容器内业务持久化数据文件路径 mountPath: /var/lib/mindie-ms - name: security #容器内证书文件目录 mountPath: /home/{容器内用户名}/mindie-service/latest/security command: ["bin/bash", "-c", "cd /home/{容器内用户名}/mindie-service/latest && ./bin/ms_server ./conf/ms_server.json"] #容器内用户名即为自定义MindIE MS的专用用户名称。 env: - name: HSECEASY_PATH value: /home/{容器内用户名}/mindie-service/latest/lib #容器内用户名即为自定义MindIE MS的专用用户名称。 - name: MINDIE_MS_SERVER_IP valueFrom: fieldRef: fieldPath: status.podIP resources: requests: memory: "512Mi" cpu: "4000m" limits: memory: "1024Mi" cpu: "4000m" volumes: - name: dir1 hostPath: path: /var/log/mindie-ms type: Directory - name: dir2 hostPath: path: /var/lib/mindie-ms type: Directory - name: security hostPath: path: /{用户工作目录}/mindie-service/latest/security type: Directory
参数 |
类型 |
说明 |
---|---|---|
name |
String |
必填。 服务名称。 |
namespace |
String |
必填。 服务所属的命名空间。 |
image |
String |
必填。 内容和用户自定义的镜像名称和镜像版本一致,镜像制作中Dockerfile已创建好的镜像。 |
terminationGracePeriodSeconds |
Int |
允许进程优雅退出的时间,单位秒,优雅退出过程中存在端口占用的可能,若用户删除deployment后退出过程重新部署,可能因端口占用启动失败。 |
runAsUser |
Int |
必填。 容器用户ID,和Dockerfile的UID一致。 |
runAsGroup |
Int |
必填。 容器所属组ID,和Dockerfile的UID一致。 |
volumeMounts |
List |
选填。 用户需要挂载的容器路径(mountPath),需要与volumes参数中的name一一对应进行挂载,需要被挂载的物理路径都可以配置name和mountPath参数对应到容器路径。
挂载容器路径时,请勿挂载到6中的{USER_HOME_DIR}路径,防止覆盖。 |
volumes |
List |
选填。 用户需要挂载物理机路径(hostpath),需要与volumeMounts参数中的name一一对应进行挂载,需要保证挂载的物理路径容器内用户可读且可写。 用户自定义被挂载的物理路径:
|
command |
List |
必填。 启动容器的运行指令。根据用户实际使用场景,填入真实且可以正常启动MindIE MS服务的命令。 用户需保证命令的安全性。
|
mkdir -p /var/lib/mindie-ms/ mkdir -p /var/log/mindie-ms/run mkdir -p /var/log/mindie-ms/operation chown -R {容器内uid}:{容器内gid} /var/lib/mindie-ms/ chown -R {容器内uid}:{容器内gid} /var/log/mindie-ms/ chmod 750 /var/log/mindie-ms/run chmod 750 /var/log/mindie-ms/operation chmod 750 /var/lib/mindie-ms/
kubectl apply -f {Deployment配置文件路径}
kubectl get pod -A
kubectl logs {NAME} -n {NAMESPACE}
kubectl delete -f {Deployment配置文件路径}
回显如下所示则表示卸载成功:
deployment.apps {Deployment配置文件中的name} deleted