kubernetes运维笔记
目录k8s部署和应用 4一. Ansible脚本部署 41.Yum install epel-release -y 42. yum install git python-pip -y 43. 安装bug收集 4二. K8s的dashboard登录和使用 4三. k8s的DaemonSet 41. 概念: 4四. K8s的存储 4五. 域名解析 5六...
1.Yum install epel-release -y 4
2. yum install git python-pip -y 4
1.Kubectl cordon ip地址 (不能调度) 7
2) Harbor使用(73下面的/data/harbor) 17
1. 将一个目录的文件复制到另一个目录中:cp -r dir/. dir1 19
2) 在git安装文件夹内,生成秘钥,添加到gitHub秘钥里面 19
1) 老region开始下线,这里就对应了报错日志中的is not online 24
3) 老region关闭,这里就对应了报错日志中的is closing 24
3) 发现失效的region server并重新分配其上的region 24
1. 配置Tomcat的https访问,配置ssl安全证书 25
Centos7安装
Root用户执行脚本
Yum update
#安装python:yum install python -y
# pip安装ansible(国内如果安装太慢可以直接用pip阿里云加速)
#pip install pip --upgrade
#pip install ansible
pip install pip --upgrade -i http://mirrors.aliyun.com/pypi/simple/ --trusted-host mirrors.aliyun.com
pip install --no-cache-dir ansible -i http://mirrors.aliyun.com/pypi/simple/ --trusted-host mirrors.aliyun.com
Ssh 免密登录 root权限的设置500就好了
- 在部署dashboard时,展示页面和主节点部署在一起,如果部署在计算节点上回出现错误dial tcp 172.20.102.147:8443: connect: invalid argument,然后去看dashboard.yaml文件,它是部署在主节点上
- 进入dashboard的账号和密码: admin和test1234
- 需要token验证--输入:kubectl -n kube-system describe secret $(kubectl -n kube-system get secret |grep admin-user | awk ‘{print $1}’)
DaemonSet能够让所有(或者特定)的节点运行同运行同一个pod
当节点加入到k8s集群中,pod会被(DaemonSet)调度到该节点上运行,当节点从k8s集群中被移除,被DaemonSet调度的pod会被移除,如果删除DaemonSet相关的Pods都会被删除
在某种程度上,DaemonSet承担了RC的部分功能,它也能保证相关pods持续运行,如果一个DaemonSet的Pod被杀死、停止、或者崩溃,那么DaemonSet将会重新创建一个新的副本在这台计算节点上
一般应用于日志收集,监控采集,分布式储存守护进程,ingress等
emptyDir
EmptyDir是一个空目录,他的生命周期和所属的 Pod 是完全一致的,可能读者会奇怪,那还要他做什么?EmptyDir的用处是,可以在同一 Pod 内的不同容器之间共享工作过程中产生的文件。
缺省情况下,EmptyDir 是使用主机磁盘进行存储的,也可以设置emptyDir.medium 字段的值为Memory,来提高运行速度,但是这种设置,对该卷的占用会消耗容器的内存份额
查看域名解析nslookup kubernetes.default
测试验证dns服务
- 新建一个测试nginx服务:kubectl run nginx --image=nginx --expose --port=80
确认nginx服务:kubectl get pod | grep nginx
Kubectl get svc | grep nginx
- 测试pod busybox
备注: 使用kubectl run b1 -it --rm --image=alpine /bin/sh 进行nslookup <svc>; nslookup <svc>.<namespace>
使用自己的dns进行解析
将由”foo.yml”配置文件中指定的资源对象和名称标识的Pod资源副本设为3
Kubectl scale --replicas=3 -f foo.yml
如果当前副本数为2,则将其扩展至3
Kubectl scale --current-replicas=2 --replicas=3 deployment/mysql
如果在一个命名空间中,当一个pod处于pending状态,命名空间会存在删除不了情况(处于游离状态的Pod)
kubectl delete pod -n monitoring monitor-prometheus-node-exporter-vskz7 --grace-period=0 --force
Kubectl expose
将资源暴露为新的kubernetes Service
指定deployment,service,replica set,replication controller或pod, 并使用该资源的选择器作为指定端口上新服务的选择器。Deployment或replica set只有当其选择器可转换为service支持的选择器时,即当选择器仅包含matchLabels组件时才会作为暴露新的Service
语法:expose (-f filename | type name) [--port=port][--protocol=TCP|UDP ][--target-port=number-or-name][--name=name][--external-ip=external-ip-of-service][--type=type]
语法解释:--type有三种类型:ClusterIp:使用一个集群固定IP,这个是默认选项;
NodePort:使用一个集群固定IP,但是额外在每个POD上均暴露这个服务,端口(支持TCP和UDP) LoadBalancer: 使用集群固定IP,和NodePort,额外还会申请一个负载均衡器来转发到服务(loadbalancer)(1.0仅支持TCP)
1.错误原因:没有配置args参数,拿不到配置中心的数据和不能向服务注册中心注册:
Command和args可以实现覆盖Dockerfile中的ENTRYPOINT功能。具体的command代表ENTRYPOINT的命令行,而args代表具体参数。
完整的分类
- 如果command和args均没写,那么使用Docker默认配置
- 如果command写了,但args没有写,那么Docker默认的配置会被忽略而且仅仅执行.yaml文件的command(不带任何参数)(错在这个地方了)
- 如果command没写,但args写了,那么Docker默认配置的ENTRYPOINT的命令行会被执行,但是调用的参数是.yaml中的args
- 如果command和args都写了,那么Docker默认的配置被忽略,使用.yaml的配置
Kubectl uncordon ip地址 (可以调度)
docker run -it --rm -v $(pwd):/bak --entrypoint sh pinpointdocker/pinpoint-agent:1.8.0
运行在该节点上,服务运行了什么命令docker ps --no-trunc |grep hello
调试镜像:docker run -it --rm --entrypoint sh harbor.ownerprivate.com/library/pinpoint-agent:1.5.2
调式pod:kubectl exec -it web-1 hostname
kubectl exec -n ams ams-auth-server-deploy-bcdc9fbc-tj4sg -- cat /etc/hosts
调式docker容器:
nsenter --net=$(docker inspect 45562e853b30 -f '{{.State.Pid}}') ip a
Kubectl删除Pod:kubectl delete deployment podname
Kubectl 删除service:kubectl delete service nginx
删除pod的状态为Evicted的容器
kubectl get pods -n ams | grep Evicted | awk '{print $1}'
Kubectl delete pods xxx
运行情况备注:
1.Agent 现在upms,Hello用的是1.8.0的探针,而其他业务用的是1.5.2版本的探针
2.Web:1.5.2 运行的1.8.0 收不到请求,现在用1.5.2来试一下
3.Collector 现在目前是1.8.0,收集器换成1.5.2的试一下,测试的结果:1.8.0的版本和1.5.2的收集器都收集不到数据,而使用本地的collector是可以收到的,这就说明了一个问题,collector需要与主机共享网络,部署collector需要加hostNetwork: true
重启k8s
在master上执行
systemctl restart kube-apiserver.service
Systemctl restart kube-controller-manager.service
Systemctl restart kube-scheduler.service
在node上执行:
Systemctl restart kubelet.service
Systemctl restart kube-proxy.service
查看终结容器的问题
Kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99
资源配额,通过ResourceQuota对象来定义,对每个namespace的资源消耗总量提供限制。它可以按类型限制namespace下可以创建的对象的数量,也可以限制可被该项目以资源形式消耗的计算资源总量。
启用资源配额:资源配额的支持在很多kubernetes版本中是默认开启的。当apiserver的--admission-control=参数中包含ResourceQuota时,资源配额会被启用当namespace中存在一个ResourceQuota对象时,该namespace即开始实施资源配额管理。一个namespace中最多只应存在一个ResourceQuota对象
Kubectl create namespace quota-mem-cpu-example
删除这个命名空间
Kubectl delete namespace quota-mem-cpu-example
用户可以对给定namespace下的计算资源总量进行限制
配额机制所支持的资源类型:
Cpu 所有非终止状态的Pod中,其cpu需求总量不能超过该值
Limits.cpu 所有非终止状态的Pod中,其cpu限额总量不能超过该值
Limits.memory 所有非终止状态的Pod中,其内存限额总量不能超过该值
Memory 所有非终止状态的Pod中,其内存需求总量不能超过该值
Requests.cpu 所有非终止状态的Pod中,其内存需求总量不能超过该值
Requests.memory 所有非终止状态的Pod中,其内存需求总量不能超过该值
用户可以对给定namespace下的存储资源总量进行限制
此外,还可以根据相关的存储类(Storage Class)来限制存储资源的消耗
Requests.storage 所有的pvc中,存储资源的需求不能超过该值
Persistentvolumeclaims namespace中所允许的pvc总量
<storage-class-name>.storageclass.storage.k8s.io/requests.storage 所有该storage-class-name相关的pvc中,存储资源的需求不能超过该值
<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims namespace中所允许的该storage-class-name相关的pvc的总量
例如,如果一个操作人员针对“黄金”存储类型与“铜”存储类型设置配额,操作员可以定义配额如下:
Gold.storageclass.storage.k8s.io/requests.storage: 500Gi
Bronze.storageclass.storage.k8s.io/requests.storage: 100Gi
给定类型的对象数量可以被限制。支持一下类型:
Configmaps namespace下允许存在的configmap的数量
Persistentvolumeclaims namespace下允许存在的pvc的数量
Pods namespace下允许存在的非终止状态的pod数量。如果pod的status.phase为failed或者succeeded,那么其处于终止状态
Replicationcontrollers namespace下允许存在的replication controllers的数量
Resourcequotas namespace下允许存在的resource quotas的数量
Services namesapce下允许存在的service的数量
Services.loadbalancers namespace下允许存在的loadbalancer类型的service的数量
Services.nodeports namespace下存在的node port类型的service的数量
Secrets namespace下允许存在的secret的数量
例如 pods配额统计并保证单个namespace下创建pods的最大数量
用户可能希望在namespace中为pod设置配额,来避免有用户创建很多小的pod,从而耗尽集群提供的pod ip地址
每个配额都有一组相关的作用域(scope),配额只会对作用域内的资源生效
当一个作用域被添加到配额中后,它会对作用域相关的资源数量作限制。如配额中指定了允许(作用域)集合之外的资源,会导致验证错误
Terminating 匹配spec.activeDeadlineSeconds >= 0的pod.
NotTerminating 匹配spec.activeDeadlineSeconds is nil 的pod
BestEffort 匹配“尽力而为(best effort)”服务类型的pod
NotBestEffort 匹配非“尽力而为(best effort)”服务类型的pod
BestEffort作用域限制配额跟踪一下资源:pods
Terminating、NotTerminating和NotBestEffort限制配额跟踪一下资源
Cpu
Limits.cpu
Limits.memory
Memory
Pods
Requests.cpu
Requests.memory
分配计算资源时,每个容器可以为cpu或内存指定请求和约束。也可以设置两者中的任何一个
如果配额中指定了requests.cpu或者requests.memory的值,那么它要求每个进来的容器针对这些资源有明确的请求。如果配额中指定了limits.cpu或limits.memory的值,那么它要求每个进来的容器针对这些资源指定明确的约束
配额对象是独立于集群容量的。它们通过绝对的单位来表示。所以,为集群添加节点,不会自动赋予每个namespace消耗更多资源的能力。如:
在几个团队中按比例划分总的集群资源
允许每个租户根据需要增加资源使用量,但要有足够的限制以防意外资源耗尽
在namespace中添加节点,提高配额的额外需求
这些策略可以基于ResourceQuata,通过编写一个检测配额使用,并根据其他信号调整各namespace下的配额硬性限制的“控制器”来实现
*** 资源配额对集群资源总体进行划分,但它对节点没有限制:来自多个namespace的pod可能在同一节点上运行
默认配置:
Pod-2
设置了内存限制请求,没设置内存请求
Pod-3
设置了内存请求,没设置内存限制请求
Quato-pod.yaml文件
Quota-pod-deployment.yaml
总结:资源配额中有给命名空间中所有资源的限额(Pod的总和),也有对Pod这一类的资源限额。我们在计算资源(内存,cpu),储存资源,Pod数量,service的数量等进行限制
访问prometheus的web页面:http://$NodeIP:39000
访问alertmanager的web页面:http://$NodeIP:39001
访问grafana的web页面:http://$NodeIP:39002(默认用户密码admin:admin,可在web页面修改,我修改为admin)
升级(或者修改配置):修改配置请在prom-settings.yaml prom-alertsmanager.yaml等文件中进行,保存后执行
#修改prometheus
$ helm upgrade --tls monitor -f prom-settings.yaml -f prom-alertsmanager.yaml -f prom-alertrules.yaml prometheus
#修改grafana
$ helm upgrade --tls grafana -f grafana-settings.yaml -f grafana-dashboards.yaml grafana
回退:参考helm help rollback文档
$ helm rollback --tls monitor [REVISION]
删除
helm del --tls monitor --purge
Helm del --tls grafana --purge
#创建deploy和service
Kubectl run nginx1 --image=nginx --port=80 --expose --limits=’cpu=500m,memory=4Mi’
#增加负载kubectl run --rm -it load-generator --image=busybox /bin/sh
While true; do wget -q -O- http://nginx1; done;
可以查看etcd的证书
启动harbor: docker-compose up -d
停止harbor:
登录harbor的地址:https://192.168.20.73/harbor/sign-in
账号密码:admin Harbor12345
- harbor镜像远程复制
#Use an official Python runtime as a parent image
FROM python:2.7-slim
#Set the working directory to /app
WORKDIR /app
#Copy the current directory contents into the container at /app
COPY . /app
#Install any needed packages specified in requirements.txt
RUN pip installl --trusted-host pypi.python.org -r requirements.txt
#Make port 80 available to the world outside this container
EXPOSE 80
#Define environment variable
ENV NAME World
#Run app.py when the container launches
CMD [“python”,”app.py”]
服务网格:是一个基础设施层,功能在于处理服务间通信,职责是负责实现请求的可靠传递。在实践中,服务网格通常实现为轻量级网络代理,通常与应用部署在一起,他们之间是远程调用
配置登录git
Git config --global user.email “1843440836@qq.com”
Git config --global user.name “qihao”
git status --查看本地,本地仓库,缓存(stash)的文件修改状态
git add . --添加新的文件,加点表示该文件夹下的所有文件,加上具体的文件,就只上传该文件
git commit -m update 提交文件,需要改注释
git push origin master推代码
Linux git 常用命令使用:
提交分支截图
拉取分支:
git fetch origin branchname:branchname
可以把远程某各分支拉去到本地的branchname下,如果没有branchname,则会在本地新建branchname
Windows中提交代码
查询是否安装vim,rpm -qa |grep vim
出现vim-minimal-7.4.160-1.el7.x86_64
安装vim
Yum -y install vim*
scp /opt/soft/nginx-0.5.38.tar.gz root@192.168.120.204:/opt/soft/scptest
chown -R qihao:qihao elasticsearch-5.6.0
-y 覆盖文件
当前目录的所有文件:sed -i “s/namespace: monitoring/namespace: kube-monitoring/g” *
当前目录的sed -i "s/查找字段/替换字段/g" `grep 查找字段 -rl 路径` 文件名
使用hostnamectl命令
/var/log/message 系统启动后的信息和错误日志,是最常用的日志
/var/log/secure 与安全相关的日志信息
/var/log/maillog 与邮件相关的日志信息
/var/log/cron 与定时任务相关的日志信息
/var/log/spooler 与UUCP和news设备相关的日志信息
/var/log/boot.log 守护进程启动和停止相关的日志消息
/var/log/wtmp 该日志文件永久记录每个用户登录,注销及系统的启动,停机的事件
Jdk环境配置:jdk8
Hbase集群地192.168.10.204:2181,192.168.20.65:2181,192.168.20.202:2181
Hbase的环境变量配置:
1.在hbase的conf/hbase-env.sh加入jdk安装地址
2.修改hbase的hbase-site.xml数据存储路径:指定rootdir参数
3.启动hbase: ./start-hbase.sh
执行pinpoint提供的Hbase初始化语句,会初始化一会
> ./hbase shell /home/pp_res/hbase-create.hbase
执行完了以后,进入Hbase
> ./hbase shell
输入”status ‘detailed’”可以看到初始化的表,看是否存在
- Pinpoint中连接的HBASE中的hadoop需要自己手动退出安全模式
- Hbase的数据库需要进行初始化,文件路径:https://raw.githubusercontent.com/naver/pinpoint/1.8.0/hbase/scripts/hbase-create.hbase
- org.apache.hadoop.hbase.NotServingRegionException: org.apache.hadoop.hbase.NotServingRegionException: Region is not online:
可能原因1:zookeeper引起的,通常这种情况往往是在你正在运行一个进程正在操作hbase数据库的时候,hbase服务被停掉所引起的,如果是hbase自身管理的zookeeper
方法1:可以将hbase的zookeeper目录下的文件全都删除掉,然后再在重启hbase服务就可以了
方法2:检查一下是否只有master创建了zookeeper目录
注释:配置zookeeper的目录为属性hbase.zookeeper.property.dataDir
- pinpoint-web的版本也有问题,目前使用的是1.5.2,之前安装的版本1.8.0
在pinpoint-web中Dockerfile
- 如果服务和主机共享网络,pinpoint追踪不到,域名解析的问题
- 现在解决zk,hbase,collector和agent之间的通信
- Pinpoint-collector 需要修改的配置文件:
在hbase.properties文件:hbase.client.host 设置hbase所用的zk地址
在pinpoint-collector.properties文件:cluster.zookeeper.address修改为给Pinpoint准备的zk地址
- pinpoint-web需要修改的配置文件
在hbase.properties文件: hbase.client.host设置为hbase所用的zk地址
在pinpoint-web.properties文件: cluster.zookeeper.address修改为给pinpoint准备的zk地址
9.zookeeper配置好集群后,在web和collector中配置,可以出现链路状态,容器化部署zookeeper
1.
- .在hbase中,切换Zookeeper的HBase管理,使用conf/hbase-env.sh中的HBASE_MANAGES_ZK变量,此变量默认为true,告诉HBase是否启动/停止Zookeeper集合服务器作为HBase启动/停止的一部分,jps会看到HQuorumPeer表示hbase管理的zookeeper;如果设置为false,则表示独立的Zookeeper管理,jps会看到QuorumPeerMain表示zookeeper独立的进程
- Hbase重启,251的hbase
步骤:
- hbase报错
1.org.apache.hadoop.hbase.ipc.ServerNotRunningYetException: Server is not running yet 原因是hadoop的hdfs集群在安全模式的原因
解决办法:在hadoop的bin目录下:hdfs dfsadmin -safemode leave
Hadoop dfsadmin -safemode leave
- hbase的NotServingRegionException 当Hbase运行时候,region达到了设置的文件大小后,就要开始分裂。分裂的过程是:
解决办法:在hadoop的bin目录下,执行hadoop fsck / 或者 hadoop fsck /hbase/data检查数据健康状况。
没有冗余备份,删除损坏的文件,使用命令hadoop fsck -delete
在次检查数据是heathy,则重启hbase
- 分布式hbase协调工作说明
Zookeeper
- 保证任何时候,集群中只有一个master
- 存储所有region的寻址入口
- 实时监控region server的状态,将region server的上线和下线信息实时通知给master
- 存储hbase的schema,包括有哪些table,每个table有哪些column family
Master
Region server
- Region server 维护Master 分配给它的region,处理对这些region的IO请求
- Region server 负责切分在运行过程中变得过大的region
- 在datadir目录下需要配置myid,对应 的顺序
- 在conf/zoo.cfg目录下配置zk的集群地址
- 启动zookeeper: ./bin/zkServer.sh start conf/zoo.cfg
配置的zookeeper集群地址
Leader: 192.168.20.168
Foller: 192.168.20.73
Foller: 192.168.20.98
- flink 安装地址官网
- Flink的启动:./start-cluster.sh 停止:./stop-cluster.sh
- 启动flink中例子在examples中 ./bin/flink run examples/streaming/SocketWindowWordCount.jar --port 9000
Tomcat7以上支持两种证书一种是keytool生成,一种是pfx格式的证书
Python导入自定义模块,用import导入其他模块需要在sys.path.append(“添加路径”);
kafka服务器消息存储策略
生产者和消费者进行交互的过程:
运行kafka步骤:
cd 进入kafka解压目录,输入
bin/zookeeper-server-start.sh config/zookeeper.properties
cd 进入kafka解压目录,输入
bin/kafka-server-start.sh config/server.properties
Kafka通过topic对同一类的数据进行管理,同一类的数据使用同一个topic可以在处理数据时更加的便捷
bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test
在创建topic后可以通过输入
bin/kafka-topics.sh --list --zookeeper localhost:2181
来查看已经创建的topic
在kafka解压目录打开终端,输入
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning 可以创建一个用于消费topic为test的消费者
在kafka解压目录打开一个新的终端,输入
Bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
Vim /etc/profile
Source /etc/profile
# go veriosn
# go run main.go
# go run ./main.go
- 部署kubernetes的CI/CD流程
Docker创建镜像仓库的秘钥
Gitlab 持续集成和持续部署CI/CD架构图:
- 查看gitlab版本
/opt/gitlab/embedded/bin/psql --version
- 编写progresSQL_sonarqube.yml
#这是一个利用docker-compose来构建【sonarqube6.7+PostgreSQL】环境的yml文件 #sonarqube6.7的登录用户和密码均为admin,登录页面port为9000。 #PostgreSQL数据库的用户和密码均为sonar[可以在浏览器输入ip+8088或navicat工具访问数据库]。 #-------------------------------------------------------------------------------- #--------------------------------------------------------------------------------
version: "3.3"
services:
db:
image: postgres
container_name: postgres
ports:
- "5432:5432"
environment:
- POSTGRES_USER=sonar
- POSTGRES_PASSWORD=sonar
adminer:
image: adminer
restart: always
ports: - 8088:8080
sonarqube6.7:
image: jamesz2011/sonarqube6.7:latest
container_name: sonarqube
ports:
- "9000:9000"
- "9092:9092"
volumes:
- /etc/localtime:/etc/localtime:ro
links:
- db
environment:
- SONARQUBE_JDBC_URL=jdbc:postgresql://db:5432/sonar
在写yml文件的过程中,sonar-scanner对资源的检测路径-Dsonar.java.binaries=target/classes以为是target/classes,它的路径为target/sonar
查看docker下挂载的目录
docker volume ls
docker volume inspect container_id
安装sonarqube汉化版 -- 1.将插件复制到/opt/sonarqube/extensions/plugins/ 目录下;2在配置-->系统--> Installed 有Chinese Pack 点击安装
更多推荐
所有评论(0)