ArgoCD HelloWorld
这里使用的是测试仓库(private)
https://github.com/zl86790/argocdtest.git
注意这个仓库不能为空,否则一会儿会被提示一个 empty repository错误
使用argocd连接这个repo
选择Repository
选择 CONNECT REPO USING SSH
ssh-keygen -t rsa -b 4096
id_rsa -> argocd
id_rsa.pub -> github
会得到如下连接
创建一个 application
配置如下
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: argocdtest
spec:
destination:
name: ''
namespace: ''
server: 'https://kubernetes.default.svc'
source:
path: ./
repoURL: 'git@github.com:zl86790/argocdtest.git'
targetRevision: HEAD
project: default
syncPolicy:
automated: null
在repo中追加一个新文件
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
namespace: argocdtest
spec:
selector:
matchLabels:
app: web_server
replicas: 2
template:
metadata:
labels:
app: web_server
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
点击 REFRESH 会看到
点击 同步 SYNC
可以看到Nginx已经正确部署了
ArgoCD安装
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl port-forward --address 0.0.0.0 svc/argocd-server -n argocd 8000:443
用户名 admin
密码是 Pod 名
kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o name | cut -d'/' -f 2
argocd-server-86f7f94488-pv2zk
不过我这里不好用,查看了一下 secrets 发现密码是 HclJUPjSiSwmWZpC
Microk8s helm rancher
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
kubectl create namespace cattle-system
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.0.4/cert-manager.crds.yaml
kubectl create namespace cert-manager
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install \
cert-manager jetstack/cert-manager \
--namespace cert-manager \
--version v1.0.4
helm install rancher rancher-latest/rancher \
--namespace cattle-system \
--set hostname=rancher.lizhe.com
Sonarqube pipeline
pipeline {
agent none
environment {
SONAR_LOGIN='xxxxxxxxxxxxxxxxxxxxxx'
}
stages {
stage ('Checkout') {
agent any
steps {
sh "rm -rf /var/jenkins_home/workspace/${env.JOB_NAME}/*"
git branch: 'develop', credentialsId: 'xxxxxxxxxxxxxxxxxxxx', url: 'https://github.com/xxxxxx/xxxxxxxx.git'
}
}
stage('Scan') {
agent {
docker {
image 'docker:20.10.6'
args "-v /var/run/docker.sock:/var/run/docker.sock -v /var/jenkins_home/workspace/${env.JOB_NAME}/:/usr/src"
}
}
steps {
dir("/var/jenkins_home/workspace/${env.JOB_NAME}/") {
sh """
ls /usr/src
rm -rf /usr/src/*
ls /usr/src
ls /var/jenkins_home/workspace/${env.JOB_NAME}
cp -r /var/jenkins_home/workspace/${env.JOB_NAME}/* /usr/src/
ls /usr/src
docker run --rm -e SONAR_HOST_URL="http://10.10.10.198:9000/" -e SONAR_LOGIN='${env.SONAR_LOGIN}' -v /var/jenkins_home/workspace/${env.JOB_NAME}/:/usr/src sonarsource/sonar-scanner-cli \
-Dsonar.projectKey=app-sonarqube -Dsonar.sources=./
"""
}
}
}
}
}
Microk8s prometheus operator
microk8s enable prometheus
如果安装过程中报错,尝试删除相关文件夹
sudo rm -rf /var/snap/microk8s/2262/kube-prometheus
使用 kubectl port-forward 登入
microk8s kubectl port-forward grafana-6b8df57c5b-z626n 3000:3000 -n monitoring
输入系统刚才提示的密码
admin/admin
创建一个 nodeport
kind: Service
apiVersion: v1
metadata:
name: grafananp
namespace: monitoring
labels:
app: grafana
spec:
ports:
- name: http
protocol: TCP
port: 3000
targetPort: 3000
nodePort: 30036
selector:
app: grafana
type: NodePort
sessionAffinity: None
externalTrafficPolicy: Cluster
Microk8s HA
要使用 Microk8s 的 HA 模式需要
- To install a 1.19+ version of MicroK8s
- At least three nodes.
- From the 1.19 release of MicroK8s, HA is enabled by default.
如果需要手动打开的话
microk8s enable ha-cluster
在 Microk8s 的基础上,添加第三个节点
直接使用之前的token
Connection failed. Invalid token (500).
似乎是因为 token是一次性的
那我们只好在 master 节点上再生成一个
microk8s join 192.168.194.196:25000/34ba363719e5d802aed9084a059ead75/c11a38c71679
可以看到
报错的 microk8s join 192.168.194.196:25000/24bfc55c51720b62f15caefb95a8f211/c11a38c71679
新生的 microk8s join 192.168.194.196:25000/34ba363719e5d802aed9084a059ead75/c11a38c71679
此时系统提示的master节点是3个
如果要从集群中移除节点,有两种方式
在要被移除的节点上调用
microk8s leave
此时从集群上还能看见这个node
microk8s remove-node mk8s3
直接remove而不使用 leave 会报错
由于节点数从 3 变成了 2 ,master节点从3变成了1
控制平面组件(Control Plane Components)
控制平面的组件对集群做出全局决策(比如调度),以及检测和响应集群事件(例如,当不满足部署的 replicas 字段时,启动新的 pod)。
控制平面组件可以在集群中的任何节点上运行。 然而,为了简单起见,设置脚本通常会在同一个计算机上启动所有控制平面组件, 并且不会在此计算机上运行用户容器。 请参阅使用 kubeadm 构建高可用性集群 中关于多 VM 控制平面设置的示例。
kube-apiserver
API 服务器是 Kubernetes 控制面的组件, 该组件公开了 Kubernetes API。 API 服务器是 Kubernetes 控制面的前端。
Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平伸缩,也就是说,它可通过部署多个实例进行伸缩。 你可以运行 kube-apiserver 的多个实例,并在这些实例之间平衡流量。
etcd
etcd 是兼具一致性和高可用性的键值数据库,可以作为保存 Kubernetes 所有集群数据的后台数据库。
您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。
要了解 etcd 更深层次的信息,请参考 etcd 文档。
kube-scheduler
控制平面组件,负责监视新创建的、未指定运行节点(node)的 Pods,选择节点让 Pod 在上面运行。
调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。
kube-controller-manager
在主节点上运行 控制器 的组件。
从逻辑上讲,每个控制器都是一个单独的进程, 但是为了降低复杂性,它们都被编译到同一个可执行文件,并在一个进程中运行。
这些控制器包括:
节点控制器(Node Controller): 负责在节点出现故障时进行通知和响应
任务控制器(Job controller): 监测代表一次性任务的 Job 对象,然后创建 Pods 来运行这些任务直至完成
端点控制器(Endpoints Controller): 填充端点(Endpoints)对象(即加入 Service 与 Pod)
服务帐户和令牌控制器(Service Account & Token Controllers): 为新的命名空间创建默认帐户和 API 访问令牌
cloud-controller-manager
云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器允许您链接集群到云提供商的应用编程接口中, 并把和该云平台交互的组件与只和您的集群交互的组件分离开。
cloud-controller-manager 仅运行特定于云平台的控制回路。 如果你在自己的环境中运行 Kubernetes,或者在本地计算机中运行学习环境, 所部署的环境中不需要云控制器管理器。
与 kube-controller-manager 类似,cloud-controller-manager 将若干逻辑上独立的 控制回路组合到同一个可执行文件中,供你以同一进程的方式运行。 你可以对其执行水平扩容(运行不止一个副本)以提升性能或者增强容错能力。
下面的控制器都包含对云平台驱动的依赖:
节点控制器(Node Controller): 用于在节点终止响应后检查云提供商以确定节点是否已被删除
路由控制器(Route Controller): 用于在底层云基础架构中设置路由
服务控制器(Service Controller): 用于创建、更新和删除云提供商负载均衡器