分类目录归档:云运维

阿里云ecs在线不停机扩展硬盘

1.选择ecs的磁盘,选择在线扩容-扩容大小-付费

2.安装相应工具
centos系列

yum install cloud-utils-growpart
yum install xfsprogs

ubuntu、debian系列:

apt install cloud-guest-utils
apt install xfsprogs

下面示范将vda设备的第一个分区扩容

3.扩展a步骤
growpart /dev/vda 1

4.扩展b步骤
resize2fs /dev/vda1

详细过程:

fdisk -l命令查看现有云盘大小

此处以CentOS 7操作系统为例演示分区扩展的步骤。

运行fdisk -l命令查看现有云盘大小。
以下示例返回云盘(/dev/vda)容量是100GiB。
[root@ecshost ~]# fdisk -l
Disk /dev/vda: 107.4 GB, 107374182400 bytes, 209715200 sectors
省略

运行df -h命令查看云盘分区大小。
以下示例返回分区(/dev/vda1)容量是20GiB。
[root@ecshost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 20G 1.5G 18G 8% /
显示20G

运行growpart <DeviceName> <PartionNumber>命令调用growpart为需要扩容的云盘和对应的第几个分区扩容。

示例命令表示为系统盘的第一个分区扩容。

[root@ecshost ~]# growpart /dev/vda 1

CHANGED: partition=1 start=2048 old: size=41940992 end=41943040 new: size=209710462,end=209712510

若运行命令后报以下错误,您可以运行LANG=en_US.UTF-8切换ECS实例的字符编码类型。

[root@ecshost ~]# growpart /dev/vda 1
unexpected output in sfdisk –version [sfdisk,来自 util-linux 2.23.2]

[root@ecshost ~]# LANG=en_US.UTF-8
运行resize2fs <PartitionName>命令调用resize2fs扩容文件系统。

示例命令表示为扩容系统盘的/dev/vda1分区文件系统。

[root@ecshost ~]# resize2fs /dev/vda1
resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/vda1 is mounted on /; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 7
The filesystem on /dev/vda1 is now 26213807 blocks long.
说明 如果您使用的是xfs文件系统,运行xfs_growfs /dev/vda1命令扩容文件系统。
运行df -h命令查看云盘分区大小。
返回分区(/dev/vda1)容量是100GiB,表示已经成功扩容。

[root@ecshost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 99G 1.6G 93G 2% /

supervisor守护服务遇见的几个坑

近期在ubunt系列服务器上遇见了supervisor的几个坑,所以将服务守护都已经切换到systemd。

坑一、资源限制配额不跟随limits.conf

1.我们在用supervisor守护一个服务A的时候,发现由supervisor拉起的服务文件描述符未跟随系统limits设置。

[program:servicea]
username=root
command = bash /etc/servicea.sh
autostart = true
stopasgroup = true
autorestart = true
startsecs = 3
stdout_logfile = /var/log/servicea.log

cat /proc/$(ps ax|grep servicea|grep -v grep|awk {print $1})/limits |grep open
Max open files            1024                 4096                 files


发现最大的文件描述符还是1024,对于系统初始化优化的时候,我们都会更改/etc/security/limits.conf

root  soft   nofile  65535
root  hard   nofile  65535
root  soft   nproc    65535
root  hard   nproc    65535
* soft   nproc    65535
* hard   nproc    65535
* soft   nofile  65535
* hard   nofile  65535
root@sklinux.com:~# ulimit -SHn
65535

或者比上诉值更大,然而supervisor守护服务,资源限制配额不跟随limits.conf。

坑二、supervisor守护prometheus服务的时候吃掉重要参数

2.我们在用supervisor守护prometheus服务的时候发现,重要参数被“吃”掉。

supervisor中prometeus配置如下:

#为方便查看做了换行处理
[program:prometheus]
username=root
directory=/opt/prometheus/data
command = /opt/prometheus/prometheus 
--config.file=/opt/prometheus/prometheus.yml
--web.listen-address="8.8.8.8:9090" 
--storage.tsdb.path="/opt/prometheus/data/"
--storage.tsdb.retention.time=90d --web.enable-lifecycle 
autostart = flase
stopasgroup = true
autorestart = true
startsecs = 3
stdout_logfile = /var/log/prometheus.log

我们发现每次拉起服务的时候,–storage.tsdb.path=“/opt/prometheus/data/“参数未生效,数据始终默认保存在/data下。 然后通过

command = /start.prometheus.sh


start.prometheus.sh 内容:
#为方便查看做了换行处理
/opt/prometheus/prometheus 
--config.file=/opt/prometheus/prometheus.yml
--web.listen-address="8.8.8.8:9090"
--storage.tsdb.path="/opt/prometheus/data/"
--storage.tsdb.retention.time=90d --web.enable-lifecycle

同样,参数无效。但是通过手工执行/start.prometheus.sh 可以将数据存储路径存在目标路径/opt/prometheus/data/中。
后来,我们将上诉服务切换为systemd守护,一切ok了! 比较:

Systemd

a.稳定可靠
b.支持 Before/After 依赖机制 c.支持 Notify 机制
d.支持基于 cgroup 的资源限制

Supervisord

a.支持通过 priority 配置进程启动顺序
b.日志友好方便查阅
c.跨平台使用
d.扩展开发友好,守护业务系统
e.但是bug多,资源限制不足

ubuntu关闭内核自动更新

ubuntu server和desktop版本都默认启动了,自动更新内核的操作。这对于生产环境来说是不友好的。因为新的内核可能引入新的安全问题、不稳定因素。

默认开启了内核自动更新所以我们关闭自动内核更新。
执行:

sudo apt-mark hold linux-image-generic linux-headers-generic

如果要重新启用内核更新:

sudo apt-mark unhold linux-image-generic linux-headers-generic

卸载内核 注意:不要先盲目地卸载内核,起码要安装一个新的才可以卸载

查看内核安装情况:

dpkg --list | grep linux-image
dpkg --list | grep linux-headers
卸载内核:

sudo ap purge linux-image-xx
sudo apt purge linux-headers-xx
sudo apt autoremove
在上述操作都完成之后,执行sudo update-grub更新grub

istio服务网格生产环境ingress网关部署SSL实战

服务网格实战之SSL服务发布

准备物件:
1.被各大厂认证签发过的、认证的域名私有证书、私钥,比如istio.sklinux.com。
2.基于云的k8s集群(生产环境)。
3.istio基础设施已经通过helm部署,并$(kubectl get svc -n istio-system|grep istio-ingressgateway)得到外部ip。
4.创建证书对象以及服务应用编排。
5.发布应用编排并使用https://istio.sklinux.com 进行测试。
大致步骤分为上面5部分,下面重点说下第4部分
首先创建证书对象:
kubectl create -n istio-system secret tls istio-ingressgateway-certs \
–key ssl/istio.sklinux.com/private.key \
–cert ssl/istio.sklinux.com/certificate.crt
将在istio-system创建一个secret为istio-ingressgateway-certs的对象,分别是私钥和证书。
然后进行检查是否在ingress-gateway的容器中已经发现:

~ kubectl exec -it istio-ingressgateway-xxxxx-xxxxx -n istio-system -c istio-proxy — ls -al /etc/istio/ingressgateway-certs/
total 0
lrwxrwxrwx 1 root root 14 May 27 09:33 tls.crt -> ..data/tls.crt
lrwxrwxrwx 1 root root 14 May 27 09:33 tls.key -> ..data/tls.key

已经看见tls.crt和tls.key

下面进行服务编排:
主要编排路线是:
Gateway->VirtualService->DestinationRule->Service->Deployment
其中在Gateway中定义协议为HTTPS以及域名:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
privateKey: /etc/istio/ingressgateway-certs/tls.key
hosts:
- istio.sklinux.com
VirtualService 主要是做一些http的匹配规则,然后匹配规则流向何处,比如流向DestinationRule中的哪个版本。
DestinationRule中主要定义了有哪些目标路由和版本,这些目标具体由Service定义。版本的标签是由多个标签组成的deployment构成。

编排好后使用

istioctl kube-inject -f注入yaml,然后kubectl create -f 即可!

istio-ingress-sds的一些障碍绕行方法

 

1.通过官网的by step 使用ingress-gateway发布ssl始终不成功,但是ingress-gateway的http服务暴露ok。

2.决定使用曲线救援方法,在外侧通过nginx来发布tls,内部回源使用http,但是遇见了http 426的错误。

➜ ~ curl https://192.168.1.25:443/ -H “Host: uat.sklinux.com” -i -k -v
* Trying 192.168.1.25…
* TCP_NODELAY set
* Connected to 192.168.1.25 (192.168.1.25) port 443 (#0)
* WARNING: disabling hostname validation also disables SNI.
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.uat.sklinux.com
* Server certificate: Fishdrowned ROOT CA
> GET / HTTP/1.1
> Host: uat.sklinux.com
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 426 Upgrade Required
HTTP/1.1 426 Upgrade Required
< Server: nginx
Server: nginx
< Date: Mon, 27 May 2019 02:25:25 GMT
Date: Mon, 27 May 2019 02:25:25 GMT
< Content-Length: 0
Content-Length: 0
< Connection: keep-alive
Connection: keep-alive

经查原因为:

nginx 反向代理默认走的http 1.0版本

但是 被反向代理的服务器是1.1版本的!

所以在反向代理的时候加上一句:proxy_http_version 1.1;

即可!

但是最终通过SDS进行tls服务发布还没彻底解决,这个问题将持续跟进社区。

kubernetes-1.14安装

1.所有节点安装docker、kubelet、kubeadm、kubectl

curl -fsSL https://get.docker.com | bash -s docker –mirror Aliyun
curl https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | apt-key add -
cat << EOF > /etc/apt/sources.list.d/kubernetes.list
deb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main
EOF
apt-get update
apt-get install -y kubelet kubeadm kubectl

2.在master和node节点拉取海外docker镜像

kubeadm config images list列出所需要img:

k8s.gcr.io/kube-apiserver:v1.14.0
k8s.gcr.io/kube-controller-manager:v1.14.0
k8s.gcr.io/kube-scheduler:v1.14.0
k8s.gcr.io/kube-proxy:v1.14.0
k8s.gcr.io/pause:3.1
k8s.gcr.io/etcd:3.3.10
k8s.gcr.io/coredns:1.3.1

3.master上初始化

kubeadm init

初始化成功后你会看见如下提示
Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run “kubectl apply -f [podnetwork].yaml” with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.0.20:6443 –token 8sio7q.g6cj9m15c0ev3d9b \
–discovery-token-ca-cert-hash sha256:81fc89c762536cadc9580278bd12fe14933ead5d9bdf5b5b1a9c07f0a3084958

4.node加入集群

kubeadm join 192.168.0.20:6443 –token 8sio7q.g6cj9m15c0ev3d9b \
–discovery-token-ca-cert-hash sha256:81fc89c762536cadc9580278bd12fe14933ead5d9bdf5b5b1a9c07f0a3084958

即可

5.coredns可能运行有问题,是因为网络还不是覆盖网络

需要安装

https://docs.projectcalico.org/v3.6/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml

修改里面cidr方面的参数然后创建应用 @master上

6.安装完成

NAME STATUS ROLES AGE VERSION
node20 Ready master 9d v1.14.0
node21 Ready <none> 9d v1.14.0
node22 Ready <none> 7d22h v1.14.0

 

aws-vpc简介

Amazon VPC (Virtual Private Cloud) 是AWS的网络基础设施。使用VPC服务可以在AWS中创建一个独立隔离的网络,在这个隔离的网络空间中可以创建任何AWS资源,例如EC2、Redis、RDS数据库等等,VPC网络使这些AWS资源互相连接,传递数据,并且提供外网访问的网关。

VPC和子网(Subnet)

当新建一个VPC,需要为虚拟网络定义IP地址范围作为CIDR地址,例如CIDR为10.1.0.0/16。IPv4的CIDR可以手动指定,但是IPv6的CIDR只能由AWS自动分配。

CIDR(无类别域间路由,Classless Inter-Domain Routing)将IP地址按照前缀分成一组,使用一种无类别的域际路由选择算法,大大减少了路由表维护的条目数。

VPC的IP地址段可以进一步划分IP段,从而创建子网(Subnet)。一个VPC横跨多个可用区(Availability Zone),但是一个子网只能位于一个可用区里面。 继续阅读aws-vpc简介

zabbix监控RouteOS

zabbix on docker

1.使用镜像zabbix/zabbix-server-mysql:latest
该镜像功能如下
支持mysql数据库的zabbix server
zabbix-server-mysql – Zabbix server with MySQL database support

暴露zabbix-server端口10051
2.运行zabbix-server

docker run –name some-zabbix-server-mysql \
-e DB_SERVER_HOST=”some-mysql-server” \
-e MYSQL_USER=”some-user” \
-e MYSQL_PASSWORD=”some-password” \
-itd –restart=’always’ \
-p 10051:10051 \
zabbix/zabbix-server-mysql:tag

3.运行zabbix管理页面后台
镜像:zabbix/zabbix-web-nginx-mysql
docker run –name some-zabbix-web-nginx-mysql \
-e DB_SERVER_HOST=”some-mysql-server” \
-e MYSQL_USER=”some-user” \
-e MYSQL_PASSWORD=”some-password” \
-e ZBX_SERVER_HOST=”some-zabbix-server” \
-e PHP_TZ=”some-timezone” \
-itd \
或者其他的一些参数
zabbix/zabbix-web-nginx-mysql:tag

4.后台添加设备
ip:161
5.关联模板 为 Template Net Mikrotik SNMPv2
下载地址:https://share.zabbix.com/network_devices/mikrotik/template-net-mikrotik-snmpv2
6.修改发现策略
7.展示流量图
ros

增加、删除node

删除node14

#ansible-playbook r.move.node14.yml -k \
-e docker_bin_dir=”/usr/bin” \
-e kube_network_plugin=”calico-rr”

#kubectl delete node node14

#kubectl get nodes node14就删除完毕

 

增加node14

在hosts.ini的nodes部分加上node别名即可,当然的提前ssh-key打通

ansible-playbook -i inventory/sk/hosts.ini scale.yml -b -k

root@node10:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
node10 Ready master 20h v1.9.5+coreos.0
node11 Ready node 3d v1.9.5+coreos.0
node12 Ready node 3d v1.9.5+coreos.0
node13 Ready node 3d v1.9.5+coreos.0
node14 Ready node 36s v1.9.5+coreos.0