K8S应用流程安全（镜像安全 配置管理 访问安全）
应用流程安全
- 1 应用流程安全
-
- 1.1 镜像安全
-
- 1.1.1 构建原则
- 1.1.2 Dockerfile实践
- 1.1.3 构建进阶
- 1.1.4 镜像检测
- 1.1.5 仓库升级
- 1.1.6 高可用仓库
- 1.1.7 镜像策略
- 1.2 配置管理
-
- 1.2.1 配置基础
- 1.2.2 YAML安全
- 1.2.3 kustomize
- 1.2.4 基础实践
- 1.2.5 功能复用
- 1.2.6 配置定制
- 1.2.7 补丁实践
- 1.3 访问安全
-
- 1.3.1 安全检测
- 1.3.3 简单实践
- 1.3.3 虚拟主机
- 1.3.4 四层实践
- 1.3.5 策略实践
1 应用流程安全
1.1 镜像安全
1.1.1 构建原则
学习目标
这一节，我们从 基础知识、原则解读、小结 三个方面来学习。
基础知识
k8s平台使用业务环境
生产中使用k8s操作业务环境的基本原则
1 保证容器应用是正常运行的
2 创建专属的资源对象文件
3 基于资源对象文件创建业务环境
4 测试业务环境，如果不满足则进行后续动作，否则不做任何改变
- 调整容器的镜像文件
- 重新调整资源对象文件
- 基于新资源对象文件创建并测试新的环境
需求
镜像是容器运行的基础，容器引擎服务可使用不同的镜像启动相应的容器。在容器出现错误后，能迅速通过 删除容器、启动新的容器来恢复服务，这都需要以容器镜像作为支撑技术。
而Kubernetes作为一种容器任务编排平台，它对于应用的管理都是基于镜像文件创建出来的。
镜像的使用流程
Docker镜像加载
对于Docker镜像文件整体来说，它是一个只读的文件，但是根据我们对构建过程的理解，我们发现，对于Docker镜像还有很多更深层的东西：
1 镜像文件是基于分层机制实现的
- Docker 镜像的最底层是 bootfs(boot file system), bootfs主要包含 bootloader 和 Kernel ， bootloader加载kernel信息到内存中，然后内存使用权交给内核，接着内核卸载bootfs。
- 在 bootfs之上是rootfs(root file system)，它包含了不同Linux发行版(Ubuntu|Centos)文件系统中的标准目录和文件，比如/dev,/proc,/bin,/etc等。它由内核挂载为只读模式，而后通过"联合挂载"在其基础上挂载一个"可写层"。
2 下层镜像是上层镜像的父镜像，最底层的称为基础镜像
- 最上层的是可写的，其他各层都是只读的。
总的来说，镜像文件包含运行某个应用软件所需的所有内容，包括代码、运行时、库、环境变量和配置文件。
UnionFS
UnionFS(联合文件系统)：Union文件系统是一种分层、轻量级并且高性能的文件系统，它支持对文件系统的修改作为一次提交来一层层的叠加，同时可以将存在不同物理位置的不同目录挂载到同一个虚拟文件系统下，从外面看起来，只能看到一个包含所有底层的文件和目录的文件系统。UnionFS可以把只读和可读写文件系统合并在一起，具有写时复制功能，允许只读文件系统的修改可以保存到可写文件系统当中。
Union文件系统是 Docker 镜像的基础。镜像可以通过分层来进行继承，基于基础镜像（没有父镜像），可以制作各种具体的应用镜像。
Docker镜像使用分层最大的好处就是 共享资源。许多镜像基于相同的base镜像构建而来，宿主机只需在磁盘上保存一份base镜像，同时内存中也只需加载一份base镜像，就可以为所有容器服务了，而且镜像的每一层都可以被共享。
原则解读
构建样式
我们将中间只读的 rootfs 的集合称为 Docker 镜像，Docker 镜像构建时，会一层层构建，前一层是后一层的基础。每一层构建完就不会再发生改变，后一层上的任何改变只发生在自己这一层。UnionFS 使得镜像的复用、定制变得更为容易。甚至可以用之前构建好的镜像作为基础层，然后进一步添加新的层，以定制自己所需的内容，构建新的镜像。
当用docker run启动这个容器时，实际上在镜像的顶部添加了一个新的可写层。这个可写层也叫容器层。容器启动后，其内的应用所有对容器的改动，文件的增删改操作都只会发生在容器层中，根据容器镜像的写时拷贝(Copy-on-Write)技术，某个容器对基础镜像的修改会被限制在单个容器内,对容器层下面的所有只读镜像层没有影响。
构建原则
1、镜像最小化原则；需要选择最精简的基础镜像、清理镜像构建的中间产物、减少镜像的层数。
2、构建速度最快化原则；充分利用镜像构建缓存，再利用构建的缓存来加快镜像构建速度。
3、注意优化网络请求。
实践原则
镜像构建实践的最佳实践原则
1 按照项目功能定制镜像构建目录结构
2 按照角色定制不同镜像
3 基于嵌套方式分层构建镜像
分层效果
功能效果
小结
1.1.2 Dockerfile实践
学习目标
这一节，我们从 基础知识、简单实践、小结 三个方面来学习。
基础知识
镜像构建过程
1）从基础镜像1创建一个容器A
2）遇到一条Dockerfile指令，都对容器A做一次修改操作
3）执行完一条指令，提交生成一个新镜像2
4）再基于新的镜像2运行一个容器B
5）遇到一条Dockerfile指令，都对容器B做一次修改操作
6）执行完一条指令，提交生成一个新镜像3
...
Dockerfile
在工作中，我们经常会因为业务需求，而定制各种各样的Doker镜像，由于Dockerfile的便捷性，所以我们经常会基于Dockerfile来创建我们业务场景中所需要的各种镜像。
根据我自己的工作经验，我们在使用Dockerfile的过程中，一般只需要关注三个方面即可：
1 Dockerfile在使用的过程中，构建的指令越少越好，能合并的就合并。
2 基于Docker镜像的分层特性，我们最好按照项目的架构级别来定制不同层的镜像
3 Dockerfile构建的过程中，功能越简单越好，最好只有一个
简单实践
准备工作
创建Dockerfile专用目录
mkdir /docker/images/ssh -p
cd /docker/images/ssh
创建秘钥认证
ssh-keygen -t rsa
cat ~/.ssh/id_rsa.pub > authorized_keys
最初的Dockerfile
# 构建一个基于ubuntu的ssh定制镜像
# 基础镜像
FROM ubuntu
# 镜像作者
MAINTAINER shuji@superopsmsb.com
# 安装 ssh 服务
RUN apt-get update
RUN apt-get install -y openssh-server curl vim net-tools git dnsutils jq
RUN mkdir -p /var/run/sshd
RUN mkdir -p /root/.ssh
RUN sed -i "s/.*pam_loginuid.so/#&/" /etc/pam.d/sshd
RUN apt-get autoclean
RUN apt-get clean
RUN apt-get autoremove
# 复制配置文件到相应位置,并赋予脚本可执行权限
ADD authorized_keys /root/.ssh/authorized_keys
# 对外端口
EXPOSE 22
# 启动ssh
CMD ["/usr/sbin/sshd","-D"]
优化后Dockerfile
# 构建一个基于ubuntu的ssh定制镜像
# 基础镜像
FROM ubuntu
# 镜像作者
MAINTAINER shuji@superopsmsb.com
# 安装 ssh 服务
RUN apt-get update && apt-get install -y openssh-server curl vim net-tools git dnsutils jq && mkdir -p /var/run/sshd && mkdir -p /root/.ssh && sed -i "s/.*pam_loginuid.so/#&/" /etc/pam.d/sshd && apt-get autoclean && apt-get clean && apt-get autoremove
# 复制配置文件到相应位置,并赋予脚本可执行权限
ADD authorized_keys /root/.ssh/authorized_keys
# 对外端口
EXPOSE 22
# 启动ssh
CMD ["/usr/sbin/sshd","-D"]
小结
1.1.3 构建进阶
学习目标
这一节，我们从 多阶段构建、触发器、小结 三个方面来学习。
多阶段构建
需求
对于一些大型微服务项目的研发来说，研发阶段会是多个团队来进行项目的研发，如果每个研发人员都是基于使用Docker容器来做项目的部署，这个时候后，因为几个项目组件可能包含公用文件,从而导致大量的Docker镜像使用的重复冗余资源,所以我们有必要为团队的提供一个更加丰富的Base镜像，以满足所有研发人员的需求的前提下，极大的节省资源的消耗。
多阶段构建
旧版本的Docker软件仅仅支持1个FROM，从1.17版本之后开始支持多阶段构建的能力 -- 也就是说多个FROM指令，也就是说我们可以使用多个base image和中间层image来构建镜像层。这里主要用到的指令是 FROM 和 AS。也就是说，它可以让我在前一个image层上创建多个image层，
示例：
FROM image as layer_name
同时Dockerfile在构建的时候，可以借助于COPY 指令的 --from 参数，docker镜像中直接获取相关文件：
COPY --from=0 /require/file /dest/
从前一个镜像层中获取文件到当前镜像层面指定位置
COPY --from=layer_name /require/file /dest/
从前指定镜像层中获取文件到当前镜像层面指定位置
COPY --from=docker.io/nginx /require/file /dest/
从前现有的镜像中获取文件到当前镜像层面指定位置
构建实践
# 基于基础镜像构建普通功能软件，将其作为ubuntu环境使用
FROM python:3 AS base
MAINTAINER shuji@superopsmsb.com
RUN apt-get update && apt-get install -y vim
# 创建一个专属的镜像层来安装Python依赖软件
FROM base AS requirements
RUN pip3 install django==3.1.2
# 使用Python镜像层创建专属的项目环境
FROM requirements as django
ADD blog /data/code/blog
ADD scripts/startup.sh /data/scripts/startup.sh
EXPOSE 8000
# 定制容器的启动命令
CMD ["/bin/bash", "/data/scripts/startup.sh"]
构建镜像
docker build -t simple-test .
测试效果
docker run -d --name django-test -p 666:8000 simple-test
curl localhost:666
docker rm -f django-test
结果显示：
我们使用FROM和AS指令组合帮助我们为所有项目创建唯一的层次结构。从而让我们一次完成所有任务docker文件，这样不仅简化了版本管理, 还可以更好地了解整个项目, 尤其是通过消除在不同镜像中的相同文件，并实现了最终镜像文件容量缩容。
触发器
需求
工作中我们在做大量Docker镜像的时候，因为分层的优势，我们一般先把基础镜像做出来，然后在它的基础上进行上层镜像的构建。结合我们刚才的实践，如果将多个团队需求的文件都进行初始化构建的话，导致基础镜像容量太大，而且很多功能对于上层镜像无用。
所以我们就可以借助于触发器的能力，提前将上层镜像需要的环境定制出来，但是不执行，只有当上层镜像需要的时候，我们再进行针对性环境的构建，这样可以让我们的容量更加高效。
指令
Dockerfile 用于 build 镜像文件，A镜像和B镜像分别需要不同的Dockerfile文件来进行构建，如果B镜像依赖于A镜像，我们可以借助于ONBUILD指令，在构建B镜像的时候，自动触发A镜像内部的构建步骤，当A镜像构建完毕后，再开始B镜像构建。
构建实践
定制两个目录
mkdir father child
定制father项目的Dockerfile文件
FROM python:3
MAINTAINER father-image
RUN echo "father image"
ONBUILD RUN echo "child image"
定制child项目的Dockerfile文件
FROM father-image
MAINTAINER child-image
RUN echo "this is my cmd"
构建父级镜像
# docker build -t father-image father/
Sending build context to Docker daemon 2.048kB
Step 1/4 : FROM python:3
---> f05c8762fe15
Step 2/4 : MAINTAINER father-image
---> Running in 90bb60b129c3
Removing intermediate container 90bb60b129c3
---> 39be4d0f1254
Step 3/4 : RUN echo "father image"
---> Running in 1ec695c98bfb
father image
Removing intermediate container 1ec695c98bfb
---> dcde17f6a0dc
Step 4/4 : ONBUILD RUN echo "child image"
---> Running in c41f441091a7
Removing intermediate container c41f441091a7 # 结果显示：命令没有执行
---> 5dcb262c76e6
Successfully built 5dcb262c76e6
Successfully tagged father-image:latest
构建子镜像
# docker build -t child-image child/
Sending build context to Docker daemon 2.048kB
Step 1/3 : FROM father-image
# Executing 1 build trigger
---> Running in 3e26148923b1
child image # 结果显示：子镜像构建的时候，自动执行父镜像的
Removing intermediate container 3e26148923b1
---> ccbcc3569240
Step 2/3 : MAINTAINER child-image
---> Running in a622eba55824
Removing intermediate container a622eba55824
---> bbaee5a9ea61
Step 3/3 : RUN echo "this is my cmd"
---> Running in ee716a0392aa
this is my cmd
Removing intermediate container ee716a0392aa
---> 229bcbf7c314
Successfully built 229bcbf7c314
Successfully tagged child-image:latest
小结
1.1.4 镜像检测
学习目标
这一节，我们从 基础知识、简单实践、小结 三个方面来学习。
基础知识
需求
在基于kubernetes平台上的云原生应用，基本上都是基于Docker镜像的方式来运行起来的，如果镜像的来源就是有问题的，那么我们建立该环境上的应用就会存在所谓0day的现象。虽然可以通过Dockerfile的方式来控制镜像的构建过程，但是这只是我们能够控制的一部分，还有大量第三方应用的镜像我们无法进行强有力的安全控制，如果第三方的平台镜像存在安全漏洞，我们是无法处理的。
在互联网中有很多组织和社区，为了实现某些场景的镜像安全，自发或者其他因素影响下，开始从事镜像安全漏洞的工作，他们研发了一系列镜像级别的安全检测工具，可以帮助我们进行镜像安全的控制，Trivy就是其中的佼佼者。
根据2022年<>的统计数据显示：在生产环境中运行的 85% 的镜像至少包含一个可修补漏洞。此外，75% 的镜像包含“高危”或“严重”的可修补漏洞。使用公共仓库可能会带来风险，因为它们很少会被验证或检查漏洞。但是在某些情况下，使用公共库的便利性大于风险，所以很多企业宁可面对风险也要用公共镜像仓库，并且将其作为最佳实践。
trivy
Trivy是一个简单而全面的漏洞/错误配置扫描器，常被应用于容器级别的业务安全场景。它主要的工作对象是 容器镜像、文件系统、Git存储库等。
Trivy提供了大量用于检测操作系统和程序语言的检测工具包。它无论是部署还是使用都是非常简单的。尤其是它对于其他平台环境的集成非常轻松，常常应用在以DevSecOps为代表的CI环境中。
官方网站：https://trivy.dev/
github: https://github.com/aquasecurity/trivy
最新版本: 0.32.1
软件部署
Centos定制软件源
# vim /etc/yum.repos.d/trivy.repo
[trivy]
name=Trivy repository
baseurl=https://aquasecurity.github.io/trivy-repo/rpm/releases/$releasever/$basearch/
gpgcheck=0
enabled=1
安装软件
yum makecache fast
yum -y install trivy
Ubuntu定制软件源
apt-get install wget apt-transport-https gnupg lsb-release
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main | sudo tee -a /etc/apt/sources.list.d/trivy.list
安装软件
apt-get update
apt-get -y install trivy
简单实践
命令解析
镜像扫描
trivy image [YOUR_IMAGE_NAME]
漏洞检测
trivy image --severity HIGH,CRITICAL [YOUR_IMAGE_NAME]
信息输出
trivy image -f json -o results.json [YOUR_IMAGE_NAME]
仓库检测
trivy repo https://github.com/knqyf263/trivy-ci-test
容器内检测
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin
trivy fs /
简单实践
下载漏洞数据库
trivy image --download-db-only
清理检测缓存
trivy image --clear-cache
清理所有检测数据库
trivy image --reset
镜像检测
trivy image nginx:latest
注意
在title部分有该漏洞的一些信息https://avd.aquasec.com/nvd/2011/cve-2011-3374/
CVSS:Common Vulnerability Scoring System，即通用漏洞评分系统，是一个行业公开标准，其被设计用来评测漏洞的严重程度，并帮助确定所需反应的紧急度和重要度。
指定检测级别测试
trivy image --severity HIGH,CRITICAL nginx:latest
文件系统扫描
trivy fs /tmp/
仓库扫描
trivy repo https://github.com/kubernetes/kubernetes.git
信息输出
trivy image -f json -o results.json nginx:latest
harbor实践
我们可以在harbor部署的时候，指定一个参数来启用trivy能力。
./install.sh --with-trivy
这样的话，我们的镜像后面就会多出检测的能力条，只需要我们配置检测的规则，它就会自动检测
小结
1.1.5 仓库升级
学习目标
这一节，我们从 基础知识、简单实践、小结 三个方面来学习。
基础知识
需求
对于docker镜像仓库来说，默认使用的级别是https的，如果是非https的话，需要将其设置到一个非安全的仓库范围中，无论是对于containerd还是docker来说，这都不是一个很好的现象。
harbor本身是支持https能力的，我们只需要按部就班的实施就可以了。
修改harbor配置
修改配置 /data/server/harbor/harbor.yml
...
hostname: kubernetes-register.superopsmsb.com
http:
port: 80
https: 注释ssl相关的部分
port: 443
certificate: /data/server/harbor/certs/kubernetes-register.superopsmsb.com/kubernetes-register.superopsmsb.com.crt
private_key: /data/server/harbor/certs/kubernetes-register.superopsmsb.com/kubernetes-register.superopsmsb.com.key
harbor_admin_password: 123456
data_volume: /data/harbor/data
准备证书信息
生成CA证书私钥
mkdir -p /data/server/harbor/ssl
cd /data/server/harbor/ssl
openssl genrsa -out ca.key 4096
生成CA证书
openssl req -x509 -new -nodes -sha512 -days 3650 \
-subj "/C=CN/ST=Beijing/L=Beijing/O=example/OU=Personal/CN=kubernetes-register.superopsmsb.com" \
-key ca.key \
-out ca.crt
注意：如果使用IP地址，需要在执行以上命令前执行以下操作：
cd /root
openssl rand -writerand .rnd
cd -
生成服务器证书私钥
openssl genrsa -out kubernetes-register.superopsmsb.com.key 4096
生成证书签名请求（CSR）
openssl req -sha512 -new \
-subj "/C=CN/ST=Beijing/L=Beijing/O=example/OU=Personal/CN=kubernetes-register.superopsmsb.com" \
-key kubernetes-register.superopsmsb.com.key \
-out kubernetes-register.superopsmsb.com.csr
生成一个x509 v3扩展文件
无论您使用FQDN还是IP地址连接到Harbor主机，都必须创建此文件，以便可以为您的Harbor主机生成符合主题备用名称（SAN）和x509 v3的证书扩展要求。替换DNS条目以反映您的域。
cat > v3.ext <<-EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1=kubernetes-register.superopsmsb.com
DNS.2=kubernetes-register.superopsmsb
DNS.3=kubernetes-register
EOF
使用该v3.ext文件为您的Harbor主机生成证书
openssl x509 -req -sha512 -days 3650 \
-extfile v3.ext \
-CA ca.crt -CAkey ca.key -CAcreateserial \
-in kubernetes-register.superopsmsb.com.csr \
-out kubernetes-register.superopsmsb.com.crt
提供证书给harbor和docker
将服务器证书和密钥复制到Harbor主机上的certficates文件夹中
mkdir /data/server/harbor/certs/kubernetes-register.superopsmsb.com -p
cp kubernetes-register.superopsmsb.com.crt /data/server/harbor/certs/kubernetes-register.superopsmsb.com/
cp kubernetes-register.superopsmsb.com.key /data/server/harbor/certs/kubernetes-register.superopsmsb.com/
Docker守护程序将.crt文件解释为CA证书，并将.cert文件解释为客户端证书
openssl x509 -inform PEM -in kubernetes-register.superopsmsb.com.crt -out kubernetes-register.superopsmsb.com.cert
将服务器证书，密钥和CA文件复制到Harbor主机上的Docker证书文件夹中。您必须首先创建适当的文件夹
mkdir -p /etc/docker/certs.d/kubernetes-register.superopsmsb.com/
cp kubernetes-register.superopsmsb.com.cert /etc/docker/certs.d/kubernetes-register.superopsmsb.com/
cp kubernetes-register.superopsmsb.com.key /etc/docker/certs.d/kubernetes-register.superopsmsb.com/
cp ca.crt /etc/docker/certs.d/kubernetes-register.superopsmsb.com/
注意：
如果将默认nginx端口443映射到其他端口，请创建文件夹
/etc/docker/certs.d/yourdomain.com:port
或/etc/docker/certs.d/harbor_IP:port
这一步，对于新版的docker来说可以省略，即使不做这一步，影响不大。
重新启动Docker Engine
systemctl restart docker
harbor启动
进入工作目录
cd /data/server/harbor
重新应用harbor配置
./prepare
./install.sh
检查效果
docker-compose ps
简单实践
浏览器测试
修改windows的hosts文件 C:\Windows\System32\drivers\etc\hosts
10.0.0.20 kubernetes-register.superopsmsb.com
浏览器访问 https://kubernetes-register.superopsmsb.com
这个时候，就会使用https方式了，如果需要让浏览器不提示不安全，需要下载ca.crt到本地电脑安装证书，在Windows环境下双击，安装选择受信任的根证书即可。
docker测试
删除之前的docker认证信息
rm -f /root/.docker/config.json
修改docker的私服配置 /etc/docker/daemon.json
"insecure-registries": ["kubernetes-register.superopsmsb.com"],
重启docker服务
systemctl restart docker
测试效果
docker login https://kubernetes-register.superopsmsb.com
小结
1.1.6 高可用仓库
学习目标
这一节，我们从 基础知识、简单实践、小结 三个方面来学习。
基础知识
需求
docker镜像很重要，如果harbor仓库存在单点现象的话，会导致所有镜像无法在项目更新的时候进行使用。所以，我们有必要对于harbor进行高可用环境的定制。
Harbor 提供了很好的性能和安全, 它支持安装在多个 Registry 节点的镜像资源复制，从而实现镜像数据的一致性需求，比较适合于负载均衡、高可用、混合云和多云的场景。
方案
我们选择的高可用方案是比较简单的Harbor的双主复制，搭建两个Harbor节点，节点之间能够互相复制，然后通过haproxy代理Harbor节点提供外部访问。
高可用节点
- 10.0.0.18|19
- keepalived+haproxy
harbor节点
- 10.0.0.20|21
- harbor
注意:
基于离线安装包安装的高可用方案需要保证以下文件在多个实例之间的一致性。同时，由于这些文件是在各个 Harbor 实例的安装过程中默认生成的，所以需要用户手动复制这些文件来保证一致性。
再一个Harbor主要是给公司内部的开发人员使用的，由于业务使用量不是那么大，所以我们对于数据的一致性能够保证分钟级别也就可以了。
从节点部署
我们在 10.0.0.21节点上部署harbor
参考 前一节的 仓库升级内容，关于证书相关的信息使用复制即可。
注意：
修改两个harbor节点的hostname为 各自的ip地址
然后执行 ./prepare 和 ./install.sh
如果需要启动时候，添加镜像检测功能，我们可以使用如下命令
./install.sh --with-trivy
keepalived配置
主keepalived配置
vrrp_instance VI_2 {
state MASTER
interface eth0
virtual_router_id 52
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.0.0.201 dev eth0 label eth0:2
}
}
从keepalived配置
vrrp_instance VI_2 {
state BACKUP
interface eth0
virtual_router_id 52
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.0.0.201 dev eth0 label eth0:2
}
}
重启keepalived
systemctl restart keepalived
haproxy配置
修改haproxy的配置文件
listen harbor-80
bind 10.0.0.201:80
mode tcp
server harbor1 10.0.0.20:80 check inter 3s fall 3 rise 5
server harbor2 10.0.0.21:80 check inter 3s fall 3 rise 5
简单实践
配置主从
我们暂时访问 http://10.0.0.20，登陆配置一个主从角色，将20相关的配置同步到21主机。点击仓库管理后，创建harbor从角色的信息：
目标名：可以随意定义
目标url: 是从harbor节点的http链接地址
访问id: admin
访问密码: 123456
注意：当我们点击确定后，就会出现图中下面的仓库列表样式
点击复制管理后，创建主从同步规则信息：
名称和描述：自定义
资源过滤器：定制同步仓库即可
目标仓库：从列表中选择即可
触发模式：选择手动模式
注意：当我们点击确定后，就会出现图中下面的规则列表样式
触发复制并验证结果
1 勾选复制规则
2 点击复制
3 确认复制
4 查看复制任务
harbor2确认复制效果
测试效果
对于master节点来说，我们只需要修改/etc/hosts 文件的主机名解析记录即可
10.0.0.201 kubernetes-register.superopsmsb.com kubernetes-register
小结
1.1.7 镜像策略
学习目标
这一节，我们从 基础知识、简单实践、小结 三个方面来学习。
基础知识
简介
Kubernetes 对 API 访问提供了三种安全访问控制措施：认证、授权和 Admission Control。认证解决用户合法性的问题，授权解决用户能做什么的问题，Admission Control 则是资源管理方面的作用。通过合规的用户、合理的权限管理以及合适的准入控制机制，能够保证系统的安全可靠。
注意：关于插件化的准入控制是1.9版本之后的能力，之前是需要编译才可以实现。
k8s在很多方面都具备可扩展性，比如通过cni实现多种网络模型，通过csi实现多种存储引擎，通过cri实现多种容器运行时等等。而AdmissionWebhook就是准入层面的一种可扩展的手段。 它可以已默认的Admission插件外，还有自定义的Admission插件，在api-server运行时指定资源对象的时候，通过webhook进行操作的请求控制。
Admission webhooks是基于HTTP回调机制运行的，当它接收Admission请求并对它们做一些事情的时候。Admission webhook对k8s的请求资源对象进行深层次准入控制，Admission webhook有两种控制机制，MutatingAdmissionWebhook(对请求对象的修改)和ValidatingAdmissionWebhook(对请求的合法性进行检查)。
webhook解析
Admission Webhook 本质是 api-server 的一个 webhook 调用，下面是 api-server 的处理流程：
api-server 通过读取 mutatingwebhookconfiguration 和 validatingwebhookconfiguration 的 CRD 文件的目标地址，然后回调用户自定义的服务。
参考资料：
https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/
部署注意事项
1 webhook 的本质是 http server，因此，需要用代码实现这么一个 server，供 apiserver 调用
2 mutating webhook 和 validating webhook 没有直接联系，分别实现了不同的功能，本质上说，如果修改/验证都需要，我们需要编写两个 http server
3 编写好的 webhook，建议使用 k8s deployment 部署，同时使用 service 来暴露能力
4 apiserver 通过MutatingWebhookConfiguration/ValidatingWebhookConfiguration 调用 webhook
5 apiserver 和 webhook 通信时的身份认证和权限控制必须合理控制
案例需求
ImagePolicyWebhook是专门用于镜像获取的准入控制器策略，它主要通过验证镜像字段来判断，资源在创建时候是否满足创建的条件。我们可以在k8s的资源对象创建的时候，保证镜像来源仓库的可靠。但是该实践需要配置涉及到的很多文档内容，包括认证、配置、环境等。
参考资料：
https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#configuration-file-format
操作步骤
1 准备https专用的证书文件
2 构建webhook服务器
3 kubernetes集成镜像webhook服务
4 综合测试
5 收尾动作
简单实践
准备https专用的证书文件
准备证书工具环境
mkdir /data/kubernetes/process_secure/ ; cd /data/kubernetes/process_secure/
for i in cfssl cfssljson
do
wget https://github.com/cloudflare/cfssl/releases/download/v1.6.1/$i_1.6.1_linux_amd64
chmod +x $i_1.6.1_linux_amd64
cp $i_1.6.1_linux_amd64 /usr/local/bin/$i
done
准备专用证书目录
mkdir /data/kubernetes/process_secure/cert -p
cd /data/kubernetes/process_secure/cert/
准备CA配置信息，参考 cfssl print-defaults config 命令
cat > ca-config.json <{
"signing": {
"default": {
"expiry": "87600h"
},
"profiles": {
"kubernetes": {
"expiry": "87600h",
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
]
}
}
}
}
EOF
准备签名请求信息参考 cfssl print-defaults csr 命令
cat > ca-csr.json <{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "Beijing",
"ST": "Beijing"
}
]
}
EOF
准备image专属的webhook请求信息
cat > webhook-csr.json <{
"CN": "webhook",
"hosts": [
"10.0.0.12",
"10.0.0.13",
"10.0.0.14",
"127.0.0.1"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "BeiJing",
"ST": "BeiJing"
}
]
}
EOF
准备webhook和apiserver的认证信息
cat > apiserver-client-csr.json <{
"CN": "apiserver",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "BeiJing",
"ST": "BeiJing"
}
]
}
EOF
生成私钥和证书
cfssl gencert -initca ca-csr.json | cfssljson -bare ca -
生成webhook证书
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes webhook-csr.json | cfssljson -bare webhook
生成apiserver证书
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes apiserver-client-csr.json | cfssljson -bare apiserver-client
构建webhook服务器
定制镜像专属目录结构
mkdir /data/images/web/flask/conf
cd /data/images/web/flask
定制webhook的核心代码(Flask) main.conf
from flask import Flask,request
import json
# 创建app应用
app = Flask(__name__)
# 定制测试url
@app.route("/index")
def index():
return "flask web ok\n"
@app.route('/image_check', methods=['POST'])
def image_policy():
# 获取用户提交数据并进行数据反序列化
post_data = request.get_data().decode()
print("--- POST数据: {}".format(post_data))
data = json.loads(post_data)
# 定制容器镜像格式的检测规则 -- 必须携带标签
for container in data['spec']['containers']:
if ":" not in container['image'] or ":latest" in container['image']:
msg="镜像格式检测失败! 镜像名称必须携带标签，同时禁用默认标签."
allowed, reason = False, msg
break
else:
msg="镜像格式检测成功!"
allowed, reason = True, msg
print("--- 检查结果: {}".format(reason))
# 定制返回信息
obj_api=data['apiVersion']
obj_kind=data['kind']
obj_image=data['spec']['containers'][0]['image']
result = {"apiVersion": obj_api, "kind": obj_kind, "image_name": obj_image , "status": {"allowed": allowed, "reason": reason}}
print("--- 响应数据: {}".format(result))
# 对响应数据进行序列化操作，ensure_ascii=False，表示返回信息包含中文
return json.dumps(result, ensure_ascii=False)
if __name__ == "__main__":
app.run(host="0.0.0.0", port=8080, ssl_context=('/data/server/image_check/webhook.pem', '/data/server/image_check/webhook-key.pem'))
定制专属的Dockerfile文件
# 构建一个基于flask的定制镜像
# 基础镜像
FROM kubernetes-register.superopsmsb.com/superopsmsb/python
# 镜像作者
MAINTAINER shuji@superopsmsb.com
# 拷贝文件
ADD conf/main.py /data/server/image_check/main.py
# 创建flask环境
RUN pip install flask && useradd python && chown -R python /data
# 暴露django端口
EXPOSE 8080
USER python
# 定制容器的启动命令
CMD ["python", "/data/server/image_check/main.py"]
注意：
这里使用普通用户主要后期运行时候的缓存信息及时显示的原因
定制镜像文件
docker build -t kubernetes-register.superopsmsb.com/superopsmsb/image-webhook:v0.1 .
在生成证书的节点上运行镜像文件
export cert_dir='/data/kubernetes/process_secure/cert/'
export cont_dir='/data/server/image_check'
docker run -d --name=image-webhook -u root -e PYTHONUNBUFFERED=1 -v $cert_dir/webhook.pem:$cont_dir/webhook.pem -v $cert_dir/webhook-key.pem:$cont_dir/webhook-key.pem -p 8080:8080 kubernetes-register.superopsmsb.com/superopsmsb/image-webhook:v0.1
注意：
-u root -e PYTHONUNBUFFERED=1 的作用是将请求相关的数据即时输出
检查效果
]# docker ps | grep image
77bf356ce83e kubernetes-register.superopsmsb.com/superopsmsb/image-webhook:v0.1 "python /data/server…" 9 seconds ago Up 9 seconds 0.0.0.0:8080->8080/tcp, :::8080->8080/tcp image-webhook
]# curl -k https://10.0.0.12:8080/index
flask web ok
结果显示：
webhook服务器已经部署完毕了
kubernetes集成镜像webhook服务
检查kubernetes集群是否启用了准入注册 API
]# kubectl api-versions |grep admission
admissionregistration.k8s.io/v1
查看kubernetes集群的准入控制现状
]# grep admission /etc/kubernetes/manifests/kube-apiserver.yaml
- --enable-admission-plugins=NodeRestriction
准备专属的目录
mkdir -p /data/kubernetes/process_secure/api_conf
cd /data/kubernetes/process_secure/api_conf
准备准入控制的策略文件 admission_configuration.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ImagePolicyWebhook
configuration:
imagePolicy:
# 指定image策略专属连接和认证文件
kubeConfigFile: /etc/kubernetes/image-policy/connect_webhook.yaml
allowTTL: 50
denyTTL: 50
retryBackoff: 500
defaultAllow: true
定制image策略专属连接和认证文件 connect_webhook.yaml
apiVersion: v1
kind: Config
clusters:
- cluster:
certificate-authority: /etc/kubernetes/image-policy/webhook.pem
# 定制
server: https://10.0.0.12:8080/image_check
name: webhook
contexts:
- context:
cluster: webhook
user: apiserver
name: webhook
current-context: webhook
preferences: {}
users:
- name: apiserver
user:
client-certificate: /etc/kubernetes/image-policy/apiserver-client.pem
client-key: /etc/kubernetes/image-policy/apiserver-client-key.pem
同步证书相关信息
cd /data/kubernetes/process_secure/cert/
for i in 12 13 14
do
ssh root@10.0.0.$i mkdir /etc/kubernetes/image-policy -p
scp webhook.pem apiserver-client.pem apiserver-client-key.pem root@10.0.0.$i:/etc/kubernetes/image-policy/
scp ../api_conf/{admission_configuration.yaml,connect_webhook.yaml} root@10.0.0.$i:/etc/kubernetes/image-policy/
done
修改kube-apiserver的配置文件与webhook集成
]# cp /etc/kubernetes/manifests/kube-apiserver.yaml{，.bak}
]# vim /etc/kubernetes/manifests/kube-apiserver.yaml
...
spec:
containers:
- command:
...
- --enable-admission-plugins=NodeRestriction,ImagePolicyWebhook
- --admission-control-config-file=/etc/kubernetes/image-policy/admission_configuration.yaml
...
volumeMounts:
...
- mountPath: /etc/kubernetes/image-policy
name: image-policy
readOnly: true
...
volumes:
- hostPath:
path: /etc/kubernetes/image-policy
type: DirectoryOrCreate
name: image-policy
...
配置解读：
因为涉及到专属证书信息，所以需要hostPath方式进行挂载操作
注意：
因为kube-apiserver是静态pod，所以文件修改完毕后，就可以重启了
综合测试
在master节点上创建两个deployment
kubectl create deployment web1 --image=kubernetes-register.superopsmsb.com/superopsmsb/nginx_web
kubectl create deployment web2 --image=kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
查看docker容器日志
docker logs -f image-webhook
环境收尾
删除docker容器
docker rm -f image-webhook
清理deployment
kubectl delete deployments.apps web1 web2
还原kube-apiserver环境
for i in 12 13 14
do
ssh root@10.0.0.$i "mv /etc/kubernetes/manifests/kube-apiserver.yaml.bak /etc/kubernetes/manifests/kube-apiserver.yaml; rm -rf /etc/kubernetes/image-policy"
done
小结
1.2 配置管理
1.2.1 配置基础
学习目标
这一节，我们从 基础知识、资源清单、小结 三个方面来学习。
基础知识
场景需求
生产中所有的应用程序中，都涉及到配置文件，而配置文件经常会有变更，比如数据库连接、代码版本号等，最典型场景就是：
项目经历开发环境、测试环境、预发布环境、线上环境才能完成发布，而每个环境都有定义其独立的各种配置，这些配置手工操作很繁杂，所以好多大公司专门开发了专用配置管理中心，如百度的disconf等。
如何为容器化应用提供配置信息？
1 启动容器时，直接向应用程序传递参数，args: []
2 将定义好的配置文件焙进镜像之中；
3 通过环境变量向容器传递配置数据：有个前提要求，应用得支持从环境变量加载配置信息；
4 制作镜像时，使用entrypoint脚本来预处理变量，常见的做法就是使用非交互式编辑工具，将环境变量的值替换到应用的配置文件中；
5 基于存储卷向容器传递配置文件；
注意：
对于运行容器中的配置改变，需要通过应用程序重载相关配置
k8s的配置管理
kubernetes作为分布式容器调度平台，肯定会遇到同样的问题，那么遇到这种问题后，我们不可能把资源删除后，重新修改一下，然后在启动生成，这种方法就太繁琐的。kubernetes提供了对pod中容器应用的集中配置管理组件：ConfigMap、Secret、downwardAPI。通过这些组件来实现向pod中的容器中注入配置信息的机制。
资源清单
对象形式
在kubernetes中，资源对象有两种形态：
文件形态 - 编写出来的资源对象文件，有大量属性组成。
对象形态 - 基于资源对象文件初始化后出来的应用对象。
对象初始化
资源对象初始化的方法主要有两大类：
命令行工具(kubectl)
- 通过纯粹的 "k8s命令及其选项" 来实现资源的创建
文件方式(API)
- 基于 "k8s命令 + 配置文件" 来实现资源的创建
- 基于 "声明式的配置文件 + kubectl" 来实现资源的创建
使用资源对象
生产中使用k8s操作业务环境
1 保证容器应用是正常运行的
2 创建专属的资源对象文件
3 基于资源对象文件创建业务环境
4 测试业务环境，如果不满足则进行后续动作，否则不做任何改变
- 调整容器的镜像文件
- 重新调整资源对象文件
- 基于新资源对象文件创建并测试新的环境
小结
1.2.2 YAML安全
学习目标
这一节，我们从 基础知识、简单实践、小结 三个方面来学习。
基础知识
需求
资源清单的最大的好处是，让我们手工繁琐操作流程变成一个一个的资源对象属性，通过一个简单的kubectl apply -f的方式，基于资源清单文件，实现业务环境的高度定制化、自动化的操作。
大量的资源清单文件在大规模使用的时候，往往会因为场景的不同，需要对于同一个配置文件进行修整。如果我们对于资源清单文件的目录结构、内容样式、适用场景非常了解的前提下，我们可以随意的操作这些海量的资源清单文件。
但是我们知道，无论操作人员的能力多么的高，在面对海量数据的时候，总会有懈怠的时候，再加上yaml操作的高速度，一旦yaml文件出现安全问题，那会导致非常严重的业务环境问题。尤其是当我们的能力不足以撑起yaml的优势的时候，导致的问题会更大。
所以，我们需要一种yaml文件的安全检测机制，来保证yaml文件的安全性。这里的安全性主要体现在三个层面：
1 yaml文件自身的结构 - explain
2 yaml文件本身的安全 - kubesec
3 yaml文件项目的安全 - kustomize
安全机制
yaml文件自身的结构 - explain
所谓文件自身的结构，就是结合explain的资源对象属性体系，然后根据业务场景的功能，选择合适的对象属性组合在一起即可。
- 它是kubeadm的一个子命令
yaml文件本身的安全 - kubesec
所谓文件本身的安全，是借助于专用的资源清单的安全配置评估的工具，根据生产的最佳实践来验证资源清单文件的安全性并适时给出建议。Kubesec 可以作为 Web 服务或准入控制器的样式存在，接收 Kubernetes资源作为输入，并进程检测分析，如果不合格，则禁止执行。
- 参考地址：https://github.com/controlplaneio/kubesec
yaml文件项目的安全 - kustomize
所谓的文件项目的安全，是站在项目的角度，对所有场景中的资源清单文件，按照版本管理的方式进行统一安全质量控制。kustomize 是 kubernetes 原生的配置管理，以无模板方式来定制应用的配置。通过功能复用、补丁等方式实现项目级别的yaml结构安全。
- 参考地址；https://github.com/kubernetes-sigs/kustomize
简单实践
普通方式实践kubeasc
Kubesec 可以作为二进制包、容器镜像、准入控制器甚至 kubectl 插件安装
cd /data/softs
wget https://github.com/controlplaneio/kubesec/releases/download/v2.12.0/kubesec_linux_amd64.tar.gz
部署kubesec
tar -xvf kubesec_linux_amd64.tar.gz
mv kubesec /usr/local/bin/
注意：
命令格式 kubesec scan /path/to/file.yaml
该命令在第一次检测的时候，需要到github中获取检测文件
简单实践
]# kubesec scan /data/kubernetes/app_secure/01_kubernetes_application_secure_secret_data.yaml
[
{
"object": "Secret/superopsmsb-secret.default",
"valid": true,
"fileName": "/data/kubernetes/app_secure/01_kubernetes_application_secure_secret_data.yaml",
"message": "This resource kind is not supported by kubesec",
"score": 0,
"scoring": {}
}
]
]# kubesec scan /data/kubernetes/server_secure/01_kubernetes_server_secure_pod_test.yaml
[
{
"object": "Pod/nginx-web.default",
"valid": true,
"fileName": "/data/kubernetes/server_secure/01_kubernetes_server_secure_pod_test.yaml",
"message": "Passed with a score of 0 points",
"score": 0,
"scoring": {
"advise": [
{
"id": "ApparmorAny",
"selector": ".metadata .annotations .\"container.apparmor.security.beta.kubernetes.io/nginx\"",
"reason": "Well defined AppArmor policies may provide greater protection from unknown threats. WARNING: NOT PRODUCTION READY",
"points": 3
},
...
web服务方式
部署web服务方式1 - 依赖于gitlab的访问获取配置文件
kubesec http 8080 &
部署web服务方式2 - 容器内部的自带配置文件
docker pull kubesec/kubesec
docker run -d --name kubesec -p 8080:8080 kubesec/kubesec http 8080
使用方式
curl -sSX POST --data-binary @/path/to/file.yaml http://localhost:8080/scan
检测方式
]# curl -sSX POST --data-binary @/data/kubernetes/server_secure/01_kubernetes_server_secure_pod_test.yaml http://10.0.0.12:8080/scan
[
{
"object": "Pod/nginx-web.default",
"valid": true,
"fileName": "API",
"message": "Passed with a score of 0 points",
"score": 0,
...
其他检测方式
变种方式
docker run -i kubesec/kubesec scan /dev/stdin < /path/to/file.yaml
注意：
不推荐
webhook方式
参考资料： https://github.com/controlplaneio/kubesec-webhook
小结
1.2.3 kustomize
学习目标
这一节，我们从 基础知识、应用管理、小结 三个方面来学习。
基础知识
实际现状
根据我们之前对 k8s的学习，尤其是对各种状态应用的管理，比如statsfulset资源对象，redis集群、alertmanager部署等具体的实践。当我们需要在kubernetes环境运行一个完整的业务项目的时候，我们需要根据业务需求提前梳理功能，进而编写大量的资源清单文件的YAML文件，通过这些文件来定制项目的预期目标(副本，存储空间，内存和CPU等信息)，我们就会遇到两种问题：
1 一大堆的部署配置资源清单就是工作量非常大的一件事情。
对于这些复杂的应用，在k8s之上，我们不建议使用独立的部署清单来进行配置
2 部署清单本身就有相当大的限制约束，导致部署清单的任务量成倍增加
如果我们要部署多套prometheus集群，我们可以将所有的资源配置清单部署到不同的namespace中
- 这就导致，两套不同的部署清单文件结构
根据我们之前说的，持续交付的解决方案，为了实现成功的项目交付，我们要在不同的环境中测试该业务是否满足我们的预期，所以项目交付的过程中，会涉及到多种环境。所以实际的情况中，我们需要通过复制+定制的方式，为不同的环境配置独有的一套配置。
我们可以想象得到，一旦我们针对这么来进行管理的话，那当我们的业务环境达到一定量级的时候，我们就有多套仅存在细微差别的配置，对于后期的方案维护相当的不友好。
方案规整
所以，为了便于k8s来管理这些同业务的多版本场景，尤其是云原生的时代，我们应该使用一个 git版本控制系统来对所有的资源配置清单进行统一的管控。同时为了方便后续技术支持团队的管理维护，开发人员应该做如下的三件事情：
1 编写业务项目相关的部署清单文件，并提交到代码管理仓库
- 方便后续团队，根据业务需求，准备相关的资源
2 提供项目持续维护的jenkinsfile、Dockerfile文件。
- 方便后续团队，根据业务的实际情况，以流水线的方式实现功能的迭代更新。
3 不同环境的资源文件，都应该有独有的一份。
- 以k8s环境为例，方便后续团队在多个ns中分别创建资源对象。
由于k8s上还有一种根据监控指标实现自动扩缩容的功能，所以，一旦我们将持续交付流水线做完毕后，结合提前做好的资源清单文件，与项目交付相关的所有操作，都不需要我们人工干预了。
应用管理
简介
根据我们刚才所描述的信息内容，我们可以了解到，越是复杂的业务运行环境，越需要有一套业务部署管理工具
- 将业务相关的功能解决方案，将多个云原生的软件以组件方式整合在一起，然后统一的进行管理
对于k8s来说，它就提供了这样的一种工具：kustomize。
官网介绍
Kubernetes native configuration management. Kustomize introduces a template-free way to customize application configuration that simplifies the use of off-the-shelf applications.
kustomize 是 kubernetes 原生的配置管理，以无模板方式来定制应用的配置。
也就是说，kustomize 使用 k8s 原生概念帮助创建并复用资源配置(YAML)，允许用户以一个应用描述文件(YAML 文件)为基础(Base YAML)，然后通过 Overlay 的方式生成最终部署应用所需的描述文件。
工具简介
kustomize允许用户将不同环境所共享的配置放在一个文件目录下，而将其他不同的配置放在另外的目录下。通过这种通用+特有的组合方式，让我们的多业务环境更轻松的来解决适配性的问题。
kustomize是sig-cli的一个子项目，它的设计目的是给kubernetes的用户提供一种可以重复使用同一套配置的声明式应用管理，从而在配置工作中用户只需要管理和维护kubernetes的API对象，而不需要学习或安装其它的配置管理工具，也不需要通过复制粘贴来得到新的环境的配置。
Kustomize 是一个用来定制 Kubernetes 配置的工具。它提供以下功能特性来管理 应用配置文件：
从其他来源生成资源
为资源设置贯穿性（Cross-Cutting）字段
组织和定制资源集合
github地址：https://github.com/kubernetes-sigs/kustomize
最新版本：v4.5.7 | 20220803
概念解析
| 组件 | 解析 |
|---|---|
| kustomization | 该文件所在的目录下可以运行 kustomize build，自动生成配套文件 |
| base | kustomization.yaml文件所在目录，项目的根目录 |
| resource | kubernetes API资源对象文件 |
| patch | kubernetes API资源对象文件特有的patch属性信息文件，符合yaml格式。 |
| variant | base下的多个不同业务场景的kustomization |
| overlay | 声明了与 base 之间的差异。通过 overlay 来维护基于 base 的不同 variants(变体) |
入口配置
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases <[]string> # 基础通用配置信息所在目录
resources <[]string> # 待定制的原始资源配置文件列表，按顺序处理
namespace # 资源对象归属目标名称空间
commonLabels [string]string> # 资源对象的通用标签
commonAnnotations [string]string> # 资源对象的通用注解
namePrefix # 资源对象添加的名称前缀
nameSuffix # 资源对象添加的名称后缀
images <[]Image> # 模板中定制的镜像文件
- name # 待替换的镜像名称
nameName # 要使用的新镜像名称
newTag # 要使用的新镜像的标签
digest # 要使用的新镜像的sha256校验码
vars <[]Var> # 可替换的变量列表
- name # 变量的名称，支持以“$(name)”格式进行引用
objref # 包含了要引用的目标字段的对象的名称
fieldref # 引用的字段名称，默认为metadata.name
配置生成器
ConfigMap生成器：
configMapGenerator <[]ConfigMapGeneratorArgs> # ConfigMap资源生成器列表
- name # 资源对象名称
namespace # 命名空间
behavior # 合并策略，可为create/replace/merge；
files <[]String> # ConfigMap文件相对当前项目的路径
literals <[]String> # 以“key=value”格式的生成ConfigMap
env # 以环境变量文件格式生成ConfigMap
Secret生成器：
secretGenerator <[]secretGeneratorArgs> # Secret资源生成器列表
- name # 资源对象名称
namespace # 命名空间
behavior # 合并策略，可为create/replace/merge；
files <[]String> # Secret文件相对当前项目的路径
literals <[]String> # 以“key=value”格式的生成Secret
type # 选择Secret资源类型
生成器选项：
generatorOptions # 生成器额外属性，为上面两项的补充内容
labels [String]String> # 扩展的标签
annotations [String]String> # 扩展的注解
disableNameSuffixHash # 是否禁用hash名称后缀，默认为启用
资源补丁
patchesJson6902 <[]Json6902> # 待补对象列表
path # 补丁文件路径，支持json或yaml格式
target # 待补资源对象
group # 资源所属的群组
version # API版本
kind # 资源类型
name # 资源对象的名称
namespace # 资源对象所属的名称空间
patchesStrategicMerge <[]string> # 将补丁补到匹配的资源之上，匹配的方式是根据资源
# Group/Version/Kind + Name/Namespace判断
配置示例
资源清单文件：kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- /config/app1/base
- /config/app2/base
- ...
resources:
- service.yaml
- deployment.yaml
patches:
- patch.yaml
namePrefix: my-
Kustomize的核心目标在于为管理的应用生成资源配置，而这些资源配置中定义了资源的期望状态
小结
1.2.4 基础实践
学习目标
这一节，我们从 基础知识、简单实践、小结 三个方面来学习。
环境准备
简介
我们可以通过如下两种不同方式来安装kustomize
二进制方式：将软件包解压到系统命令路径即可，我们推荐
go方式：go get github.com/kubernetes-sigs/kustomize
k8s方法：从 1.14 版本开始，kubectl 也开始支持使用 kustomization 文件来管理 Kubernetes 对象。 要查看包含 kustomization 文件的目录中的资源，执行下面的命令：
软件安装
下载软件
mkdir /data/softs && cd /data/softs
wget https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize%2Fv4.5.7/kustomize_v4.5.7_linux_amd64.tar.gz
解压文件
mkdir /data/server/kustomize/bin
tar xf kustomize_v4.5.7_linux_amd64.tar.gz -C /data/server/kustomize/bin/
环境变量定制
# vim /etc/profile.d/kustomize.sh
#!/bin/bash
# set kustomize env path
export KUSTOMIZE_HOME=/data/server/kustomize
export PATH=${KUSTOMIZE_HOME}/bin:$PATH
加载环境变量
chmod +x /etc/profile.d/kustomize.sh
source /etc/profile.d/kustomize.sh
查看命令帮助
]# kustomize --help
...
Available Commands:
build Build a kustomization target from a directory or URL.
cfg Commands for reading and writing configuration.
completion Generate shell completion script
create Create a new kustomization in the current directory
edit Edits a kustomization file
fn Commands for running functions against configuration.
help Help about any command
version Prints the kustomize version
Flags:
-h, --help help for kustomize
--stack-trace print a stack-trace on error
Additional help topics:
kustomize docs-fn [Alpha] 开发和调用配置函数的文档
kustomize docs-fn-spec [Alpha] 配置函数规范文档.
kustomize docs-io-annotations [Alpha] io使用的注释文档
kustomize docs-merge [Alpha] 合并资源的文档.
kustomize docs-merge3 [Alpha] 合并资源的文档.
kustomize tutorials-command-basics [Alpha] 使用基本配置命令的教程.
kustomize tutorials-function-basics [Alpha] 使用函数的教程.
Use "kustomize [command] --help" for more information about a command.
安装方式2 - k8s子命令
从 1.14 版本开始，kubectl 也开始支持使用 kustomization 文件来管理 Kubernetes 对象。 要查看包含 kustomization 文件的目录中的资源，执行下面的命令：
kubectl kustomize
要应用这些资源，使用参数 --kustomize 或 -k 标志来执行 kubectl apply：
kubectl apply -k
简单实践
简单实践
创建测试目录
mkdir -p /data/kubernetes/process_secure/kustomize/kustomize-test -p
创建核心的kustomization.yaml文件，用于核心流程处理
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- kustomiz-deployment-test.yaml
- kustomiz-service-test.yaml
commonLabels:
generated-by: kustomize
创建依赖的 kustomiz-deployment-test.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-nginx-web
spec:
replicas: 1
selector:
matchLabels:
app: nginx-web
template:
metadata:
labels:
app: nginx-web
spec:
containers:
- name: nginx
image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
name: http
创建依赖的 kustomiz-service-test.yaml
kind: Service
apiVersion: v1
metadata:
name: service-nginx-web
spec:
selector:
app: nginx-web
ports:
- name: http
protocol: TCP
port: 80
targetPort: 80
查看目录结构
kustomize/kustomize-test]# tree ./
./
├── kustomization.yaml
├── kustomiz-deployment-test.yaml
└── kustomiz-service-test.yaml
0 directories, 3 files
执行效果
创建资源对象
kubectl apply -k ./
查看资源对象
]# kubectl get pod,svc
NAME READY STATUS RESTARTS AGE
pod/deployment-nginx-web-c77b687c5-6tzmt 1/1 Running 0 9s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 443/TCP 57d
service/service-nginx-web ClusterIP 10.106.243.105 80/TCP 10s
删除资源对象
kubectl delete -k ./
直接以模拟的方式查看效果
kubectl apply -k ./ --dry-run=client -o yaml
仅仅查看生成的配置文件
kustomize build ./
注意：
这种方式可以确认，创建好的资源对象是否包含我们刚才定制的相关属性信息。
小结
1.2.5 功能复用
学习目标
这一节，我们从 基础知识、简单实践、小结 三个方面来学习。
基础知识
简介
kustomize 可以通过目录复用的机制，实现在通用功能的基础上，对某些特殊的机制进行重写或者集成
方案解析
我们可以创建一个base目录，作为所有相关项目的根目录。
然后再另外一个目录中，通过 bases 属性，继承base目录的相关内容
简单实践
准备基础文件
将我们之前实践出来的环境文件，作为一个基础的可以被其他环境集成的项目目录
mkdir kustomize-proj/base/ -p
cp -a kustomize-test/* kustomize-proj/base/
环境实践
在base目录同级别的位置，创建一个test目录
mkdir kustomize-proj/test
创建一个专用的继承功能的文件 kustomize-proj/test/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../base/
resources:
- namespace.yaml
namespace: test
# kustomize支持添加标注和注释，这些标注和注释会加在每一个它所管理的API对象上
commonLabels:
env: test
commonAnnotations:
superopsmsb.io/app: "kustomize"
images:
- name: "kubernetes-register.superopsmsb.com/superopsmsb/nginx_web"
newTag: "v0.1"
属性解析：
1 通过base继承原来的应用
2 images仅仅是基于原来的镜像名称，更改了镜像的标签。
创建依赖出来的文件 kustomize-proj/test/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name: test
查看目录效果
# tree kustomize-proj/
kustomize-proj/
├── base
│ ├── kustomization.yaml
│ ├── kustomiz-deployment-test.yaml
│ └── kustomiz-service-test.yaml
└── test
├── kustomization.yaml
└── namespace.yaml
2 directories, 5 files
检查效果
kubectl apply -k kustomize-proj/base/ --dry-run=client -o yaml
kubectl apply -k kustomize-proj/test/ --dry-run=client -o yaml
或者
kustomize build kustomize-proj/base/
kustomize build kustomize-proj/test/
小结
1.2.6 配置定制
学习目标
这一节，我们从 基础知识、简单实践、小结 三个方面来学习。
基础知识
简介
ConfigMap 和 Secret 包含其他 Kubernetes 对象（如 Pod）所需要的配置或敏感数据。 ConfigMap 或 Secret 中数据的来源往往是集群外部. 例如某个 .properties 文件或者 SSH 密钥文件。
Kustomize 提供 secretGenerator 和 configMapGenerator，可以基于文件或字面 值来生成 Secret 和 ConfigMap。
简单实践
准备基础文件
在base目录同级别的位置，创建一个test目录
mkdir kustomize-proj/staging
环境实践
创建一个专用的继承功能的文件 kustomize-proj/staging/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../base/
resources:
- namespace.yaml
namespace: staging
commonLabels:
environment: staging
commonAnnotations:
superopsmsb.io/app: "kustomize"
configMapGenerator:
- name: nginx-conf
literals:
- HOST="0.0.0.0"
- PORT="80"
secretGenerator:
- name: nginx-ssl
files:
- secrets/tls.crt
- secrets/tls.key
type: "kubernetes.io/tls"
generatorOptions:
disableNameSuffixHash: true
属性解析：
1 通过secretGenerator 和 generatorOptions 生成相关的对象
2 disableNameSuffixHash 的目的是在基于deployment创建pod的时候，禁止生成hash后缀
创建依赖出来的文件 kustomize-proj/staging/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name: staging
准备相关的证书信息
mkdir kustomize-proj/staging/secrets && cd kustomize-proj/staging/secrets
openssl genrsa -out tls.key 2048
openssl req -new -x509 -key tls.key -out tls.crt -subj /C=CN/ST=Beijing/L=Beijing/O=DevOps/CN=shuji.superopsmsb.com
注意：
域名必须是我们使用的域名信息
检查效果
查看目录效果
]# tree kustomize-proj/
kustomize-proj/
├── base
│ ├── kustomization.yaml
│ ├── kustomiz-deployment-test.yaml
│ └── kustomiz-service-test.yaml
├── staging
│ ├── kustomization.yaml
│ ├── namespace.yaml
│ └── secrets
│ ├── tls.crt
│ └── tls.key
└── test
├── kustomization.yaml
└── namespace.yaml
4 directories, 9 files
方法1
kubectl apply -k ./base/ --dry-run=client -o yaml
kubectl apply -k ./staging/ --dry-run=client -o yaml
方法2
kustomize build kustomize-proj/base/
kustomize build kustomize-proj/staging/
小结
1.2.7 补丁实践
学习目标
这一节，我们从 基础知识、简单实践、小结 三个方面来学习。
基础知识
简介
由于软件开发是一个复杂的过程，组织必须保持警惕以确保系统是最新版本的，涉及到的业务功能需要更新，以避免不必要的风险。根据2022年云原生环境下容器存活周期的调查，容器的更新时间是非常快的，在加上容器业务环境的更新迭代非常高，这就对于kubernetes场景中海量的资源清单文件的管理，提出了更高的要求。
补丁的作用
补丁管理是针对当前资源对象进行识别、获取、部署和验证软件更新的做法。我们可以借助于kustomize补丁管理策略和解决方案有助于为kuberntes资源管理对象的统一管理，提供应用验证和应用更新的便捷方法。
补丁管理的意义对于网络安全行业来说不言而喻。为了应对高级威胁，检测全球威胁情报源已知的恶意软件是成功的一半。补丁管理对于阻止已知威胁而言至关重要。
属性解析
资源补丁
patchesJson6902 <[]Json6902> # 待补对象列表
path # 补丁文件路径，支持json或yaml格式
target # 待补资源对象
group # 资源所属的群组
version # API版本
kind # 资源类型
name # 资源对象的名称
namespace # 资源对象所属的名称空间
patchesStrategicMerge <[]string> # 将补丁补到匹配的资源之上，匹配的方式是根据资源
# Group/Version/Kind + Name/Namespace判断
由于定制的补丁信息，主要起的是补充的作用，所以，为了能够让补丁信息和所归属的资源对象产生关联，我们需要在patch文件中补充原资源对象的基本属性信息，比如apiVersion、Kind、Namespace等。
简单实践
准备基础文件
在base目录同级别的位置，创建一个prod目录
mkdir kustomize-proj/prod/patches
环境实践
创建一个专用的继承功能的文件 kustomize-proj/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../base/
resources:
- namespace.yaml
namespace: prod
commonLabels:
env: prod
commonAnnotations:
superopsmsb.io/app: "kustomize"
configMapGenerator:
- name: nginx-conf
literals:
- host="0.0.0.0"
- port="80"
secretGenerator:
- name: nginx-ssl
files:
- secrets/tls.crt
- secrets/tls.key
type: "kubernetes.io/tls"
generatorOptions:
disableNameSuffixHash: true
patchesStrategicMerge:
- patches/nginx-add-check.yaml
- patches/nginx-add-conf.yaml
patchesJson6902:
- target:
version: v1
kind: Service
name: service-nginx-web
path: patches/patch-service-nginx.yaml
属性解析：
1 通过patchesStrategicMerge 加载相关的补丁文件
2 patchesJson6902 使用这种规则进行规范限制
创建依赖出来的文件 kustomize-proj/prod/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name: prod
准备补丁文件
定制配置相关的补丁文件 kustomize-proj/prod/patches/nginx-add-conf.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-nginx-web
spec:
template:
spec:
containers:
- name: nginx
env:
- name: PORT
valueFrom:
configMapKeyRef:
name: nginx-conf
key: port
optional: false
- name: HOST
valueFrom:
configMapKeyRef:
name: nginx-conf
key: host
optional: true
volumeMounts:
- name: nginx-certs
mountPath: /etc/certs/
readOnly: true
volumes:
- name: nginx-certs
secret:
secretName: nginx-ssl
定制检测相关的补丁文件 kustomize-proj/prod/patches/nginx-add-check.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-nginx-web
spec:
template:
spec:
containers:
- name: nginx
livenessProbe:
httpGet:
path: '/'
port: 80
initialDelaySeconds: 5
readinessProbe:
httpGet:
path: '/'
port: 80
initialDelaySeconds: 15
准备纯粹的补丁文件 kustomize-proj/prod/patches/nginx-add-sidecar.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-nginx-web
spec:
template:
spec:
containers:
- name: busybox
image: kubernetes-register.superopsmsb.com/superopsmsb/busybox:v0.1
command: ['/bin/sh','-c']
args: ['sleep 3600']
定制专属的service修改补丁文件 kustomize-proj/prod/patches/patch-service-nginx.yaml
- op: replace
path: /spec/ports/0/targetPort
value: 8888
- op: add
path: /spec/ports/1
value:
name: https
protocol: TCP
port: 443
targetPort: 8443
准备相关的证书信息
mkdir kustomize-proj/prod/secrets && cd kustomize-proj/prod/secrets
openssl genrsa -out tls.key 2048
openssl req -new -x509 -key tls.key -out tls.crt -subj /O=DevOps/CN=shuji.superopsmsb.com
注意：
域名必须是我们使用的域名信息
查看效果
查看目录效果
]# tree kustomize-proj/prod/
kustomize-proj/prod/
├── kustomization.yaml
├── namespace.yaml
├── patches
│ ├── nginx-add-check.yaml
│ ├── nginx-add-conf.yaml
│ ├── nginx-add-sidecar.yaml
│ └── patch-service-nginx.yaml
└── secrets
├── tls.crt
└── tls.key
2 directories, 8 files
方法1:
kubectl apply -k kustomize-proj/base/ --dry-run=client -o yaml
kubectl apply -k kustomize-proj/prod/ --dry-run=client -o yaml
方法2:
kustomize build kustomize-proj/base/
kustomize build kustomize-proj/prod/
运行项目环境
kubectl apply -k kustomize-proj/prod/
检测效果
kubectl get all -n prod
小结
1.3 访问安全
1.3.1 安全检测
学习目标
这一节，我们从 基础知识、简单实践、小结 三个方面来学习。
基础知识
需求
国外软件供应商产品历史上出现了许多恶意后门和网络安全事件，譬如服务源码泄露漏洞、 黑客攻击漏洞、木马事件等，由于这些软件运行本身的安全漏洞，导致在此平台之上的应用也运行在危险环境中，我们把这类的安全问题统统成为供应链安全问题 -- 非项目代码本身导致的安全问题。由于供应链安全事件愈演愈烈，从2021年逐渐引起大家注意。
Synopsys 2022年对市场上17个行业2400多个商用产品的代码源进行了分析。开源软件代码使用率超过78%，81%的代码包含至少一个安全漏洞，而且53%的代码存在许可证冲突问题。许可证冲突问题会影响商务软件的使用。
虽然供应链方面的安全隐患非常多，但是我们可以站在用户访问流程的角度，直接从入口进行控制，只要我们能够将常见的用户请求进行精细化的限制的话，我们可以极大程度的降低软件项目所面对的安全攻击手段。
对于基于kubernetes的容器应用来说，我们还可以在Ingress层面进行更加高层次的，专门针对用户请求数据的安全访问控制。
为什么需要使用Ingress暴露服务？
Kubernetes主要通过两种方式实现集群内外的流量访问：
1 支持通过NodePort、LoadBalancer等方式向集群外部暴露内部服务
2 支持以ingress通过单一IP为多个服务提供基于http形式的访问
- 通过主机名和路径将流量路由到特定服务，使得服务访问更加灵活，同时还可以用来提供https服务。
ingress的两大实现软件：
Kubernetes Ingress Nginx
kubernetes社区开发和维护(Nginx帮忙管理)的ingress-nginx，通过nginx的负载均衡和反向代理能力实现流量控制
- kubernetes/ingress-nginx
- https://github.com/kubernetes/ingress-nginx
Nginx Ingress Controller
NGINX公司开发和维护的一种Ingress Controller。实现了nginx更多的能力，包括VS和VSR等，这些都是k8s的ingress默认不支持的功能。
- 它主要有两个发行：基于NGINX开源(免费)和基于NGINX Plus(商业)
- nginxinc/kubernetes-ingress
- https://github.com/nginxinc/kubernetes-ingress/
- https://docs.nginx.com/nginx-ingress-controller/
nginx 控制器的优势
Nginx Ingress Controller和其他Ingress Controller之间的主要区别在于它们的开发和部署模型，尤其是这些模型可以基于不同的目标和优先级实现nginx善于负载均衡和反向代理。
开发理念
- NGINX 项目和产品的首要任务是提供一个快速、轻量级的工具，并具有长期的稳定性和一致性。
集成代码库
- 所有代码都是NGINX自己的代码和校验过的代码，保证控制器环境的高度稳定。
高级流量管理
- 有别于其他Ingress通过注释、CM、template定制高级功能。
- Nginx控制器提供原生、类型安全和缩进的配置风格，高级功能配置
- 包括 TCP/UDP、断路、A/B测试、蓝绿部署、双向TLS认证和WAF等。
持续的生产准备
- 每个版本都按照可支持的生产标准进行构建和维护。
根据2022年<>的统计数据显示：在生产环境中有了更多的命名空间，每个命名空间有了更多的 Deployments，每个命名空间下的 Deployments 构成了用户服务应用的部署单元。
所以说如何让流量入口适应新形势下的kubernetes应用就是非常重要的选项了。
简单实践
清理旧环境
清理旧有环境
cd /data/kubernetes/app_secure/
kubectl delete -f ./
清理旧有ingress控制器
kubectl delete -f ingress/deploy-daemonset.yaml
准备环境
获取环境文件
cd /data/kubernetes/process_secure/
git clone https://github.com/nginxinc/kubernetes-ingress.git --branch v2.4.1
cd kubernetes-ingress/deployments
部署基础环境
kubectl apply -f common/ns-and-sa.yaml
kubectl apply -f rbac/rbac.yaml
kubectl apply -f rbac/ap-rbac.yaml
kubectl apply -f rbac/apdos-rbac.yaml
部署通用资源
kubectl apply -f common/default-server-secret.yaml
kubectl apply -f common/nginx-config.yaml
kubectl apply -f common/ingress-class.yaml
创建自定义资源
kubectl apply -f common/crds/k8s.nginx.org_virtualservers.yaml
kubectl apply -f common/crds/k8s.nginx.org_virtualserverroutes.yaml
kubectl apply -f common/crds/k8s.nginx.org_transportservers.yaml
kubectl apply -f common/crds/k8s.nginx.org_policies.yaml
kubectl apply -f common/crds/k8s.nginx.org_globalconfigurations.yaml
创建应用保护资源对象
kubectl apply -f common/crds/appprotect.f5.com_aplogconfs.yaml
kubectl apply -f common/crds/appprotect.f5.com_appolicies.yaml
kubectl apply -f common/crds/appprotect.f5.com_apusersigs.yaml
创建洪水攻击防护资源对象
kubectl apply -f common/crds/appprotectdos.f5.com_apdoslogconfs.yaml
kubectl apply -f common/crds/appprotectdos.f5.com_apdospolicy.yaml
kubectl apply -f common/crds/appprotectdos.f5.com_dosprotectedresources.yaml
部署环境
部署应用保护的环境
kubectl apply -f deployment/appprotect-dos-arb.yaml
kubectl apply -f service/appprotect-dos-arb-svc.yaml
修改ingress的入口 service/nodeport.yaml
...
spec:
externalIPs: ['10.0.0.12'] # 增加该条属性
...
deployment方式部署ingress控制器
kubectl apply -f deployment/nginx-ingress.yaml
kubectl create -f service/nodeport.yaml
daemonset方式部署ingress控制器
kubectl apply -f daemon-set/nginx-ingress.yaml
注意：
二选一即可，由于daemonset自动做了端口的映射，所以不需要做service
环境检查
]# kubectl get pods --namespace=nginx-ingress
NAME READY STATUS RESTARTS AGE
appprotect-dos-arb-78fb9d4cbf-82xbt 1/1 Running 0 3m31s
nginx-ingress-6644665fb7-rrtsm 1/1 Running 0 2m34s
其他
环境的收尾
kubectl delete namespace nginx-ingress
kubectl delete clusterrole nginx-ingress
kubectl delete clusterrolebinding nginx-ingress
kubectl delete -f common/crds/
小结
1.3.3 简单实践
学习目标
这一节，我们从 准备工作、简单实践、小结 三个方面来学习。
基础知识
准备服务模板文件
定制资源清单文件 01_ingress_web_resource.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: django
spec:
replicas: 2
selector:
matchLabels:
app: django
template:
metadata:
labels:
app: django
spec:
containers:
- name: django
image: kubernetes-register.superopsmsb.com/superopsmsb/django_web:v0.1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
name: django-svc
spec:
ports:
- port: 8000
targetPort: 8000
protocol: TCP
name: http
selector:
app: django
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
labels:
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
name: http
selector:
app: nginx
应用资源清单文件
kubectl apply -f 01_ingress_web_resource.yaml
检查效果
]# kubectl get deploy,svc
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/django 2/2 2 2 30s
deployment.apps/nginx 2/2 2 2 30s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/django-svc ClusterIP 10.105.153.107 8000/TCP 30s
service/kubernetes ClusterIP 10.96.0.1 443/TCP 49d
service/nginx-svc ClusterIP 10.97.65.163 80/TCP 30s
这里是使用ingressclasses的方式进行ingress方式选择的
]# kubectl get ingressclasses.networking.k8s.io
NAME CONTROLLER PARAMETERS AGE
nginx nginx.org/ingress-controller 26h
功能页面访问
]# curl 10.105.153.107:8000
Hello Django, django-548fb788f5-4mckj-1.10.4
]# curl 10.97.65.163
Hello Nginx, nginx-7f7b4d6686-56jc6-1.23.1
定制单域名多url的ingress
定制资源清单文件 02_ingress_mulurl.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-test
annotations:
# nginx controller的反向代理，默认没有进行重写，我们需要定制重写机制
nginx.org/rewrites: "serviceName=nginx-svc rewrite=/"
spec:
# 对于nginx的入口控制器，它是以ingressClassName的方式来选择如何使用的
# 后面的定制格式与kubernetes的ingress格式一致
ingressClassName: nginx
rules:
- host: shuji.superopsmsb.com
http:
paths:
- path: /django
pathType: Prefix
backend:
service:
name: django-svc
port:
number: 8000
- path: /nginx
pathType: Prefix
backend:
service:
name: nginx-svc
port:
number: 80
应用资源清单文件
kubectl apply -f 02_ingress_mulurl.yaml
检查效果
]# kubectl describe ingress ingress-test
Name: ingress-test
...
Ingress Class: nginx
Default backend:
Rules:
Host Path Backends
---- ---- --------
shuji.superopsmsb.com
/django django-svc:8000 (10.244.3.11:8000,10.244.4.11:8000)
/nginx nginx-svc:80 (10.244.3.12:80,10.244.5.10:80)
Annotations: nginx.org/rewrites: serviceName=nginx-svc rewrite=/
...
定制专属的域名解析，因为我们对于ingress的入口进行限制了，所以hosts主机名解析信息如下：
echo '10.0.0.12 shuji.superopsmsb.com' >> /etc/hosts
访问效果
]# curl shuji.superopsmsb.com/django
Hello Django, django-548fb788f5-xfdjs-1.10.4
]# curl shuji.superopsmsb.com/nginx
Hello Nginx, nginx-7f7b4d6686-qfsfn-1.23.1
配置解析
]# kubectl -n nginx-ingress exec -it nginx-ingress-6644665fb7-54scz -- cat /etc/nginx/conf.d/default-ingress-test.conf
# configuration for default/ingress-test
upstream default-ingress-test-shuji.superopsmsb.com-django-svc-8000 {
zone default-ingress-test-shuji.superopsmsb.com-django-svc-8000 256k;
random two least_conn;
server 10.244.3.11:8000 max_fails=1 fail_timeout=10s max_conns=0;
server 10.244.4.11:8000 max_fails=1 fail_timeout=10s max_conns=0;
}
upstream default-ingress-test-shuji.superopsmsb.com-nginx-svc-80 {
zone default-ingress-test-shuji.superopsmsb.com-nginx-svc-80 256k;
random two least_conn;
server 10.244.3.12:80 max_fails=1 fail_timeout=10s max_conns=0;
server 10.244.5.10:80 max_fails=1 fail_timeout=10s max_conns=0;
}
server {
listen 80;
listen [::]:80;
server_tokens on;
server_name shuji.superopsmsb.com;
set $resource_type "ingress";
set $resource_name "ingress-test";
set $resource_namespace "default";
location /django {
set $service "django-svc";
...
proxy_pass http://default-ingress-test-shuji.superopsmsb.com-django-svc-8000;
}
location /nginx {
set $service "nginx-svc";
...
proxy_pass http://default-ingress-test-shuji.superopsmsb.com-nginx-svc-80/;
}
}
简单实践
定制secret文件
mkdir ingress-tls && cd ingress-tls
(umask 077; openssl genrsa -out tls.key 2048)
openssl req -new -x509 -key tls.key -out tls.crt -subj "/CN=shuji.superopsmsb.com" -days 365
kubectl create secret tls ingress-tls --cert=./tls.crt --key=./tls.key
cd ..
创建资源对象文件 03_ingress_tlshosts.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-test
annotations:
# 定制重写规则
nginx.org/rewrites: "serviceName=nginx-svc rewrite=/"
spec:
ingressClassName: nginx
# 添加tls认证信息
tls:
- hosts:
- shuji.superopsmsb.com
secretName: ingress-tls
rules:
- host: shuji.superopsmsb.com
http:
paths:
- path: /django
pathType: Prefix
backend:
service:
name: django-svc
port:
number: 8000
- path: /nginx
pathType: Prefix
backend:
service:
name: nginx-svc
port:
number: 80
应用ingress资源对象
kubectl delete -f 02_ingress_mulurl.yaml
kubectl apply -f 03_ingress_tlshosts.yaml
查看效果
]# kubectl describe ingress ingress-test
Name: ingress-test
...
TLS:
ingress-tls terminates shuji.superopsmsb.com
Rules:
Host Path Backends
---- ---- --------
shuji.superopsmsb.com
/django django-svc:8000 (10.244.3.11:8000,10.244.4.11:8000)
/nginx nginx-svc:80 (10.244.3.12:80,10.244.5.10:80)
Annotations: nginx.org/rewrites: serviceName=nginx-svc rewrite=/
...
访问效果
]# curl -k https://shuji.superopsmsb.com/django
Hello Django, django-548fb788f5-xfdjs-1.10.4
]# curl -k https://shuji.superopsmsb.com/nginx
Hello Nginx, nginx-7f7b4d6686-qfsfn-1.23.1
环境收尾
kubectl delete -f 01_ingress_web_resource.yaml -f 03_ingress_tlshosts.yaml
小结
1.3.3 虚拟主机
学习目标
这一节，我们从 基础知识、简单实践、小结 三个方面来学习。
基础知识
需求
Nginx Ingress Controller提供了基于虚拟主机的路由分发策略，可以让不同的应用位于不同的namespace环境，然后基于虚拟主机的方式在k8s中存在，然后定制一个专属的总路由进行配置，从而实现流量的分发。这种方式与传统意义上的应用流量分发基本一致。
配置解析
虚拟主机属性解析
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name:
namespace:
spec:
host: 访问域名
tls:
secret: https依赖的tls
routes:
- path: /分发url
route: namespace/虚拟主机名称
虚拟主机路由配置
apiVersion: k8s.nginx.org/v1
kind: VirtualServerRoute
metadata:
name:
namespace:
spec:
host: 访问域名
upstreams:
- name: <应用service组名>
service: <应用service组名>
port: <应用service端口>
subroutes:
# 反向代理配置
- path: /<应用url>
action:
proxy:
upstream: <应用service组名>
requestHeaders:
pass: true
set:
- name: 定制请求头
value: 定制请求值
responseHeaders:
add: # 增加响应头
- name: 定制响应头
value: 定制响应结果
always: true # 是否永远存在
rewritePath: / # 设定转发规则
# 根据条件请求路由分发
- path: /<应用url>
matches:
- conditions:
- cookie: version
value: v2
action:
pass: django-v2
案例需求
应用解析
nginx命名空间
nginx的deployment和svc，以及专属的虚拟主机路由
django命名空间
django的deployment和svc，以及专属的虚拟主机路由
django同时部署两个版本，v1和v2
shuji命名空间
定制专属虚拟主机
访问解析
https://shuji.superopsmsb.com/nginx - 默认访问nginx命名空间的nginx应用
https://shuji.superopsmsb.com/django - 默认访问django命名空间的django的v2版本
访问django的时候，携带"version=v1"请求头 - 访问django命名空间的django的v1版本
简单实践
准备基础环境
定制资源清单文件 04_ingress_vs_base.yaml
apiVersion: v1
kind: Namespace
metadata:
name: django
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: django-v1
namespace: django
spec:
replicas: 2
selector:
matchLabels:
app: django-v1
template:
metadata:
labels:
app: django-v1
spec:
containers:
- name: django
image: kubernetes-register.superopsmsb.com/superopsmsb/django_web:v0.1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
name: django-v1-svc
namespace: django
spec:
ports:
- port: 8000
targetPort: 8000
protocol: TCP
name: http
selector:
app: django-v1
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: django-v2
namespace: django
spec:
replicas: 2
selector:
matchLabels:
app: django-v1
template:
metadata:
labels:
app: django-v1
spec:
containers:
- name: django
image: kubernetes-register.superopsmsb.com/superopsmsb/django_web:v0.2
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
name: django-v1-svc
namespace: django
spec:
ports:
- port: 8000
targetPort: 8000
protocol: TCP
name: http
selector:
app: django-v1
---
apiVersion: v1
kind: Namespace
metadata:
name: nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
namespace: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
namespace: nginx
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
name: http
selector:
app: nginx
---
apiVersion: v1
kind: Namespace
metadata:
name: shuji
准备子路由主机
定制nginx虚拟主机路由资源清单文件 05_ingress_vs_nginx.yaml
apiVersion: k8s.nginx.org/v1
kind: VirtualServerRoute
metadata:
name: nginx
namespace: nginx
spec:
host: shuji.superopsmsb.com
upstreams:
- name: nginx
service: nginx-svc
port: 80
subroutes:
- path: /nginx
action:
proxy:
upstream: nginx
requestHeaders:
pass: true
set:
- name: My-Header
value: NGINX-Best
responseHeaders:
add:
- name: My-Header
value: ${http_user_agent}
- name: IC-Nginx-Version
value: ${nginx_version}
always: true
rewritePath: /
定制django虚拟主机路由资源清单文件 06_ingress_vs_django.yaml
apiVersion: k8s.nginx.org/v1
kind: VirtualServerRoute
metadata:
name: django
namespace: django
spec:
host: shuji.superopsmsb.com
upstreams:
- name: django-v1
service: django-v1-svc
port: 8000
- name: django-v2
service: django-v2-svc
port: 8000
subroutes:
- path: /django
matches:
- conditions:
- cookie: version
value: v2
action:
pass: django-v2
action:
pass: django-v1
定制虚拟服务主机
定制虚拟主机的资源清单 07_ingress_vs_shuji.yaml
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: shuji
namespace: shuji
spec:
host: shuji.superopsmsb.com
tls:
secret: ingress-tls
routes:
- path: /nginx
route: nginx/nginx
- path: /django
route: django/django
创建secret
kubectl -n shuji create secret tls ingress-tls --cert=./ingress-tls/tls.crt --key=./ingress-tls/tls.key
测试效果
应用资源清单文件
kubectl apply -f 04_ingress_vs_base.yaml -f 05_ingress_vs_nginx.yaml -f 06_ingress_vs_django.yaml -f 07_ingress_vs_shuji.yaml
检查命名空间
kubectl get ns | egrep 'shuji|django|nginx'
检查资源对象
kubectl get vs -n shuji
kubectl get vsr,deploy,svc -n django
kubectl get vsr,deploy,svc -n nginx
普通http检查
]# curl -k https://shuji.superopsmsb.com/nginx
Hello Nginx, nginx-7f7b4d6686-g66wh-1.23.1
]# curl -k https://shuji.superopsmsb.com/django
Hello Django, django-v1-fddf5c955-h8rrz-1.10.4
指定请求版本检查
]# curl -k --cookie "version=v1" https://shuji.superopsmsb.com/django
Hello Django, django-v1-fddf5c955-h8rrz-1.10.4
环境收尾
kubectl delete -f 07_ingress_vs_shuji.yaml -f 06_ingress_vs_django.yaml -f 05_ingress_vs_nginx.yaml -f 04_ingress_vs_base.yaml
1.3.4 四层实践
学习目标
这一节，我们从 基础知识、简单实践、小结 三个方面来学习。
基础知识
需求
Nginx ingress 不仅仅可以做http级别的ingress，还支持ip:port级别的ingress。这个功能需要GlobalConfiguration能力的支持。
准备工作
改造 deployment资源对象 deployment/nginx-ingress.yaml
...
spec:
...
template:
...
spec:
...
containers:
- image: nginx/nginx-ingress:2.4.1
...
ports:
...
- name: tcp-8001
containerPort: 8001
- name: tcp-8002
containerPort: 8002
...
args:
...
- -global-configuration=$(POD_NAMESPACE)/nginx-configuration
配置解析：
开启-global-configuration启动参数，开启专属容器端口映射
改造service资源对象 service/nodeport.yaml
...
...
spec:
externalIPs: ['10.0.0.12']
type: NodePort
ports:
...
- port: 8001
targetPort: 8001
protocol: TCP
name: tcp-8001
- port: 8002
targetPort: 8002
protocol: TCP
name: tcp-8002
配置解析：
开启专属容器端口映射
重启环境
kubectl apply -f deployment/nginx-ingress.yaml
kubectl apply -f service/nodeport.yaml
简单实践
创建基础应用环境
kubectl apply -f 01_ingress_web_resource.yaml
创建资源对象文件
创建 08_ingress_globalconfiguration_listener.yaml
apiVersion: k8s.nginx.org/v1alpha1
kind: GlobalConfiguration
metadata:
name: nginx-configuration
namespace: nginx-ingress
spec:
listeners:
- name: tcp-8001
port: 8001
protocol: TCP
- name: tcp-8002
port: 8002
protocol: TCP
创建专属的代理配置 09_ingress_transportserver.yaml
apiVersion: k8s.nginx.org/v1alpha1
kind: TransportServer
metadata:
name: nginx
spec:
listener:
name: tcp-8001
protocol: TCP
upstreams:
- name: nginx
service: nginx-svc
port: 80
action:
pass: nginx
---
apiVersion: k8s.nginx.org/v1alpha1
kind: TransportServer
metadata:
name: django
spec:
listener:
name: tcp-8002
protocol: TCP
upstreams:
- name: django
service: django-svc
port: 8000
action:
pass: django
应用资源清单文件
kubectl apply -f 01_ingress_web_resource.yaml -f 08_ingress_globalconfiguration_listener.yaml -f 09_ingress_transportserver.yaml
检查效果
]# curl 10.0.0.12:8001
Hello Nginx, nginx-7f7b4d6686-fkbbj-1.23.1
]# curl 10.0.0.12:8002
Hello Django, django-548fb788f5-pdgzw-1.10.4
环境收尾
对于globalconfiguration环境来说，这个资源千万不要删除，如果非要删除的话，可以清理该对象的配置即可，资源对象文件：10_ingress_globalconfiguration_reset.yaml
apiVersion: k8s.nginx.org/v1alpha1
kind: GlobalConfiguration
metadata:
name: nginx-configuration
namespace: nginx-ingress
spec:
清理环境
kubectl delete -f 01_ingress_web_resource.yaml -f 09_ingress_transportserver.yaml -f 10_ingress_globalconfiguration_reset.yaml
小结
1.3.5 策略实践
学习目标
这一节，我们从 基础知识、简单实践、小结 三个方面来学习。
基础知识
需求
Nginx ingress 提供了大量与waf等相关的内容，我们可以在ingress中，为不同的应用定制各自的访问策略信息。
属性解读
apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
name:
spec:
rateLimit:
rate: 100r/s # 每秒 100 个请求的速率
burst: 50 # 超过burst数量的过多的请求会被延迟。
noDelay: true # 在请求受到限制时禁用延迟过多请求。delay如果两者都设置，则覆盖。
key: ${binary_remote_addr} # 应用速率限制的键。可以是文本、变量${}或组合。
zoneSize: 10M # 设定共享内存区域的大小
rejectCode: 444 # 设置状态码以响应被拒绝的请求而返回。必须落入范围400..599。默认为503。
参考资料：
https://docs.nginx.com/nginx-ingress-controller/configuration/policy-resource/
工具部署
git clone https://github.com/wg/wrk.git wrk
cd wrk
make
cp wrk /usr/local/bin
命令帮助
语法格式: wrk <选项> <被测HTTP服务的URL>
语法参数
-c, --connections 跟服务器建立并保持的 TCP 连接数量
-d, --duration 压测时间
-t, --threads 使用多少个线程进行压测
-s, --script 指定 Lua 脚本路径
-H, --header 为每一个 HTTP 请求添加 HTTP 头
--latency 在压测结束后，打印延迟统计信息
--timeout 超时时间
-v, --version 打印正在使用的 wrk 的详细版本信息
代表数字参数，支持国际单位 (1k, 1M, 1G)
代表时间参数，支持时间单位 (2s, 2m, 2h)
简单实践
简单对象
定制资源对象 11_ingress_vs_nginx.yaml
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: shuji
spec:
host: shuji.superopsmsb.com
# policies:
# - name: rate-limit-policy
upstreams:
- name: nginx
service: nginx-svc
port: 80
routes:
- path: /
action:
pass: nginx
运行资源对象
kubectl apply -f 01_ingress_web_resource.yaml -f 11_ingress_vs_nginx.yaml
测试效果
]# wrk -t2 -c10 -d10s http://shuji.superopsmsb.com
Running 10s test @ http://shuji.superopsmsb.com # 压测时间10s）
2 threads and 10 connections # 共1个测试线程，10个连接
Thread Stats Avg Stdev Max +/- Stdev
Latency 5.48ms 4.97ms 109.56ms 93.11% # 延迟信息
Req/Sec 1.02k 229.62 1.48k 70.50% # 处理中请求
20466 requests in 10.05s, 5.44MB read # 10.05s处理20466个请求
# 读取5.44MB数据
Requests/sec: 2037.01 # 平均每秒处理完成2037.01个请求
Transfer/sec: 554.91KB # 平均每秒读取数据554.91KB
策略实践
定制策略文件 12_ingress_policy_limit.yaml
apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
name: rate-limit-policy
spec:
rateLimit:
rate: 10r/s
burst: 50
noDelay: true
key: ${binary_remote_addr}
zoneSize: 5M
rejectCode: 444
修改虚拟主机文件 11_ingress_vs_nginx.yaml
...
spec:
host: shuji.superopsmsb.com
policies:
- name: rate-limit-policy
...
应用资源清单文件
kubectl apply -f 12_ingress_policy_limit.yaml -f 11_ingress_vs_nginx.yaml
测试效果：
]# wrk -t2 -c10 -d10s http://shuji.superopsmsb.com
Running 10s test @ http://shuji.superopsmsb.com
2 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 5.72ms 3.58ms 28.40ms 83.44%
Req/Sec 11.90 35.35 282.00 98.02%
151 requests in 10.05s, 41.14KB read
Socket errors: connect 0, read 29404, write 0, timeout 0
Requests/sec: 15.02
Transfer/sec: 4.09KB
结果显示：
Requests/sec 的值从原来的 2000左右，下降到了10左右，说明限制生效了。
查看控制器pod
]# kubectl get pod -n nginx-ingress
NAME READY STATUS RESTARTS AGE
nginx-ingress-79fbbb9dc-s4qnz 1/1 Running 0 64m
查看日志效果
]# kubectl logs nginx-ingress-79fbbb9dc-s4qnz -n nginx-ingress
...
2022/10/24 06:33:31 [error] 138#138: *81481 limiting requests, excess: 50.470 by zone "pol_rl_default_rate-limit-policy_default_shuji", client: 10.244.0.1, server: shuji.superopsmsb.com, request: "GET / HTTP/1.1", host: "shuji.superopsmsb.com"
10.244.0.1 - - [24/Oct/2022:06:33:31 +0000] "GET / HTTP/1.1" 444 0 "-" "-" "-"
结果显示：
限制策略实施成功了
环境收尾
kubectl delete -f 12_ingress_policy_limit.yaml -f 11_ingress_vs_nginx.yaml -f 01_ingress_web_resource.yaml