安装

docker

1
2
3
4
5
6
7
8
9
10
11

docker run \
    --detach \
    --hostname gitlab.qh.com \
    --publish 2222:22 \
    --publish 80:80 \
    --name gitlab \
    --restart unless-stopped \
    -v /data/gitlab/etc:/etc/gitlab \
    -v /data/gitlab/log:/var/log/gitlab \
    -v /data/gitlab/data:/var/opt/gitlab \
    gitlab/gitlab-ce:13.6.3-ce.0

Gitlab官方提供了 Helm 的方式在 Kubernetes 集群中来快速安装，但是在使用的过程中发现 Helm 提供的 Chart 包中有很多其他额外的配置，所以我们这里使用自定义的方式来安装，也就是自己来定义一些资源清单文件。

Gitlab主要涉及到3个应用：Redis、Postgresql、Gitlab 核心程序，实际上我们只要将这3个应用分别启动起来，然后加上对应的配置就可以很方便的安装 Gitlab 了，我们这里选择使用的镜像不是官方的，而是 Gitlab 容器化中使用非常多的一个第三方镜像：sameersbn/gitlab，基本上和官方保持同步更新，地址：http://www.damagehead.com/docker-gitlab/

https://github.com/sameersbn/docker-gitlab

官方仓库：

https://github.com/argoproj/argo-cd

安装

1
2
3
4
5
6
7
8

kubectl create namespace argocd
#Non-HA:
wget https://raw.githubusercontent.com/argoproj/argo-cd/v1.8.1/manifests/install.yaml -O argo-cd.yaml
#HA:
wget https://raw.githubusercontent.com/argoproj/argo-cd/v1.8.1/manifests/ha/install.yaml -O argo-cd.yaml
#替换镜像
sed -i -e 's?image: argoproj?image: dockerhub.azk8s.cn/argoproj?g'  -e 's?quay.io?quay.azk8s.cn?g' -e 's?k8s.gcr.io?gcr.azk8s.cn/google-containers?g'  argo-cd.yaml
kubectl apply -n argocd -f argo-cd.yaml

CI/CD并不是陌生的东西，大部分企业都有自己的CI/CD，不过今天我要介绍的是使用Jenkins和GitOps实现CI/CD。

整体架构如下：

Calico 网络通信解析

在 Kubernetes 集群中，Calico 区别于 Flannel 的最显著特征，就是其宣称可以不借助隧道技术，是建立在纯三层协议上的解决方案。也就是说，Calico 通过建立一些路由信息，就构建了单节点/多节点网络命名空间隔离下的通信网络。

网上很多支持grafana导入导出的小工具/脚本，此处采用 https://gist.github.com/crisidev/bd52bdcc7f029be2f295

一般定时备份/var/lib/grafana文件夹就可以

1.grafana中获取api key

2.脚本中使用到 jq tr命令，需要提前安装

3.脚本使用 sh grafana_db_bak.sh $host $key

jps

Java版的ps命令，查看java进程及其相关的信息，如果你想找到一个java进程的pid，那可以用jps命令替代linux中的ps命令了，简单而方便。

命令格式：

jps [options] [hostid]

options参数解释：

• -l : 输出主类全名或jar路径
• -q : 只输出LVMID
• -m : 输出JVM启动时传递给main()的参数
• -v : 输出JVM启动时显示指定的JVM参数

最常用示例：

1
2
3

jps -l 输出jar包路径，类全名
jps -m 输出main参数
jps -v 输出JVM参数

1.安装

1

yum -y install httpd

2.过程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

[root@apiserver local]# mkdir basic-auth
[root@apiserver local]# cd basic-auth/
[root@apiserver basic-auth]# ls
[root@apiserver basic-auth]# htpasswd -c auth foo
New password:
Re-type new password:
Adding password for user foo
[root@apiserver basic-auth]# kubectl create secret generic basic-auth --from-file=auth
secret/basic-auth created

[root@apiserver basic-auth]# vim ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-with-auth
annotations:

nginx.ingress.kubernetes.io/auth-type: basic
nginx.ingress.kubernetes.io/auth-secret: basic-auth
nginx.ingress.kubecnetes.io/auth-realm: ‘Authentication Required - foo’ #  foo对应用户名
spec:
rules:

1

故障现象

kubelet 启动不了，通过命令 journalctl -u kubelet 查看日志，报 Failed to start ContainerManager failed to initialize top level QOS containers: failed to update top level Burstable QOS cgroup : failed to set supported cgroup subsystems for cgroup [kubepods burstable]: failed to find subsystem mount for required subsystem: pids

如果你经常使用 Kubernetes，那么应该对 Helm 和 Kustomize 不陌生，这两个工具都是用来管理 Kubernetes 资源清单的，但是二者有着不同的工作方式。

Helm 使用的是模板，一个 Helm Chart 包中包含了很多模板和值文件，当被渲染时模板中的变量会使用值文件中对应的值替换。而 Kustomize 使用的是一种无模板的方式，它对 YAML 文件进行修补和合并操作，此外 Kustomize 也已经被原生内置到 kubectl 中了。这两个工具在 Kubernetes 的生态系统中都被广泛使用，而且这两个工具也可以一起结合使用。