Month: March 2021

Kubernetes Node污点

kubectl taint nodes 192.168.204.129 key1=value1:NoExecute
node/192.168.204.129 tainted

如果不指定key，那么可以使用

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-hello-deployment3
  namespace: lizhe
  labels:
    app: nginx-hello3
spec:
  replicas: 6
  selector:
    matchLabels:
      app: nginx-hello3
  template:
    metadata:
      labels:
        app: nginx-hello3
    spec:
      tolerations:
      - effect: NoExecute
        operator: Exists
      containers:
      - name: nginx-hello3
        image: nginx
        ports:
        - containerPort: 80

这样会忽略所有 key

可以看到 nginx3 运行在了 129上

如果需要指定特定的 key ，例如这里指定 key = key2 ，实际上这个 key2 不存在，所以是没有任何容忍的

    spec:
      tolerations:
      - effect: NoExecute
        operator: Exists
        key: key2

也可以加入 value 但是就无法使用 operator 了

The Deployment "nginx-hello-deployment3" is invalid: spec.template.spec.tolerations[0].operator: Invalid value: core.Toleration{Key:"key1", Operator:"Exists", Value:"value2", Effect:"NoExecute", TolerationSeconds:(*int64)(nil)}: value must be empty when `operator` is 'Exists'

    spec:
      tolerations:
      - effect: NoExecute
        key: key1
        value: value2

如果想容忍的话

    spec:
      tolerations:
      - effect: NoExecute
        key: key1
        value: value1

Kubernetes Pod 亲和性

和节点亲和性类似，Pod亲和性主要用于限制调度器工作，顾名思义，Pod亲和性是参考pod运行来调度的

而不是像节点亲和性那样根据节点来控制调度

在 Kubernetes 节点亲和性 中我们创建了nginx的deploy

可以看到 nginx全部 运行在 129 上

这里我们尝试让 nginx2 跟随 nginx 调度在同一个节点上

使用

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-hello-deployment2
  namespace: lizhe
  labels:
    app: nginx-hello2
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-hello2
  template:
    metadata:
      labels:
        app: nginx-hello2
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx-hello
            topologyKey: numberCores
      containers:
      - name: nginx-hello2
        image: nginx
        ports:
        - containerPort: 80

结果发现 nginx2 不仅被调度在了 129 上，还被调度在了 139 上

这就不得不说一说 topologyKey 了，由于我们的3个node都指定了 numberCores=6

也就是说，

1. 运行了 pod app=nginx-hello 的 node上，带有numberCores, 且值为 6
2. 则 只要是带有 numberCores 为 6 的 node，都可以运行 nginx2

我们把numberCores在 129 上改为 7 ，这样就只有 129的 numberCores 是 7 ，其余node 都是 6

这样，nginx2 为了跟随 nginx的7，只能被调度在 129上

由于亲和性配置在 已经创建的 pod 上不能重新生效（因为已经被调度完成了）

所以这里我们删除原 dep 重新创建

这一次可以看到，因为只有 129带有7，所以nginx 被全部调度在了 129 上

那如果你想要让 pod A 只被调度在已经运行了 pod B 的节点上，只需要把

topologyKey 写成 kubernetes.io/hostname

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-hello-deployment2
  namespace: lizhe
  labels:
    app: nginx-hello2
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-hello2
  template:
    metadata:
      labels:
        app: nginx-hello2
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx-hello
            topologyKey: kubernetes.io/hostname
      containers:
      - name: nginx-hello2
        image: nginx
        ports:
        - containerPort: 80

Kubernetes 节点亲和性

节点亲和性 是对节点选择器方法的一种泛化，允许指定必要规则和偏好规则

下面的例子是一个 nginx ， 亲和性规则要求它

只考虑有3个以上核心（不包含3个）的节点

尽量选择不是 master 的节点

这里还有一个权重，值为1，如果这个节点符合 名称不为 master，则会获得一个权重积分1

调度器最后会选择一个 所有权重 得分最高的节点，权重是一个列表

看下面一个例子

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-hello-deployment
  namespace: lizhe
  labels:
    app: nginx-hello
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-hello
  template:
    metadata:
      labels:
        app: nginx-hello
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: numberCores
                operator: Gt
                values: ["3"]
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchFields:
              - key: metadata.name
                operator: NotIn
                values: ["master"]
      containers:
      - name: nginx-hello
        image: nginx
        ports:
        - containerPort: 80

在这个例子中，使用了 numberCores ，请不要误以为这是一个 原生字段，实际上这是一个 node 上的 label，我们需要自己手动创建

不创建的话，是不会调度成功的

添加label

已经可以正确调度了

快速安装NFS

有时候我们会在本地环境中使用 kubernetes，这时候想要一些方便的类似 aws 和 其他公有云上那种 storage class 就不太可能了，这时候一般我们会选择使用 linux NFS 来代替这些共有云的存储卷

如果不需要storage class的话，直接使用docker run也是可以的，但是这里，因为我很懒，我希望在 NFS 创建之后能自动得到一个 storage class，那最方便的实际上是 rancher 提供的 helm，注意这里

nfs-client-provisioner 和 nfs-server-provisioner 只是驱动模式不同，功能是一样的

K8S的外部NFS驱动，可以按照其工作方式（是作为NFS server还是NFS client）分为两类：

NFS client 通过K8S的内置的NFS驱动挂载远端的NFS服务器到本地目录；然后将自身作为storage provider，关联storage class。当用户创建对应的PVC来申请PV时，该provider就将PVC的要求与自身的属性比较，一旦满足就在本地挂载好的NFS目录中创建PV所属的子目录，为Pod提供动态的存储服务

NFS server 与 nfs-client 不同，该驱动并不使用 k8s 的 NFS 驱动来挂载远端的 NFS 到本地再分配，而是直接将本地文件映射到容器内部，然后在容器内使用 ganesha.nfsd 来对外提供 NFS 服务；在每次创建 PV 的时候，直接在本地的 NFS 根目录中创建对应文件夹，并 export 出该子目录。利用 NFS 动态提供 Kubernetes 后端存储卷

可惜这里我使用的是 NFS-provisioner https://github.com/kubernetes-retired/external-storage

直接点击安装没什么好说得，注意默认的 node 上存储路径是 /srv，至于存储到哪个node上，这里是随机的，也可以通过node name 指定

可以看到这里我的 workload 被分配在了 139 上，

这种方式最方便的点在于可以直接得到 storage class

然后我们尝试安装一个 nginx 来使用这个 nfs-provisioner

然后我会在 nginx的pod上，使用 shell 在 /test 路径上创建一个测试文件

可以看到这个文件可以在 nfs node 上被找到

Rancher 网站证书配置

在使用helm在已经存在的Kubernetes集群上安装 rancher HA 时，

有3种https模式可选，如果可以使用的话，LET’S ENCRYPT 模式无疑是最简单的方式，LET’S ENCRYPT甚至可以通过cert-manager在证书过期之前，自动更新免费证书，非常的方便。

但是有的时候收到网络环境，或者是客户的额外要求时，就需要手动更新或者设置证书

此处在安装时选择的是 RANCHER-GENERATED CERTIFICATES

在这种模式下 rancher 会自己创建mockup的自管理证书

可以看到 Not secure 提示 以及自管理的证书的细节

我们知道 rancher的网页服务本身就是基于 ingress 暴露的

所以只需要把证书配置到对应的 ingress 上就可以了

上图中可以看到 这个ingress 使用的 cert 是 tls-rancher-ingress

来创建一个新证书的 secret

然后重新指定rancher ingress的cert配置

更新证书

./rke cert rotate

证书已经更新

Kubernetes Downward API

在Kubernetes环境中，因为容器是被动态分配到节点上的，也就是说在容器启动之前，无法知道运行环境的具体信息

那如何在程序中获得当前容器的 pod ip 呢？又或者是 当前容器的 内存限制呢？

Kubernetes 使用 Downward API 通过环境变量和文件，将有关Pod的元数据注入到容器和集群中。

apiVersion: v1
kind: Pod
metadata:
  name: getpodip
spec:
  containers:
  - image: nginx
    name: getpodip
    env: 
    - name: POD_IP
      valueFrom:
        fieldRef: 
          fieldPath: status.podIP
    - name: MEM_LIMITS
      valueFrom:
        resourceFieldRef: 
          containerName: getpodip
          resource: limits.memory

不过由于环境变量无法在容器启动之后更改，也可以将信息挂载到磁盘卷上，这样每次修改之后，程序可以通过重新读取文件内容，更新这些信息

apiVersion: v1
kind: Pod
metadata:
  name: getpodip
spec:
  containers:
  - image: nginx
    name: getpodip
    volumeMounts:
      - name: pod-info
        mountPath: /pod-info
        readOnly: true
      - name: pod-resource
        mountPath: /pod-resource
        readOnly: true
  volumes:
    - name: pod-info
      downwardAPI:
        items:
          - path: POD_IP
            fieldRef: 
              fieldPath: metadata.name
    - name: pod-resource
      downwardAPI:
        items:
          - path: "cpu_limit"
            resourceFieldRef:
              containerName: getpodip
              resource: limits.cpu
              divisor: 1m
          - path: "cpu_request"
            resourceFieldRef:
              containerName: getpodip
              resource: requests.cpu
              divisor: 1m
          - path: "mem_limit"
            resourceFieldRef:
              containerName: getpodip
              resource: limits.memory
              divisor: 1Mi
          - path: "mem_request"
            resourceFieldRef:
              containerName: getpodip
              resource: requests.memory
              divisor: 1Mi

不过不知道为什么这里 metadata.name 无法替换为 status.podIP

The Pod "getpodip" is invalid: 
* spec.volumes[0].downwardAPI.fieldRef.fieldPath: Unsupported value: "status.podIP": supported values: "metadata.annotations", "metadata.labels", "metadata.name", "metadata.namespace", "metadata.uid"
* spec.containers[0].volumeMounts[0].name: Not found: "pod-info"

• Env vars using valueFrom.fieldRef:
  •  spec.nodeName – the node’s name
  •  status.hostIP – the node’s IP
  •  metadata.name – the pod’s name
  •  metadata.namespace – the pod’s namespace
  •  status.podIP – the pod’s IP address
  •  spec.serviceAccountName – the pod’s service account name
  •  metadata.uid – the pod’s UID
  •  metadata.labels[”] – the value of the pod’s label (for example, metadata.labels[‘mylabel’])
  •  metadata.annotations[”] – the value of the pod’s annotation (for example, metadata.annotations[‘myannotation’])
• DownwardAPI volumes via items of fieldRef:
  •  spec.nodeName – the node’s name
  •  status.hostIP – the node’s IP
  •  metadata.name – the pod’s name
  •  metadata.namespace – the pod’s namespace
  •  status.podIP – the pod’s IP address
  •  spec.serviceAccountName – the pod’s service account name
  •  metadata.uid – the pod’s UID
  •  metadata.labels- the value of the pod’s label (for example, metadata.labels[‘mylabel’])
  •  metadata.annotations – the value of the pod’s annotation (for example, metadata.annotations[‘myannotation’])

Kubernetes Secret 安全么

如果要在 kubernetes 保存密码，你一定会想到要使用 secret

  docker-registry Create a secret for use with a Docker registry
  generic         Create a secret from a local file, directory or literal value
  tls             Create a TLS secret

secret分为以上3种，我们来创建一个 generic 类型的 secret 来保存一个密码

kubectl create secret generic secretname --from-literal="mykey=myvalue"

通过以下命令，可以简单查看这个 secret

kubectl get secret secretname -o jsonpath='{.data}'

secret保存base64编码的数据，并在解码后将其作为环境变量或挂载卷提供给pod使用

所以经常有人误认为secret是安全的，然而base64编码不是加密方法，从安全角度上看，它和纯文本没有区别。

echo 'bXl2YWx1ZQ==' | base64 --decode

实际上，secret的安全性在于

• 只有运行了需要访问secret的pod的节点，才会拥有 secret
• 在节点上，secret存储在tmpfs内存中，永远不会写入物理内存，而且会随着 pod 一起删除

tmpfs有以下优势：

1。动态文件系统的大小，/dev /shm/需要注意的一个是容量问题，在linux下，它默认最大为内存的一半大小，使用df -h命令可以看到。但它并不会真正的占用这块内存，如果/dev/shm/下没有任何文件，它占用的内存实际上就是0字节；如果它最大为1G，里头放有 100M文件，那剩余的900M仍然可为其它应用程序所使用，但它所占用的100M内存，是绝不会被系统回收重新划分的
2。tmpfs 的另一个主要的好处是它闪电般的速度。因为典型的 tmpfs 文件系统会完全驻留在 RAM 中，读写几乎可以是瞬间的。
3。tmpfs 数据在重新启动之后不会保留，因为虚拟内存本质上就是易失的。所以有必要做一些脚本做诸如加载，绑定的操作。

这里我创建一个 nginx 部署，挂载刚刚创建的secret

这个pod被分配在节点2上

Secret 的大小不能超过1MB，不能用于存储太大的数据，也不适合作为非配置类型的数据。

因为Base64编码，存储的数据大约只能有700kb

Build docker image from a Kubernetes installed Jenkins

因为默认的 jnlp image 是不包含 docker 命令的，所以这里需要自己先打一个安装docker 的 jnlp

FROM jenkins/jnlp-slave:latest

USER root
RUN apt update && apt install -y curl
RUN curl https://releases.rancher.com/install-docker/20.10.sh | sh
RUN usermod -aG docker jenkins

USER jenkins
ENTRYPOINT ["/usr/local/bin/jenkins-agent"]

这里为了方便我放开了 docker.sock的全部权限

sudo chmod 777 /var/run/docker.sock

关于jenkins的安装请参考

NFS Provisioner

Install Jenkins on Kubernetes

编写pipeline

pipeline {
    agent {
        kubernetes {
            label 'jenkins-slave'
            yaml '''
apiVersion: v1
kind: Pod
metadata:
  name: jenkins-slave
spec:
  containers:
    - name: jnlp
      image: libaibai/lz-jnlp-slave:4.6.1
      securityContext:
        privileged: true
      imagePullPolicy: IfNotPresent
      env:
      - name: JENKINS_URL
        value: http://10.43.113.251:8080
      - name: JENKINS_AGENT_WORKDIR
        value: /tmp
      volumeMounts:
        - mountPath: /var/run/docker.sock
          name: docker-sock
        - name: jenkins-docker-cfg
          mountPath: /root/.docker
      workingDir: /home/jenkins
      resources:
          limits:
            cpu: 100m
            memory: 200Mi
  restartPolicy: Never
  volumes:
    - name: docker-sock
      hostPath:
        path: /var/run/docker.sock
    - name: jenkins-docker-cfg
      projected:
        sources:
        - secret:
            name: regcred
            items:
              - key: .dockerconfigjson
                path: config.json
'''
        }
    }
    stages{
        stage('get code'){
            steps{
                echo 'getted the code...'
                sh "/usr/bin/docker info"
                timeout(time: 2, unit: 'HOURS'){
                    dir('sourcecodes') {
                        git credentialsId: '0559259b-d672-457f-8d2e-d3925c412d70', url: 'https://github.com/zl86790/kanikotest.git'
                    }
                    sh "docker build -f /home/jenkins/agent/workspace/helloworld2/sourcecodes/Dockerfile -t libaibai/useless ."
                }
            }
        }
        stage('push image'){
            steps{
                echo 'push image...'
                sh "/usr/bin/docker info"
                timeout(time: 2, unit: 'HOURS'){
                    withDockerRegistry([ credentialsId: "3182bbdd-fd4d-4497-b262-c882b7ac0ee9", url: "" ]) {
                        sh "docker push libaibai/useless"
                    }
                }
            }
        }
     }
}