secret配置资源管理
配置资源管理
//Secret
Secret 是用来保存密码、token、密钥等敏感数据的 k8s 资源，这类数据虽然也可以存放在 Pod 或者镜像中，但是放在 Secret 中是为了更方便的控制如何使用数据，并减少暴露的风险。
Secret 有三种类型：
●kubernetes.io/service-account-token：由 Kubernetes 自动创建，用来访问 APIServer 的 Secret，Pod 会默认使用这个 Secret 与 APIServer 通信， 并且会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中;
●Opaque ：base64 编码格式的 Secret，用来存储用户自定义的密码、密钥等，默认的 Secret 类型;
●kubernetes.io/dockerconfigjson ：用来存储私有 docker registry 的认证信息。
Pod 需要先引用才能使用某个 secret，Pod 有 3 种方式来使用 secret：
●作为挂载到一个或多个容器上的卷 中的文件。
●作为容器的环境变量。
●由 kubelet 在为 Pod 拉取镜像时使用。
应用场景：凭据
https://kubernetes.io/docs/concepts/configuration/secret/
//创建 Secret
1、用kubectl create secret命令创建Secret
echo -n 'zhangsan' > username.txt
echo -n 'abc1234' > password.txt
kubectl create secret generic mysecret --from-file=username.txt --from-file=password.txt
kubectl get secrets
NAME TYPE DATA AGE
default-token-8pqp6 kubernetes.io/service-account-token 3 3d1h
mysecret Opaque 2 51s
kubectl describe secret mysecret
Name: mysecret
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password.txt: 7 bytes
username.txt: 8 bytes
//get或describe指令都不会展示secret的实际内容，这是出于对数据的保护的考虑
2、内容用 base64 编码，创建Secret
echo -n zhangsan | base64
emhhbmdzYW4K=
echo -n abc1234 | base64
YWJjMTIzNAo==
vim secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret1
type: Opaque
data:
username: emhhbmdzYW4K=
password: YWJjMTIzNAo==
kubectl create -f secret.yaml
kubectl get secrets
NAME TYPE DATA AGE
default-token-8pqp6 kubernetes.io/service-account-token 3 3d1h
mysecret Opaque 2 43m
mysecret1 Opaque 2 6s
kubectl get secret mysecret1 -o yaml
apiVersion: v1
data:
password: YWJjMTIzNAo==
username: emhhbmdzYW4K=
kind: Secret
metadata:
creationTimestamp: 2021-05-24T09:11:18Z
name: mysecret1
namespace: default
resourceVersion: "45641"
selfLink: /api/v1/namespaces/default/secrets/mysecret1
uid: fffb7902-bc6f-11eb-acba-000c29d88bba
type: Opaque
//使用方式
1、将 Secret 挂载到 Volume 中，以 Volume 的形式挂载到 Pod 的某个目录下
vim secret-test.yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: secrets
mountPath: "/etc/secrets"
readOnly: true
volumes:
- name: secrets
secret:
secretName: mysecret
kubectl create -f secret-test.yaml
kubectl get pods
NAME READY STATUS RESTARTS AGE
seret-test 1/1 Running 0 16s
kubectl exec -it seret-test bash
password.txt username.txt
2、将 Secret 导出到环境变量中
vim secret-test1.yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod1
spec:
containers:
- name: nginx
image: nginx
env:
- name: TEST_USER
valueFrom:
secretKeyRef:
name: mysecret1
key: username
- name: TEST_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret1
key: password
kubectl apply -f secret-test1.yaml
kubectl get pods
NAME READY STATUS RESTARTS AGE
mypod1 1/1 Running 0 77s
kubectl exec -it mypod bash
zhangsan
abc1234
//ConfigMap
与Secret类似，区别在于ConfigMap保存的是不需要加密配置的信息。
ConfigMap 功能在 Kubernetes1.2 版本中引入，许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。ConfigMap API 给我们提供了向容器中注入配置信息的机制，ConfigMap 可以被用来保存单个属性，也可以用来保存整个配置文件或者JSON二进制大对象。
应用场景：应用配置
//创建 ConfigMap
1、使用目录创建
mkdir /opt/configmap/
vim /opt/configmap/game.properties
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
vim /opt/configmap/ui.properties
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
ls /opt/configmap/
game.properties
ui.properties
kubectl create configmap game-config --from-file=/opt/configmap/
//--from-file 指定在目录下的所有文件都会被用在 ConfigMap 里面创建一个键值对，键的名字就是文件名，值就是文件的内容
kubectl get cm
NAME DATA AGE
game-config 2 10s
kubectl get cm game-config -o yaml
apiVersion: v1
data:
game.properties: |
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties: |
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
creationTimestamp: 2021-05-25T06:49:18Z
name: game-config
namespace: default
resourceVersion: "87803"
selfLink: /api/v1/namespaces/default/configmaps/game-config
uid: 541b5302-bd25-11eb-acba-000c29d88bba
2、使用文件创建
只要指定为一个文件就可以从单个文件中创建 ConfigMap
--from-file 这个参数可以使用多次，即可以使用两次分别指定上个实例中的那两个配置文件，效果就跟指定整个目录是一样的
kubectl create configmap game-config-2 --from-file=/opt/configmap/game.properties --from-file=/opt/configmap/ui.properties
kubectl get configmaps game-config-2 -o yaml
kubectl describe cm game-config-2
3、使用字面值创建
使用文字值创建，利用 --from-literal 参数传递配置信息，该参数可以使用多次，格式如下
kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=good
kubectl get configmaps special-config -o yaml
apiVersion: v1
data:
special.how: very
special.type: good
kind: ConfigMap
metadata:
creationTimestamp: 2021-05-25T06:59:37Z
name: special-config
namespace: default
resourceVersion: "88610"
selfLink: /api/v1/namespaces/default/configmaps/special-config
uid: c4f45936-bd26-11eb-acba-000c29d88bba
kubectl delete cm --all
kubectl delete pod --all
//Pod 中使用 ConfigMap
1、使用 ConfigMap 来替代环境变量
vim env.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
special.how: very
special.type: good
---
apiVersion: v1
kind: ConfigMap
metadata:
name: env-config
namespace: default
data:
log_level: INFO
kubectl create -f env.yaml
kubectl get cm
NAME DATA AGE
env-config 1 6s
special-config 2 6s
//Pod的创建
vim test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-pod
spec:
containers:
- name: busybox
image: busybox:1.28.4
command: [ "/bin/sh", "-c", "env" ]
env:
- name: SPECIAL_HOW_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.how
- name: SPECIAL_TYPE_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.type
envFrom:
- configMapRef:
name: env-config
restartPolicy: Never
kubectl create -f test-pod.yaml
kubectl get pods
NAME READY STATUS RESTARTS AGE
pod-test 0/1 Completed 0 33s
kubectl logs pod-test
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.0.0.1:443
HOSTNAME=pod-test
SHLVL=1
SPECIAL_HOW_KEY=very
HOME=/root
SPECIAL_TYPE_KEY=good
KUBERNETES_PORT_443_TCP_ADDR=10.0.0.1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_PROTO=tcp
log_level=INFO
KUBERNETES_PORT_443_TCP=tcp://10.0.0.1:443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_SERVICE_HOST=10.0.0.1
PWD=/
2、用 ConfigMap 设置命令行参数
vim test-pod2.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-pod2
spec:
containers:
- name: busybox
image: busybox:1.28.4
command:
- /bin/sh
- -c
- echo "$(SPECIAL_HOW_KEY) $(SPECIAL_TYPE_KEY)"
env:
- name: SPECIAL_HOW_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.how
- name: SPECIAL_TYPE_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.type
envFrom:
- configMapRef:
name: env-config
restartPolicy: Never
kubectl create -f test-pod2.yaml
kubectl get pods
NAME READY STATUS RESTARTS AGE
test-pod2 0/1 Completed 0 34s
kubectl logs test-pod2
very good
3、通过数据卷插件使用ConfigMap
在数据卷里面使用 ConfigMap，就是将文件填入数据卷，在这个文件中，键就是文件名，键值就是文件内容
vim test-pod3.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-pod3
spec:
containers:
- name: busybox
image: busybox:1.28.4
command: [ "/bin/sh", "-c", "sleep 36000" ]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: special-config
restartPolicy: Never
kubectl create -f test-pod3.yaml
kubectl get pods
NAME READY STATUS RESTARTS AGE
test-pod3 1/1 Running 0 5s
kubectl exec -it test-pod3 sh
special.how special.type
//ConfigMap 的热更新
vim test-pod4.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: log-config
namespace: default
data:
log_level: INFO
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: my-nginx
spec:
replicas: 1
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: log-config
kubectl apply -f test-pod5.yaml
kubectl get pods
NAME READY STATUS RESTARTS AGE
my-nginx-76b6489f44-6dwxh 1/1 Running 0 46s
kubectl exec -it my-nginx-76b6489f44-6dwxh -- cat /etc/config/log_level
INFO
kubectl edit configmap log-config
apiVersion: v1
data:
log_level: DEBUG
kind: ConfigMap
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","data":{"log_level":"DEBUG"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"log-config","namespace":"default"}} #INFO 修改成 DEBUG
creationTimestamp: 2021-05-25T07:59:18Z
name: log-config
namespace: default
resourceVersion: "93616"
selfLink: /api/v1/namespaces/default/configmaps/log-config
uid: 1b8115de-bd2f-11eb-acba-000c29d88bba
//等大概10秒左右，使用该 ConfigMap 挂载的 Volume 中的数据同步更新
kubectl exec -it my-nginx-76b6489f44-6dwxh -- cat /etc/config/log_level
DEBUG
//ConfigMap 更新后滚动更新 Pod
更新 ConfigMap 目前并不会触发相关 Pod 的滚动更新，可以通过在 .spec.template.metadata.annotations 中添加 version/config ，每次通过修改 version/config 来触发滚动更新
kubectl patch deployment my-nginx --patch '{"spec": {"template": {"metadata": {"annotations": {"version/config": "20210525" }}}}}'
kubectl get pods
NAME READY STATUS RESTARTS AGE
my-nginx-665dd4dc8c-j4k9t 0/1 ContainerCreating 0 4s
my-nginx-76b6489f44-6dwxh 0/1 Terminating 0 10m
kubectl get pods
NAME READY STATUS RESTARTS AGE
my-nginx-665dd4dc8c-j4k9t 1/1 Running 0 74s
PS：更新 ConfigMap 后：
●使用该 ConfigMap 挂载的 Env 不会同步更新。
●使用该 ConfigMap 挂载的 Volume 中的数据需要一段时间（实测大概10秒）才能同步更新。
k8s的安全机制
1、客户端向服务端发送请求
2、服务端返回一个公钥证书
3、客户端查看公钥证书是否合规
4、生成随机的会话密钥对
5、对公钥加密会话密钥冰发给服务端
6、服务端用私钥解密
它可以引用role，还可引用classrole
k8s优化
Helm
什么是 Helm
在没使用 helm 之前，向 kubernetes 部署应用，我们要依次部署 deployment、svc 等，步骤较繁琐。 况且随着很多项目微服务化，复杂的应用在容器中部署以及管理显得较为复杂，helm 通过打包的方式，支持发布的版本管理和控制， 很大程度上简化了 Kubernetes 应用的部署和管理。
Helm 本质就是让 K8s 的应用管理（Deployment、Service 等）可配置，可以通过类似于传递环境变量的方式能动态生成。通过动态生成 K8s 资源清单文件（deployment.yaml、service.yaml）。然后调用 Kubectl 自动执行 K8s 资源部署。
Helm 是官方提供的类似于 YUM 的包管理器，是部署环境的流程封装。Helm 有三个重要的概念：Chart 、Repository 和 Release
●Chart：Helm 的软件包，采用 TAR 格式。类似于 APT 的 DEB 包或者 YUM 的 RPM 包，其包含了一组定义 Kubernetes 资源相关的 YAML 文件。
●Repository（仓库）：Helm 的软件仓库，Repository 本质上是一个 Web 服务器，该服务器保存了一系列的 Chart 软件包以供用户下载，并且提供了一个该 Repository 的 Chart 包的清单文件以供查询。Helm 可以同时管理多个不同的 Repository。
●Release：使用 helm install 命令在 Kubernetes 集群中部署的 Chart 称为 Release。可以理解为 Helm 使用 Chart 包部署的一个应用实例。一个 chart 通常可以在同一个集群中安装多次。每一次安装都会创建一个新的 release。
以 MySQL chart 为例，如果你想在你的集群中运行两个数据库，你可以安装该 chart 两次。每一个数据库都会拥有它自己的 release 和 release name。可以将 release 想象成应用程序发布的版本号。
总结：Helm 安装 charts 到 Kubernetes 集群中，每次安装都会创建一个新的 release。你可以在 Helm 的 chart repositories 中寻找新的 chart。
//Helm3 与 Helm2 的区别：
Helm2 是 C/S 架构，主要分为客户端 helm 和服务端 Tiller。在 Helm 2 中，Tiller 是作为一个 Deployment 部署在 kube-system 命名空间中，很多情况下，我们会为 Tiller 准备一个 ServiceAccount ，这个 ServiceAccount 通常拥有集群的所有权限。
用户可以使用本地 Helm 命令，自由地连接到 Tiller 中并通过 Tiller 创建、修改、删除任意命名空间下的任意资源。
在 Helm3 中，Tiller 被移除了。新的 Helm 客户端会像 kubectl 命令一样，读取本地的 kubeconfig 文件，使用我们在 kubeconfig 中预先定义好的权限来进行一系列操作。
Helm 的官方网站 https://helm.sh/
------------------- Helm 部署 -------------------
1、安装 helm
//下载二进制 Helm client 安装包
https://github.com/helm/helm/tags
tar -zxvf helm-v3.6.0-linux-amd64.tar.gz
mv linux-amd64/helm /usr/local/bin/helm
helm version
//命令补全
source <(helm completion bash)
2、使用 helm 安装 Chart
//添加常用的 chart 仓库，
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo add stable http://mirror.azure.cn/kubernetes/charts
helm repo add aliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
helm repo add incubator https://charts.helm.sh/incubator
//更新 charts 列表
helm repo update
helm repo list
//查看 stable 仓库可用的 charts 列表
helm search repo stable
//删除 incubator 仓库
helm repo remove incubator
//查看 chart 信息
helm show chart stable/mysql
helm show all stable/mysql
//安装 chart
helm install my-redis bitnami/redis [-n default]
helm install bitnami/redis --generate-name
//查看所有 release
helm ls
helm list
//查看指定的 release 状态
helm status my-redis
//删除指定的 release
helm uninstall my-redis
------------------- Helm 自定义模板 -------------------
charts 除了可以在 repo 中下载，还可以自己自定义，创建完成后通过 helm 部署到 k8s。
//拉取 chart
mkdir /opt/helm
cd /opt/helm
helm pull stable/mysql
ls
mysql-1.6.9.tgz
tar xf mysql-1.6.9.tgz
yum install -y tree
tree mysql
mysql
├── Chart.yaml
├── README.md
├── templates
│ ├── configurationFiles-configmap.yaml
│ ├── deployment.yaml
│ ├── _helpers.tpl
│ ├── initializationFiles-configmap.yaml
│ ├── NOTES.txt
│ ├── pvc.yaml
│ ├── secrets.yaml
│ ├── serviceaccount.yaml
│ ├── servicemonitor.yaml
│ ├── service.yaml
│ ├── ingress.yaml
│ └── tests
│ ├── test-configmap.yaml
│ └── test.yaml
└── values.yaml
可以看到，一个 chart 包就是一个文件夹的集合，文件夹名称就是 chart 包的名称。
（1）软件包自描述文件 Chart.yaml，这个文件必须有 name 和 version（chart版本） 的定义
（2）一个或多个模板，其中包含 Kubernetes 清单文件：
●NOTES.txt：chart 的“帮助文本”，在用户运行 helm install 时显示给用户
●deployment.yaml：创建 deployment 的资源清单文件
●service.yaml：为 deployment 创建 service 的资源清单文件
●ingress.yaml: 创建 ingress 对象的资源清单文件
●_helpers.tpl：放置模板助手的地方，可以在整个 chart 中重复使用
//创建自定义的 chart
helm create nginx
tree nginx
nginx
├── charts
├── Chart.yaml
├── templates
│ ├── deployment.yaml
│ ├── _helpers.tpl
│ ├── hpa.yaml
│ ├── ingress.yaml
│ ├── NOTES.txt
│ ├── serviceaccount.yaml
│ ├── service.yaml
│ └── tests
│ └── test-connection.yaml
└── values.yaml
cat nginx/templates/deployment.yaml
比如在 deployment.yaml 中定义的容器镜像：
image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
cat nginx/values.yaml | grep repository
repository: nginx
//修改 chart
vim nginx/Chart.yaml
apiVersion: v2
name: nginx
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: 1.16.0
vim nginx/values.yaml
replicaCount: 1
image:
repository: nginx
pullPolicy: IfNotPresent
tag: "latest"
imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""
serviceAccount:
create: true
annotations: {}
name: ""
podAnnotations: {}
podSecurityContext: {}
securityContext: {}
service:
type: ClusterIP
port: 80
ingress:
enabled: true
className: ""
annotations: {}
hosts:
- host: www.kgc.com
paths:
- path: /
pathType: Prefix
tls: []
resources:
limits:
cpu: 100m
memory: 128Mi
requests:
cpu: 100m
memory: 128Mi
autoscaling:
enabled: false
minReplicas: 1
maxReplicas: 100
targetCPUUtilizationPercentage: 80
nodeSelector: {}
tolerations: []
affinity: {}
//打包 chart
helm lint nginx
helm package nginx
//部署 chart
helm install nginx ./nginx --dry-run --debug
helm install nginx ./nginx -n default
或者
helm install nginx ./nginx-0.1.0.tgz
helm install nginx ./nginx -f ./nginx/values-prod.yaml
helm ls
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
nginx default 1 2022-01-18 23:43:06.170248683 +0800 CST deployed nginx-0.1.0 1.16.0
kubectl get pod,svc
NAME READY STATUS RESTARTS AGE
pod/nginx-67779bd969-kq2fm 1/1 Running 0 58m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 37h
service/nginx ClusterIP 10.100.0.171 <none> 80/TCP 58s
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/mandatory.yaml
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml
kubectl apply -f mandatory.yaml
kubectl apply -f service-nodeport.yaml
kubectl get pod,svc -n ingress-nginx
NAME READY STATUS RESTARTS AGE
pod/nginx-ingress-controller-54b86f8f7b-jjlnj 1/1 Running 0 79s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ingress-nginx NodePort 10.101.36.34 <none> 80:30665/TCP,443:30363/TCP 6s
kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
nginx <none> www.kgc.com 10.101.36.34 80 58m
vim /etc/hosts
.....
192.168.80.12 node02 www.kgc.com
curl http://www.kgc.com:30665
//修改为 NodePort 访问后，升级
vim nginx/values.yaml
service:
type: NodePort
port: 80
nodePort: 30080
ingress:
enabled: false
vim nginx/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
name: {{ include "nginx.fullname" . }}
labels:
{{- include "nginx.labels" . | nindent 4 }}
spec:
type: {{ .Values.service.type }}
ports:
- port: {{ .Values.service.port }}
targetPort: http
protocol: TCP
name: http
nodePort: {{ .Values.service.nodePort }}
selector:
{{- include "nginx.selectorLabels" . | nindent 4 }}
升级 release，release 版本加 1
helm upgrade nginx nginx
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 38h
nginx NodePort 10.100.0.171 <none> 80:30080/TCP 79m
curl 192.168.80.14:30080
//回滚
helm history nginx
helm rollback nginx 1
helm history nginx
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Tue Jan 18 23:43:06 2022 superseded nginx-0.1.0 1.16.0 Install complete
2 Wed Jan 19 01:02:42 2022 superseded nginx-0.1.0 1.16.0 Upgrade complete
3 Wed Jan 19 01:04:52 2022 deployed nginx-0.1.0 1.16.0 Rollback to 1
//在命令行使用 --set 指定参数来部署（install,upgrade）release
helm upgrade nginx nginx --set image.tag='1.15'
------------------- Helm 仓库 -------------------
helm 可以使用 harbor 作为本地仓库，将自定义的 chart 推送至 harbor 仓库。
//安装 harbor
cd /opt
cp docker-compose /usr/local/bin/
chmod +x /usr/local/bin/docker-compose
tar zxf harbor-offline-installer-v1.9.1.tgz
cd harbor/
vim harbor.yml
hostname: 192.168.80.13
harbor_admin_password: Harbor12345
data_volume: /data
chart:
absolute_url: enabled
log:
level: info
local:
rotate_count: 50
rotate_size: 200M
location: /var/log/harbor
./install.sh --with-clair --with-chartmuseum
//安装 push 插件
helm plugin install https://github.com/chartmuseum/helm-push
wget https://github.com/chartmuseum/helm-push/releases/download/v0.8.1/helm-push_0.8.1_linux_amd64.tar.gz
mkdir ~/.local/share/helm/plugins/helm-push
tar -zxvf helm-push_0.8.1_linux_amd64.tar.gz -C ~/.local/share/helm/plugins/helm-push
helm repo ls
浏览器访问：http://192.168.80.10 ，默认的管理员用户名和密码是 admin/Harbor12345
点击 “+新建项目” 按钮
填写项目名称为 “chart_repo”，访问级别勾选 “公开”，点击 “确定” 按钮，创建新项目
helm repo add harbor http://192.168.80.13/chartrepo/chart_repo --username=admin --password=Harbor12345
cd /opt/helm
helm push nginx harbor
部署 HPA
HPA（Horizontal Pod Autoscaling）Pod 水平自动伸缩，Kubernetes 有一个 HPA 的资源，HPA 可以根据 CPU 利用率自动伸缩一个 Replication Controller、 Deployment 或者Replica Set 中的 Pod 数量。
（1）HPA 基于 Master 上的 kube-controller-manager 服务启动参数 horizontal-pod-autoscaler-sync-period 定义的时长（默认为30秒），周期性的检测 Pod 的 CPU 使用率。
（2）HPA 与之前的 RC、Deployment 一样，也属于一种 Kubernetes 资源对象。通过追踪分析 RC 控制的所有目标 Pod 的负载变化情况， 来确定是否需要针对性地调整目标Pod的副本数，这是HPA的实现原理。
（3）metrics-server 也需要部署到集群中， 它可以通过 resource metrics API 对外提供度量数据。
--------------- 部署 metrics-server ---------------
●metrics-server：是kubernetes集群资源使用情况的聚合器，收集数据给kubernetes集群内使用，如kubectl、hpa、scheduler等。
//在所有 Node 节点上传 metrics-server.tar 镜像包到 /opt 目录
cd /opt/
docker load -i metrics-server.tar
//使用 helm install 安装 metrics-server
mkdir /opt/metrics
cd /opt/metrics
helm repo remove stable
helm repo add stable https://charts.helm.sh/stable
或
helm repo add stable http://mirror.azure.cn/kubernetes/charts
helm repo update
helm pull stable/metrics-server
vim metrics-server.yaml
args:
- --logtostderr
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP
image:
repository: k8s.gcr.io/metrics-server-amd64
tag: v0.3.2
//使用 helm install 安装 metrics-server
helm install metrics-server stable/metrics-server -n kube-system -f metrics-server.yaml
kubectl get pods -n kube-system | grep metrics-server
kubectl top node
kubectl top pods --all-namespaces
--------------- 部署 HPA ---------------
//在所有节点上传 hpa-example.tar 镜像文件到 /opt 目录
hpa-example.tar 是谷歌基于 PHP 语言开发的用于测试 HPA 的镜像，其中包含了一些可以运行 CPU 密集计算任务的代码。
cd /opt
docker load -i hpa-example.tar
docker images | grep hpa-example
gcr.io/google_containers/hpa-example latest 4ca4c13a6d7c 5 years ago 481MB
//创建用于测试的 Pod 资源，并设置请求资源为 cpu=200m
vim hpa-pod.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
run: php-apache
name: php-apache
spec:
replicas: 1
selector:
matchLabels:
run: php-apache
template:
metadata:
labels:
run: php-apache
spec:
containers:
- image: gcr.io/google_containers/hpa-example
name: php-apache
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
resources:
requests:
cpu: 200m
---
apiVersion: v1
kind: Service
metadata:
name: php-apache
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
run: php-apache
kubectl apply -f hpa-pod.yaml
kubectl get pods
NAME READY STATUS RESTARTS AGE
php-apache-799f99c985-5j5b4 1/1 Running 0 26s
//使用 kubectl autoscale 命令创建 HPA 控制器，设置 cpu 负载阈值为请求资源的 50%，指定最少负载节点数量为 1 个，最大负载节点数量为 10 个
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
//需要等一会儿，才能获取到指标信息 TARGETS
kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache 0%/50% 1 10 1 8m27s
kubectl top pods
NAME CPU(cores) MEMORY(bytes)
php-apache-799f99c985-5j5b4 0m 11Mi
//创建一个测试客户端容器
kubectl run -it load-generator --image=busybox /bin/sh
//增加负载
//打开一个新的窗口，查看负载节点数目
kubectl get hpa -w
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache 39%/50% 1 10 1 13m
php-apache Deployment/php-apache 54%/50% 1 10 1 13m
php-apache Deployment/php-apache 342%/50% 1 10 1 14m
php-apache Deployment/php-apache 315%/50% 1 10 4 14m
php-apache Deployment/php-apache 315%/50% 1 10 7 14m
php-apache Deployment/php-apache 315%/50% 1 10 7 14m
php-apache Deployment/php-apache 68%/50% 1 10 7 15m
php-apache Deployment/php-apache 62%/50% 1 10 7 15m
php-apache Deployment/php-apache 67%/50% 1 10 7 15m
php-apache Deployment/php-apache 67%/50% 1 10 10 15m
php-apache Deployment/php-apache 56%/50% 1 10 10 16m
php-apache Deployment/php-apache 52%/50% 1 10 10 16m
php-apache Deployment/php-apache 45%/50% 1 10 10 16m
php-apache Deployment/php-apache 34%/50% 1 10 10 16m
//如果 cpu 性能较好导致负载节点上升不到 10 个，可再创建一个测试客户端同时测试：
kubectl run -i --tty load-generator1 --image=busybox /bin/sh
//查看 Pod 状态，也发现已经创建了 10 个 Pod 资源
kubectl get pods
NAME READY STATUS RESTARTS AGE
load-generator-7d549cd44-xq5rv 1/1 Running 0 6m34s
php-apache-799f99c985-5j5b4 1/1 Running 0 20m
php-apache-799f99c985-6zn9n 1/1 Running 0 3m12s
php-apache-799f99c985-8rnqz 1/1 Running 0 101s
php-apache-799f99c985-lgth4 1/1 Running 0 2m57s
php-apache-799f99c985-nhtzv 1/1 Running 0 101s
php-apache-799f99c985-nssrp 1/1 Running 0 2m57s
php-apache-799f99c985-nx4hn 1/1 Running 0 3m12s
php-apache-799f99c985-p7h4w 1/1 Running 0 2m57s
php-apache-799f99c985-rmb9t 1/1 Running 0 3m12s
php-apache-799f99c985-xwj5p 1/1 Running 0 101s
原因是防止在业务高峰期时因为网络波动等原因的场景下，如果回收策略比较积极的话，K8S集群可能会认为访问流量变小而快速收缩负载节点数量，而仅剩的负载节点又承受不了高负载的压力导致崩溃，从而影响业务。
//资源限制 - Pod
Kubernetes对资源的限制实际上是通过cgroup来控制的，cgroup是容器的一组用来控制内核如何运行进程的相关属性集合。针对内存、CPU 和各种设备都有对应的 cgroup。
默认情况下，Pod 运行没有 CPU 和内存的限额。这意味着系统中的任何 Pod 将能够像执行该 Pod 所在的节点一样， 消耗足够多的 CPU 和内存。一般会针对某些应用的 pod 资源进行资源限制，这个资源限制是通过 resources 的 requests 和 limits 来实现。requests 为创建 Pod 时初始要分配的资源，limits 为 Pod 最高请求的资源值。
示例：
spec:
containers:
- image: xxxx
imagePullPolicy: IfNotPresent
name: auth
ports:
- containerPort: 8080
protocol: TCP
resources:
limits:
cpu: "2"
memory: 1Gi
requests:
cpu: 250m
memory: 250Mi
//资源限制 - 命名空间
1.计算资源配额
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources
namespace: spark-cluster
spec:
hard:
pods: "20"
requests.cpu: "2"
requests.memory: 1Gi
limits.cpu: "4"
limits.memory: 2Gi
2.配置对象数量配额限制
apiVersion: v1
kind: ResourceQuota
metadata:
name: object-counts
namespace: spark-cluster
spec:
hard:
configmaps: "10"
persistentvolumeclaims: "4"
replicationcontrollers: "20"
secrets: "10"
services: "10"
services.loadbalancers: "2"
K8S 会根据 limits 限制 Pod 使用资源，当内存超过 limits 时 cgruops 会触发 OOM。
这里就需要创建 LimitRange 资源来设置 Pod 或其中的 Container 能够使用资源的最大默认值
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
namespace: test
spec:
limits:
- default:
memory: 512Mi
cpu: 500m
defaultRequest:
memory: 256Mi
cpu: 100m
type: Container
