Kubernetes & Docker on CctoctoFX

Kubernetes Operator Development History

Thu, 29 Apr 2021 11:22:18 +0800

本文旨在记录对中间件、编排组件容器化部署后，实现kubernetes扩展组件Controller的过程。

Third-Parties

kubernetes-client: javascript

client-go

kube-rs

`client-go`源码分析

目录结构

kubernetes: contains the clientset to access Kubernetes API.

discovery: discover APIs supported by a Kubernetes API server.

dynamic: contains a dynamic client that can perform generic operations on arbitrary Kubernetes API objects.

transport: set up auth and start a connection.

tools/cache: useful for writing controllers.

informers: informer group

listers: lister group

代码实例

git clone https://github.com/huweihuang/client-go.git
cd client-go
#保证本地HOME目录有配置kubernetes集群的配置文件
go run client-go.go

client-go.go

Kubernetes ConfigMap 热更新

Sat, 24 Apr 2021 11:22:18 +0800

注：如果对kubernetes的基本概念不太清楚，建议先过一下基本的资源类型再阅读此文

先随便给个例子:

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-config
data:
  config.yml: |-
    start-message: 'Hello, World!'
    log-level: INFO
  bootstrap.yml:
    listen-address: '127.0.0.1:8080'

我们定义了一个ConfigMap，data中定义了两个文件config.yml以及bootstrap.yml，当我们要引用当中的配置的时候，kubernetes提供了两种方案：

使用configMapKeyRef引用configMap中某个文件的内容作为Pod中容器的环境变量。
把所有configMap中的文件写到一个临时目录，将临时目录作为volume挂载到容器中，也就是configmap类型的volume。

假设现在我们有一个Deployment，它的pod模板里引用了configMap，现在我们的目标是：当configmap更新的时候，这个Deployment的业务逻辑也能随之更新。那么有哪些方案？
最好的情况是，当configMap发生变更时，直接进行hot update，做到不影响pod的正常运行。
如果无法hot update或者这样完成不了需求，就要出发对应的Deployment做一次滚动更新。

场景一：针对可以进行热更新的容器，进行配置热更新

如果configMap由volume挂载，比如下述的投射卷，它的内容是可以更新的：

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - configMap:
          name: myconfigmap
          items:
            - key: config
              path: my-group/my-config

为了能够比较好得理解，先说明一下configMap的volume挂载机制：

Kubernetes Developement

Wed, 21 Apr 2021 11:22:18 +0800

资源模板

`statefulset`举例

apiVersion: apps/v1beta1
kind: StatefulSet
metadata: 
  name: kubia
spec:
  serviceName: kubia
  replicas: 2
  template:
    metadata:
      labels:
        app: kubia
    spec:
      containers:
      - name: kubia
        image: derios/kubia
        ports:
        - name: http
          containerPort: 8080
        volumeMounts:
        - name: data
          mountPath: /var/data
   volumeClaimTemplates:
   - metadata:
       name: data
     spec:
       resources:
         requests:
           storage: 1Mi
       accessModes:
       - ReadWriteOnce

`headless service`举例

apiVersion: v1
kind: Service
metadata:
  name: kubia
spec:
  clusterIP: None
  selector:
    app: kubia
  ports:
  - name: http
    port: 80

`storage class` local PV

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: local-test
spec:
  serviceName: "local-service"
  replicas: 3
  selector:
    matchLabels:
      app: local-test
  template:
    metadata:
      labels:
        app: local-test
    spec:
      containers:
      - name: test-container
        image: k8s.gcr.io/busybox
        command:
        - "/bin/sh"
        args:
        - "-c"
        - "sleep 100000"
        volumeMounts:
        - name: local-vol
          mountPath: /usr/test-pod
  volumeClaimTemplates:
  - metadata:
      name: local-vol
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "local-storage"
      resources:
        requests:
          storage: 368Gi

Key Point

使用Local PV的实际场景

使用本地磁盘作为缓存的系统
CI/CD中用于存储构建中的系统
一些允许丢失和不需要保证可靠的数据(session, token)

Local PV与HostPath的对比

hostpath:

Kubernetes Handbook (Schedule)

Fri, 09 Apr 2021 10:22:18 +0800

内容涵盖

使用节点污点和pod容忍度阻止pod调度到特定节点
将节点亲缘性规则作为节点选择器的一种替代
使用节点亲缘性进行多个pod的共同调度
使用节点非亲缘性来分离多个pod

高级调度

在pod介绍的文章中可以看到，k8s可以通过在pod spec里面指定节点选择器，而这篇文章介绍的是后面其他逐渐加入的机制。

使用污点和容忍度阻止节点调度到特定节点

新特性： 节点污点、pod对于污点的容忍度

这些特性用于限制哪些pod可以被调度到某一个节点，也就是说只有当一个pod容忍某个节点的污点，这个pod才能被调度到该节点。

节点选择器和节点亲缘性规则，是明确在pod中添加的信息，来觉得一个pod可以或者不可以被调度到某个节点。而污点不一样，是在不修改已有pod信息的前提下，通过在节点上新增污点信息，来拒绝pod在这个节点的部署。

简单介绍污点和容忍度

我在自己的机器用minikube创建了k8s单点集群，用kubectl describe node minikube可以看到:

k describe node minikube
Name:               minikube
Roles:              master
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    deploy=test
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=minikube
                    kubernetes.io/os=linux
                    minikube.k8s.io/commit=b09ee50ec047410326a85435f4d99026f9c4f5c4
                    minikube.k8s.io/name=minikube
                    minikube.k8s.io/updated_at=2021_03_30T20_15_58_0700
                    minikube.k8s.io/version=v1.14.0
                    node-role.kubernetes.io/master=
Annotations:        kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
                    node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Tue, 30 Mar 2021 20:15:55 +0800
Taints:             <none>                  # -----> 主节点暂时没有污点
Unschedulable:      false
Lease:
  HolderIdentity:  minikube
  AcquireTime:     <unset>
  RenewTime:       Fri, 09 Apr 2021 14:48:12 +0800

可以看到Taints属性，表示目前这个主节点没有污点。不过这里可以举个例子：

Docker Fundamentals: AUFS

Tue, 06 Apr 2021 11:22:18 +0800

AUFS是一种Union File System，所谓的UnionFS实际上就是把不同物理位置的目录合并mount到同一个目录当中。一种典型的UnionFS的应用，就是把一张CD/DVD和一个硬盘目录联合mount在一起，然后你就可以对这个只读的CD/DVD上的文件进行修改。

AUFS又叫做Another UnionFS，后面改成Alternative UnionFS，然后又变成Advance UnionFS…..当然名字的改变叫啥不重要，本质还是没变的。2006年Junjiro Okajima开发了AUFS，完全重写了早期的UnionFS 1.X，主要目的是为了可靠性和性能，再引入一些新的功能，例如可写分支的负载均衡。不过很有意思的是，AUFS的性能比UnionFS 1.X好很多，后面UnionFS 2.x就抄AUFS的功能，而AUFS本身却没有合入到Linux主线，因为代码量太大质量也不好。虽然后面Junjiro不断提升代码质量，不断提交但是还是被Linus拒绝了。所以哪怕是今天AUFS也没进到Linux里，虽然质量已经可以了。

不过一些发行版比如：Ubuntu 10.04，Debian6.0都支持AUFS，所以也还好。我在Ubuntu 14.04演示一下例子。

首先，我们建立两个水果和蔬菜的目录，在这个目录上放一些文件，水果里有苹果和番茄，蔬菜有胡萝卜和番茄:

$ tree
.
├── fruits
│   ├── apple
│   └── tomato
└── vegetables
    ├── carrots
    └── tomato

然后输入:

# 创建一个mount目录
$ mkdir mnt

# 把水果目录和蔬菜目录union mount到 ./mnt目录中
$ sudo mount -t aufs -o dirs=./fruits:./vegetables none ./mnt

#  查看./mnt目录
$ tree ./mnt
./mnt
├── apple
├── carrots
└── tomato

可以看到mnt目录下有三个文件，水果和蔬菜的目录被合并起来了。如果我们修改一下文件内容:

Docker Fundamentals: Cgroup

Mon, 05 Apr 2021 11:22:18 +0800

Linux Namespace的技术解决了环境隔离的问题，不过这是虚拟化最基本的一步，我们另外需要解决对计算机资源使用上的隔离。说人话，就是虽然Namespace把我关到一个特定的环境，但是里面进程使用的CPU、内存、磁盘等计算资源实际上没有被限制。这个问题的解决，就要用到CGroup技术。

Linux CGroup全称是Linux Control Group，也是其内核的一个功能，用于限制、控制和分离一个进程group的资源。最早这个项目是2006年由谷歌的工程师发起的，最开始名称是process containers（工程容器），后面觉得内核中容器这个名词被用烂了，就改名为cgroup。

CGroup可以让你对系统中运行的进程的用户组分配资源-CPU时间、系统内存、网络带宽亦或者是这些的组合。同时，也可以监控你配置的cgroup，拒绝cgroup访问某些资源。主要提供的功能如下：

Resource Limitation：限制资源使用
Prioritization: 优先级控制，例如CPU使用和磁盘IO吞吐
Accounting：审计统计，主要用于计费
Control：挂起进程，恢复执行进程

在真正的实践当中，system admin一般会利用CGroup做以下的事：
对进程集合进行隔离，限制他们所消费的资源，例如绑定CPU core
为这组进程分配足够使用的内存
为这组进程分配响应的网络带宽和磁盘存储限制
限制访问某些设备（白名单）

Linux实际上把CGroup实现成了一个文件系统，你可以mount。在linux环境输入下面的可以看到cgroup已经为你mount好：

derios@ubuntu:~$ mount -t cgroup
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu)
cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,relatime,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,relatime,blkio)
cgroup on /sys/fs/cgroup/net_prio type cgroup (rw,net_prio)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,net_cls)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,relatime,hugetlb)

可以看到，在/sys/fs下有cgroup目录，这个目录下面有各种子目录：cpu，cpuset，memory…。这些都是cgroup的子系统，分别用来干不同的事。

Docker Fundamentals: Namespace

Thu, 01 Apr 2021 11:22:18 +0800

容器技术出现已经很久，只不过Docker容器平台的出现它变火了。Docker是第一个让容器能在不同机器之间移植的系统，它简化了打包应用的流程，也简化了打包应用的库和各种依赖。思考下整个OS的file system能直接被打包成一个简单的可移植的包，一开始的时候概念上还是很有趣的。

有时候我认为自己的阅读比较碎片化(~~short-term memory越来越少~~)，所以我想把之前学习容器知识的一些基础技术再整理出来，也算是给自己学习的反馈。这个基础系列从Linux Namespace开始，后续会陆续介绍比如cgroup、aufs、devicemapper等技术。

参考

Namespace in operation

Linux namespace man page

Introduction to linux namespace

什么是Namespace

简单来说，linux namespace是Linux提供的一种内核级别环境隔离的方法。在早期的Unix中，提供了一种叫做chroot的系统调用：通过修改root目录把用户关到一个特定的目录下面。这种就是简单的隔离方式，也就是chroot内部的file system无法访问外部的内容。Linux Namespace在此基础之上，提供了对UTS、IPC、mount、network、PID、User等隔离机制。

这里可以简单举例，比如Linux的超级父进程的PID为1，如果我们可以把用户的进程空间关到某个进程分支之下，并且像chroot那样能够让下面的进程看到那个超级父进程的PID为1，而不同PID Namespace中的进程无法看到彼此，这样就能达到进程隔离。

Linux Namespace有以下的种类，供给后续参考（刚看有个印象就行）：

分类	系统调用参数	相关内核版本
Mount namespaces	CLONE_NEWNS	Linux 2.4.19
UTS namespaces	CLONE_NEWUTS	Linux 2.6.19
IPC namespaces	CLONE_NEWIPC	Linux 2.6.19
PID namespaces	CLONE_NEWPID	Linux 2.6.24
Network namespaces	CLONE_NEWNET	始于Linux 2.6.24 完成于 Linux 2.6.29
User namespaces	CLONE_NEWUSER	始于 Linux 2.6.23 完成于 Linux 3.8)

其主要涉及到三个系统调用：

clone()：实现线程的系统调用，用来创建新的线程，并可通过涉及上述参数做到隔离
unshare()：让某一个线程脱离某namespace
setns(): 把某一个线程加到某namespace

如果读者你想看具体的实例，请自己man一下(关注一下自己的linux虚拟机内核)，或者google一下，我这里贴一个clone()的source code：

Kubernetes Handbook (Start & Pod)

Wed, 31 Mar 2021 11:22:18 +0800

使用minikube构建本地单节点k8s集群

minikube ssh
kubectl cluster-info
kubectl get nodes #查看节点信息
kubectl describe node minikube #详细信息

多节点k8s集群，使用Google K8s Engine

构建方式看GKE官网即可

k8s初步使用

kubectl run kubia –image=derios/kubia –port=8080 –generator=run/v1

--image=derios/kubia代表要运行的容器镜像
这里的--generator会被废弃，其含义指代的是创建一个ReplicationController而不是Deployment。
kubectl apply -f 更常用
kubectl get pods
kubectl get pods -o wide 显示pod ip和pod的节点
如果使用GWE，可以访问集群的dashborad:
kubectl clusert-info获取地址
gcloud container clusters describe kubia | grep -E “(username|password):“获取用户名和密码
如果仅仅使用minikube，则如下不需要任何凭证即可访问:

`1`	`minikube dashboard`

Namespace相关操作

`1`	`kubectl config set-context --current --namespace=my-namespace`

创建服务对象，访问Web应用

如果使用minikube或者kubeadm等自定义k8s，loadbalancer是没有集成的，需要AWS或者Google Cloud。最好使用NodePort或者Ingress Controller。如果真要用minikube, 可以使用minikube tunnel解决, 或者minikube service kubia-http

Docker Cheat Sheet

Tue, 30 Mar 2021 11:22:18 +0800

Books

Docker in Action (English ver.)

Docker入门到实践(中文)

速查

Docker Cheat Sheet

全量CLI

容器管理CLI

查看容器CLI

容器交互CLI

镜像管理CLI

镜像传输CLI

DOCKERFILE主要命令

Dockerfile

基底

`1`	`FROM ruby:2.2.2`

变量

1
2

ENV APP_HOME/myapp
RUN mkdir $APP_HOME

初始化

`1`	`RUN bundle install`

`1`	`WORKDIR /myapp`

1
2

VOLUME ["/data"]
# Specification for mount point

1
2

ADD file.xyz /file.xyz
COPY --chown=user:group host_file.xyz /path/container_file.xyz

Onbuild

1
2

ONBUILD RUN bundle install
# when used with another file

命令

1
2

EXPOSE 5900
CMD ["bundle", "exec", "rails", "server"]

Entrypoint

`1`	`ENTRYPOINT exec top -b`

Metadata

`1`	`LABEL version="1.0"`

1
2

LABEL "com.example.vendor"="ACME Incorporated"
LABEL com.example.label-with-value="foo"

1
2

LABEL description="This text illustrates \
that label-values can span multiple lines."

Docker Compose

基本用法

# docker-compose.yml
version: '2'

services:
  web:
    build: .
    # build from Dockerfile
    context: ./Path
    dockerfile: Dockerfile
    ports:
     - "5000:5000"
    volumes:
     - .:/code
  redis:
    image: redis

指令

1
2

docker-compose start
docker-compose stop

1
2

docker-compose pause
docker-compose unpause

1
2
3

docker-compose ps
docker-compose up
docker-compose down

Reference(例子)

构建

1
2
3

web:
  # build from Dockerfile
  build: .

  # build from custom Dockerfile
  build:
    context: ./dir
    dockerfile: Dockerfile.dev

 # build from image
  image: ubuntu
  image: ubuntu:14.04
  image: tutum/influxdb
  image: example-registry:4000/postgresql
  image: a4bc65fd

端口

1
2
3

  ports:
    - "3000"
    - "8000:80"  # guest:host

1
2

  # expose ports to linked services (not to host)
  expose: ["3000"]

指令

1
2
3

  # command to execute
  command: bundle exec thin -p 3000
  command: [bundle, exec, thin, -p, 3000]

1
2
3

  # override the entrypoint
  entrypoint: /app/start.sh
  entrypoint: [php, -d, vendor/bin/phpunit]

环境变量

  # environment vars
  environment:
    RACK_ENV: development
  environment:
    - RACK_ENV=development

1
2
3

  # environment vars from file
  env_file: .env
  env_file: [.env, .development.env]

依赖

  # makes the `db` service available as the hostname `database`
  # (implies depends_on)
  links:
    - db:database
    - redis

1
2
3

  # make sure `db` is alive before starting
  depends_on:
    - db

其他选项

  # make this service extend another
  extends:
    file: common.yml  # optional
    service: webapp

1
2
3

  volumes:
    - /var/lib/mysql
    - ./_data:/var/lib/mysql

高级特性

打标签

services:
  web:
    labels:
      com.example.description: "Accounting web app"

DNS服务器

services:
  web:
    dns: 8.8.8.8
    dns:
      - 8.8.8.8
      - 8.8.4.4

设备绑定

services:
  web:
    devices:
    - "/dev/ttyUSB0:/dev/ttyUSB0"

外部链接

services:
  web:
    external_links:
      - redis_1
      - project_db_1:mysql

主机设置

services:
  web:
    extra_hosts:
      - "somehost:192.168.1.100"

Services

# To view list of all the services runnning in swarm
docker service ls 

# To see all running services
docker stack services stack_name

# to see all services logs
docker service logs stack_name service_name 

# To scale services quickly across qualified node
docker service scale stack_name_service_name=replicas

Clean up

# To clean or prune unused (dangling) images
docker image prune 

# To remove all images which are not in use containers , add - a
docker image prune -a 

# To Purne your entire system
docker system prune 

# To leave swarm
docker swarm leave

# To remove swarm ( deletes all volume data and database info)
docker stack rm stack_name 

# To kill all running containers
docker kill $(docekr ps -q )

Kubernetes & Docker on CctoctoFX

Kubernetes Operator Development History

Third-Parties

client-go源码分析

目录结构

代码实例

Kubernetes ConfigMap 热更新

场景一： 针对可以进行热更新的容器，进行配置热更新

Kubernetes Developement

资源模板

statefulset举例

headless service举例

storage class local PV

Key Point

使用Local PV的实际场景

Local PV与HostPath的对比

Kubernetes Handbook (Schedule)

内容涵盖

高级调度

使用污点和容忍度阻止节点调度到特定节点

简单介绍污点和容忍度

Docker Fundamentals: AUFS

Docker Fundamentals: Cgroup

Docker Fundamentals: Namespace

参考

什么是Namespace

Kubernetes Handbook (Start & Pod)

使用minikube构建本地单节点k8s集群

多节点k8s集群，使用Google K8s Engine

k8s初步使用

Namespace相关操作

创建服务对象，访问Web应用

Docker Cheat Sheet

Books

速查

全量CLI

容器管理CLI

查看容器CLI

容器交互CLI

镜像管理CLI

镜像传输CLI

DOCKERFILE主要命令

Dockerfile

基底

变量

初始化

Onbuild

命令

Entrypoint

Metadata

Docker Compose

基本用法

指令

Reference(例子)

构建

端口

指令

环境变量

依赖

其他选项

高级特性

打标签

DNS服务器

设备绑定

外部链接

主机设置

Services

Clean up

`client-go`源码分析

场景一：针对可以进行热更新的容器，进行配置热更新

`statefulset`举例

`headless service`举例

`storage class` local PV