其他分享
首页 > 其他分享> > 基于openkruise实现容器应用固定id

基于openkruise实现容器应用固定id

作者:互联网

背景说明

我们在业务上容器的过程中遇到了如下问题:

  1. 以deployment部署的应用pod,由于id经常变更,服务重启,监控变得难以维护。这里只是以监控为切入点,事实上,还有诸多应用需要与id强绑定。
  2. statefulset可以解决上面的问题,但是引入一个新的问题就是statefulset本身为了维护有状态的应用,所有的应用Pod启动是有严格的先后顺序,也就是串行启动,对于大规模的应用pod来讲,启动消耗时间太长,这是无法忍受的。

为解决以上问题,我们在容器平台当中引入了openkruise。

openkruise简介

项目地址: https://github.com/openkruise/kruise

详细的说明可以参考这篇文章: 《OpenKruise - 云原生应用自动化引擎正式开源》

从当前github上的文档来看,目前OpenKruise支持五种改进的控制器:

UnitedDeployment是在StatefulSet基础上的更高级抽象,通过一个资源描述可以管理多个StatefulSet的实例组,可实现多实例组的灰度发布与滚动升级。

Broadcast Job实际上就是以DaemonSet的方式在所有节点上运行一次性Job

SidercarSet用于Sidercar注入及管理

而我们要使用到的正是其Advanced StatefulSet的特性。关于Advanced StatefulSet更详细的描述如下:

部署openkruise

官方的安装文档可以直接参考这里: https://github.com/openkruise/kruise/tree/master/docs/tutorial

我简单写下安装步骤:

wget https://github.com/openkruise/kruise/releases/download/v0.4.0/kruise-chart.tgz

tar xf kruise-chart.tgz

cd kruise

helm install openkruise ./ -n kube-system 

目前openkruise已经更新到了v0.5.0的版本。也可以直接通过阿里云的应用目录来完成其安装。

下面说一下更详细的安装过程:

  1. 获取helm包

helm repo add incubator  http://aliacs-k8s-cn-beijing.oss-cn-beijing.aliyuncs.com/app/charts-incubator/

helm search repo ack-kruise

helm fetch incubator/ack-kruise

tar xf ack-kruise-0.5.0.tgz

cd ack-kruise

修改values.yml文件如下:

# Default values for kruise.

revisionHistoryLimit: 3

manager:
  # settings for log print
  log:
    # log level for kruise-manager
    level: "4"

  # image settings
  image:
    # repository for kruise-manager image
    repository: hub.example.com/library/kruise-manager
    # tag for kruise-manager image
    tag: v0.5.0

  # resources of kruise-manager container
  resources:
    limits:
      cpu: 500m
      memory: 1Gi
    requests:
      cpu: 500m
      memory: 1Gi

  metrics:
    addr: localhost
    port: 8080
    
  custom_resource_enable: StatefulSet

其实这里就改了两个东西:

然后执行安装操作:

helm install ack-kruise -n kube-system ./

安装完后,会生成以下五种crd:

# kubectl get crds |grep kruise
broadcastjobs.apps.kruise.io            2020-04-26T10:29:28Z
clonesets.apps.kruise.io                2020-04-26T10:29:28Z
sidecarsets.apps.kruise.io              2020-04-26T10:29:28Z
statefulsets.apps.kruise.io             2020-04-26T10:29:28Z
uniteddeployments.apps.kruise.io        2020-04-26T10:29:28Z

同时会创建一个kruise-system的命名空间,并在里面生成一个pod:

# kubectl get pods -n kruise-system 
NAME                          READY   STATUS    RESTARTS   AGE
kruise-controller-manager-0   1/1     Running   0          55m

验证statefulset资源的webhook是否被正常创建:

# kubectl get mutatingwebhookconfiguration -o yaml

apiVersion: v1
items:
- apiVersion: admissionregistration.k8s.io/v1
  kind: MutatingWebhookConfiguration
  metadata:
    creationTimestamp: "2020-04-26T10:29:28Z"
    generation: 3
    name: kruise-mutating-webhook-configuration
    resourceVersion: "622944921"
    selfLink: /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations/kruise-mutating-webhook-configuration
    uid: 303a7b7f-3a62-49d7-8ef6-082ea288eeb2
  webhooks:
  - admissionReviewVersions:
    - v1beta1
    clientConfig:
      caBundle: xxxxx
      service:
        name: kruise-webhook-server-service
        namespace: kruise-system
        path: /mutating-create-update-statefulset
        port: 443
    failurePolicy: Fail
    matchPolicy: Exact
    name: mutating-create-update-statefulset.kruise.io
    namespaceSelector:
      matchExpressions:
      - key: control-plane
        operator: DoesNotExist
    objectSelector: {}
    reinvocationPolicy: Never
    rules:
    - apiGroups:
      - apps.kruise.io
      apiVersions:
      - v1alpha1
      operations:
      - CREATE
      - UPDATE
      resources:
      - statefulsets
      scope: '*'
    sideEffects: Unknown
    timeoutSeconds: 30
......

也是确保其他未用到的相关mutatingwebhook是关闭的。。在实际测试中,SidecarSet资源的mutatingwebhook可能会导致创建的pod出不来。

这些webhook本质上都是kubernetes的admissioncontrol,只要你安装了,哪怕没有使用,当你在执行相关操作时,都需要被所有的adminssioncontrol检测,如果admissioncontrol本身出了问题,就会导致请求无法响应的状态。同时这些webhook类型的adminssioncontrol也会拖慢响应速度。

用法示例

下面是官方提供的一个基于openkruise提供的statefulset资源的部署文件示例:

apiVersion: apps.kruise.io/v1alpha1
kind: StatefulSet
metadata:
  name: demo-v1-guestbook-kruise
  labels:
    app.kubernetes.io/name: guestbook-kruise
    app.kubernetes.io/instance: demo-v1
spec:
  replicas: 20
  serviceName: demo-v1-guestbook-kruise
  selector:
    matchLabels:
      app.kubernetes.io/name: guestbook-kruise
      app.kubernetes.io/instance: demo-v1
  template:
    metadata:
      labels:
        app.kubernetes.io/name: guestbook-kruise
        app.kubernetes.io/instance: demo-v1
    spec:
      readinessGates:
        # A new condition that ensures the pod remains at NotReady state while the in-place update is happening
      - conditionType: InPlaceUpdateReady
      containers:
      - name: guestbook-kruise
        image: openkruise/guestbook:v1
        imagePullPolicy: Always
        ports:
        - name: http-server
          containerPort: 3000
  podManagementPolicy: Parallel  # allow parallel updates, works together with maxUnavailable
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      # Do in-place update if possible, currently only image update is supported for in-place update
      podUpdatePolicy: InPlaceIfPossible
      # Allow parallel updates with max number of unavailable instances equals to 2
      maxUnavailable: 3

执行部署之后,启动pod示例如下:

# kubectl get pods  |grep demo-v1
demo-v1-guestbook-kruise-0                                 1/1     Running   0          62s
demo-v1-guestbook-kruise-1                                 1/1     Running   0          62s
demo-v1-guestbook-kruise-2                                 1/1     Running   0          62s

更详细的用法可参考:

标签:容器,StatefulSet,v1,io,openkruise,id,guestbook,kruise
来源: https://www.cnblogs.com/breezey/p/12925103.html