Fearchen's Blog

把我的过程记录下来,以免以后忘了


  • 首页

  • 归档

  • 关于

OpenShift-运维管理

发表于 2018-04-25 | 分类于 OpenShift

Cockpit介绍

Cockpit是一个开源的系统管理项目,其目的是为用户提供一个灵活高效的Linux系统运维管理界面。目前Cockpit支持Docker、Kubernetes和OpenShift。通过Cockpit,用户可以在一个统一的系统中获取OpenShift集群节点操作系统的实时信息及配置,用户也可以在Cockpit中以管理员的身份对OpenShift集群进行管理。

项目URL:https://github.com/cockpit-project

Cockpit部署

  • 所有节点执行
yum install cockpit cockpit-docker cockpit-kubernetes -y
systemctl start cockpit && systemctl enable cockpit
vim /etc/sysconfig/iptables
A INPUT -p tcp -m state –state NEW -m tcp –dport 9090 -j ACCEPT
./media/image1.png
systemctl restart iptables
  • 登陆
登陆https://master.example.com:9090/
用户名密码即服务器用户名密码
./media/image2.png
./media/image3.png

Cockpit集群运维

在集群选项中可以添加OpenShift集群
./media/image4.png
各信息在浏览器中直观展现
节点
./media/image5.png
拓扑
./media/image6.png
持久化卷
./media/image7.png

OpenShift集群扩容

根据OpenShift项目官方资料,单个计算节点可以支持250个Pod,单一集群目前实际最大部署数量达到1000个节点,单一集群的最大Pod数量为120
000。

目前集群扩容的方式有:

  • 半自动扩容:

OpenShift默认提供了扩容的Ansible
Playbook解决自动化节点的安装和配置,之所以称为半自动,是因为Ansible扩容的时机是由用户决定的。

  • 全自动扩容:

自动扩容是在半自动扩容的基础上由系统自动判别当前集群资源是否足够,如果不足,则调用Ansible
Playbook进行扩容。自动扩容需要ManageIQ第三方云管理平台的支持,根据用户预定义的规则,在满足规则条件的情况下对集群进行扩容或缩容。

Ansible Playbook

通过Ansible
Playboko进行扩容需要编辑Ansible的Inventory,/etc/ansible/hosts文件,在相应角色下添加新节点的域名以及配置信息

# host group for masters [masters] master.example.com # host group for etcd [etcd] master.example.com # host group for nodes, includes region info [nodes] master.example.com node1.example.com openshift_node_labels=”{‘region’: ‘primary’, ‘zone’: ‘east’}” node2.example.com openshift_node_labels=”{‘region’: ‘primary’, ‘zone’: ‘west’}” infra-node1.example.com openshift_node_labels=”{‘region’: ‘infra’, ‘zone’: ‘default’}” infra-node2.example.com openshift_node_labels=”{‘region’: ‘infra’, ‘zone’: ‘default’}” #新增计算节点 node3.example.com node4.example.com

主节点扩容Playbook

ansible-playbook /root/openshift-ansible/playbooks/byo/openshift-master/scaleup.yml

计算节点扩容Playbook

ansible-playbook /root/openshift-ansible/playbooks/byo/openshift-node/scaleup.yml

OpenShift集群缩容

缩容是指减小集群的计算资源,缩容主要考虑如何将计算资源抽离集群而不影响现有的业务。在缩容的场景中,集群管理员需要保证:1.新的容器不会再创建于要缩减的计算之上;2.当前运行在计划缩减的计算节点之上的容器能迁移到其他计算节点之上。

禁止参与调度

控制一个计算节点是否参与到集群的调度运行应用
oc adm manage-node master.example.com –schedulable=false
./media/image8.png

OpenShift-性能监控

发表于 2018-04-25 | 分类于 OpenShift

简介

OpenShift在Kubernetes架构的基础上提供了一套易于使用的度量采集和性能监控方案。设计从整个环境中的容器、POD、Node节点中收集信息,然后在Web控制台中显示这些信息。

项目URL:https://github.com/openshift/origin-metrics

主要通过以下组件实现:

  • Heapster

Heapster通过Master
API收集系统级别的信息,如CPU、内存、网络,然后将这些信息发送到Hawkular

https://github.com/kubernetes/heapster

  • Hawkular Metrics

Hawkular Metrics是来此Hawkular项目的监控存储引擎。它提供了通过json
REST接口来创建、访问和管理历史存储指标的方法。

https://github.com/hawkular/hawkular-metrics

  • Cassandra

Cassandra是Hawkular的分布式数据库

http://cassandra.apache.org/

  • Hawkular OpenShift Agent

Hawkular OpenShift
Agent是一个代理组件,用来收集来此pod的应用程序级别的数据。前提是pod公开自己希望被收集的信息。

OpenShift的监控采集方案的组件Heapster、Hawkular
Metrics、Canssandra数据库都是以容器的形式提供,并默认提供了可快速部署的Temaplate。

启用集群监控

版本1.4之前OpenShift
Origin提供template的方式,供用户安装Metrics组件,从版本1.5开始到当前环境的3.6版本,OpenShift
Origin开始已Ansible Playbook的方式安装Metris组件。

Playbook URL:./openshift-ansible/playbooks/common/openshift-cluster/
openshift_metrics.yml

由于部署需要联网下载docker 镜像,网络原因导致失败,提前下载。
在infra-node上下载以下镜像,并保证infrra-node物理内存>4G
docker pull docker.io/openshift/origin-metrics-heapster:latest docker pull docker.io/openshift/origin-metrics-hawkular-metrics:latest docker pull docker.io/openshift/origin-metrics-heapster:lates
开始部署Metric组件
ansible-playbook /root/openshift-ansible/playbooks/byo/openshift-cluster/openshift-metrics.yml \ -e openshift_metrics_install_metrics=True \ -e openshift_metrics_hawkular_hostname=hawkular-metrics.example.com
因为测试使用临时存储,若要持久化存储: ansible-playbook /root/openshift-ansible/playbooks/byo/openshift-cluster/openshift-metrics.yml \ -e openshift_metrics_install_metrics=True \ -e openshift_metrics_hawkular_hostname=hawkular-metrics.example.com \ -e openshift_metrics_cassandra_storage_type=pv
./media/image2.png
oc project openshift-infra
oc get po
./media/image3.png

使用集群监控

部署完成后,在OpenShift的Web控制台,进入某一个Pod的详情页面,单机Metrics页签,可以看到当前Pod的CPU,内存及网络的使用情况,如下图

集群监控容量规划

OpenShift
Origin监控存储使用的是Cassandra数据库。默认设置,监控数据存储七天,七天后,Cassandra开始清除旧数据。已删除的Pod和Project的监控数据不会自动清除,只要超过7天才会被删除

Pod运行累计数据表
1000Pod 10000Pod
24小时Cassandra数据占用 2.5GB 11.4GB
7天Cassandra数据占用 20GB 90GB

监控组件配置

在实际环境中,强烈建议为Cassandra数据库配置后端持久化存储,并且规划好容量。此外根据集群以及应用规模,可以调整Hawkular
Metrics及Cassandra数据库的实例数量,保证性能及相应速度。

详细关于监控的配置项,参考官方文档:https://docs.openshift.org/3.6/install_config/cluster_metrics.html

监控接口

OpenShift的监控信息最终都存放在Hawkular
Metrics后端的Cassandra数据库中。可以访问Hawkular
Metrics的RESTful接口获取其中的信息,着对需要将OpenShift的监控和企业现有监控对接有很大帮助。

Heapster已配置通过API访问,并且需要cluster-reader或cluster-admin权限。

示例
curl -H “Authorization: Bearer \$(oc whoami -t)” \ -X GET https://\${KUBERNETES_MASTER}/api/v1/proxy/namespaces/openshift-infra/services/https:heapster:/validate

更多API接口信息,参考Heapster项目:

https://github.com/kubernetes/heapster/

OpenShift-日志管理

发表于 2018-04-25 | 分类于 OpenShift

简介

OpenShift平台的日志聚合和管理是在EFK方案的基础上实现的。EFK主要汇集来自Host和App的运行日志,包括多个容器和已删除的Pods。

EFK Stack是在EFK上修改的版本,由以下部分组成:

  • Elasticsearch:存储所有日志的额对象存储

  • Fluentd:从节点收集日志并推送给ES

  • Kibana:ES的Web UI

  • Curator:从ES删除旧日志

部署EFK Stack

EFK Stack使用Ansible Playbook部署日志管理组件。

origin-logging-elasticsearch服务至少需要有物理内存8G的Node节点

由于网络原因,提前下载images
docker pull docker.io/openshift/origin-logging-fluentd:latest
docker pull openshift/origin-logging-curator:latest
docker pull openshift/origin-logging-kibana:latest
docker pull openshift/origin-logging-elasticsearch:latest
ansible-playbook /root/openshift-ansible/playbooks/byo/openshift-cluster/openshift-logging.yml
./media/image1.png
验证服务正常
./media/image2.png

访问Kibana

通过Route创建的URL进行访问:https://kibana.router.default.svc.cluster.local/

(配置好DNS或者Hosts)

./media/image3.png

日志管理操作

  1. 允许集群成员查看集群日志

默认情况下,只有集群管理员才能访问日志管理,若要允许普通成员访问则需要开启配置

oc project logging
oc edit configmap/logging-elasticsearch
openshift.operations.allow_cluster_reader 配置为true
./media/image4.png
或者在部署前修改playbbok
vim /root/openshift-ansible/roles/openshift_logging/defaults/main.yml
openshift_logging_es_allows_cluster_reader配置true
./media/image5.png
  1. Fluentd

Fluentd使用Systemd Journal作为日志源,默认情况下,Fluentd分别从/ var / log /
messages和
/var/log/containers/\<container>.log中读取系统日志和容器日志。您可以改为使用systemd日志作为日志源。有三个库存参数可用:

参数 概述
openshift_logging_use_journal 缺省值为空,它配置Fluentd以检查Docker正在使用哪个日志驱动程序。如果Docker正在使用–log-driver=journald,Fluentd将从systemd日志中读取数据,否则,它会假定docker正在使用json-file日志驱动程序并从/ var / log文件源读取数据。您可以将openshift_logging_use_journal选项指定 为true或false明确指出要使用哪个日志源。使用systemd日志需要docker-1.10或更高版本,并且必须配置Docker以使用–log-driver=journald。
openshift_logging_journal_read_from_head 如果此设置为false,Fluentd将从日志末尾开始读取,忽略历史日志。如果这个设置是true,Fluentd开始从日志的开头读取日志。
  1. 修改kibana URL
/etc/origin/master/master-config.yaml
… assetConfig: … loggingPublicURL: “https://kibana.example.com" …
必须为https
oc scale dc/logging-kibana –replicas=2
  1. Curator配置

Curator允许管理员配置按计划自动执行的预定Elasticsearch维护操作。它计划每天根据其配置执行操作。每个Elasticsearch群集只推荐一个Curator
pod,配置参数

变量名 描述
\$PROJECT_NAME 项目的实际名称,例如myapp-devel。对于OpenShift Origin 操作 日志,请使用该名称.operations作为项目名称。
\$ACTION 目前只delete允许采取行动。
\$UNIT 其中一个days,weeks或months。
\$VALUE 单位数的整数。
.defaults 使用.defaults的\$PROJECT_NAME设置为未指定的项目的默认值。
runhour (数量)以24小时格式运行策展人作业的一天中的小时。用于.defaults。
runminute (数字)运行策展人作业的小时数。用于.defaults。
例如,要将Curator配置为:
  • 删除比myapp-dev项目早的索引1 day

    • 删除myapp-qe项目中早于的索引1 week

      • 删除操作日志比8 weeks

        • 删除30 days旧的所有其他项目索引

        • 每天午夜运行策展人工作

使用: MYAPP-dev的: 删除: 天数:1 MYAPP - 即: 删除: 周:1 .operations: 删除: 周:8 .defaults: 删除: 天数:30 runhour: 0 runminute:0
创建curator配置
编辑提供的ConfigMap
oc edit configmap/logging-curator
代替提供的ConfigMap:
create /path/to/mycuratorconfig.yaml oc create configmap logging-curator -o yaml \ –from-file=config.yaml=/path/to/mycuratorconfig.yaml \ \ oc replace -f -
完成更改后,重新部署
oc rollout latest dc/logging-curator oc rollout latest dc/logging-curator-ops

OpenShift-企业应用

发表于 2018-04-25 | 分类于 OpenShift

Ansible部署

为区分各角色,部署结构如下:

环境配置

主机名 角色 IP地址 操作系统 硬件配置
master.example.com master 10.10.31.161 7.4 mini 4C2G+30G
node1.example.com node 10.10.31.162 7.4 mini 4C2G+30G
node2.example.com node 10.10.31.163 7.4 mini 4C2G+30G
infra-node1.example.com node 10.10.31.164 7.4 mini 4C2G+30G
infra-node2.example.com node 10.10.31.165 7.4 mini 4C2G+30G

准备工作,所有主机执行

配置主机名
hostnamectl set-hostname master.example.com hostnamectl set-hostname node1.example.com hostnamectl set-hostname node2.example.com hostnamectl set-hostname infra-node1.example.com hostnamectl set-hostname infra-node2.example.com
若无DNS Server,则配置Hosts
10.10.31.161 master.example.com 10.10.31.162 node1.example.com 10.10.31.163 node2.example.com 10.10.31.164 infra-node1.example.com 10.10.31.165 infra-node2.example.com
确认网络正常
nmcli con show nmcli con up ens160 nmcli con mod ens160 connection.autoconnect yes systemctl restart NetworkManager systemctl status NetworkManager systemctl is-enabled NetworkManager
安装基础软件包
yum install wget git net-tools bind-utils iptables-services bridge-utils bash-completion kexec-tools sos psacct -y
升级系统
yum update -y
安装Docker
yum install docker -y
docker version
配置docker后端存储
cat \<\ /etc/sysconfig/docker-storage-setup DEVS=/dev/sdb EOF
docker-storage-setup
添加中科大源
vim /etc/docker/daemon.json
{ “registry-mirrors”: [“https://docker.mirrors.ustc.edu.cn/"] }
systemctl enable docker && systemctl start docker

配置Ansible,Master执行

由于网络原因,提前修改repo源和导入docker images

配置EPEL
yum -y install \ https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
不启用EPEL,后续手动指定
sed -i -e “s/\^enabled=1/enabled=0/“ /etc/yum.repos.d/epel.repo
安装Ansible
yum -y –enablerepo=epel install ansible pyOpenSSL
拉取最新openshift-ansible版本
cd ~ git clone -b release-3.6 https://github.com/openshift/openshift-ansible.git cd openshift-ansible
修改ansible playbook中的repo源
vim openshift-ansible/roles/openshift_repos/templates/CentOS-OpenShift-Origin36.repo.j2
baseurl=http://mirrors.ustc.edu.cn/centos/7.4.1708/paas/x86_64/openshift-origin36/
./media/image1.png
提前pull好docker images
./media/image2.png
配置各主机互信
ssh-keygen -f /root/.ssh/id_rsa -N ‘’
for host in master.example.com \ etcd.example.com \ node2.example.com \ node1.example.com \ infra-node1.example.com \ infra-node2.example.com; do ssh-copy-id -i ~/.ssh/id_rsa.pub \$host; done

执行部署

  • 准备Ansible Host
mv -f /etc/ansible/hosts /etc/ansible/hosts.old
vi /etc/ansible/hosts
# Create an OSEv3 group that contains the masters and nodes groups [OSEv3:children] masters nodes etcd # Set variables common for all OSEv3 hosts [OSEv3:vars] # SSH user, this user should allow ssh based auth without requiring a password ansible_ssh_user=root # If ansible_ssh_user is not root, ansible_become must be set to true #ansible_become=true openshift_deployment_type=origin # uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider openshift_master_identity_providers=[{‘name’: ‘htpasswd_auth’, ‘login’: ‘true’, ‘challenge’: ‘true’, ‘kind’: ‘HTPasswdPasswordIdentityProvider’, ‘filename’: ‘/etc/origin/master/htpasswd’}] #Disable disk and memory checks openshift_disable_check=disk_availability,memory_availability # host group for masters [masters] master.example.com # host group for etcd [etcd] etcd.example.com # host group for nodes, includes region info [nodes] master.example.com node1.example.com openshift_node_labels=”{‘region’: ‘primary’, ‘zone’: ‘east’}” node2.example.com openshift_node_labels=”{‘region’: ‘primary’, ‘zone’: ‘west’}” infra-node1.example.com openshift_node_labels=”{‘region’: ‘infra’, ‘zone’: ‘default’}” infra-node2.example.com openshift_node_labels=”{‘region’: ‘infra’, ‘zone’: ‘default’}”
运行
ansible-playbook ~/openshift-ansible/playbooks/byo/config.yml
./media/image3.png

验证安装

  • Master上验证

  • 确认集群状态

oc status
./media/image4.png
oc get nodes
./media/image5.png
oc get all
./media/image6.png
验证etcd
yum install etcd -y
etcdctl -C \ https://etcd.example.com:2379 \ –ca-file=/etc/origin/master/master.etcd-ca.crt \ –cert-file=/etc/origin/master/master.etcd-client.crt \ –key-file=/etc/origin/master/master.etcd-client.key cluster-health
etcdctl -C \ https://etcd.example.com:2379 \ –ca-file=/etc/origin/master/master.etcd-ca.crt \ –cert-file=/etc/origin/master/master.etcd-client.crt \ –key-file=/etc/origin/master/master.etcd-client.key member list

登陆

创建用户
htpasswd -b /etc/origin/master/htpasswd dev dev
给dev用户admin权限
oc login -u system:admin
oc adm policy add-cluster-role-to-user cluster-admin dev
浏览器登录
https://master.example.com:8443

本地DNS Server

  • 在建立openshift集群时,是直接修改各节点的/etc/hosts文件,要访问Router映射出的域名,是加上静态的域名解析。当节点数量很多或者后续执行节点扩容时,都需要修改大量/etc/hosts/文件,繁琐又不智能。

  • 这里选择在本地搭建一个DNS服务器,并选择将DNS Server部署在Master节点上。

  • 在部署过程中已经安装好dnsmasp服务,不用安装,只需要添加配置文件即可

添加dnsmasp配置

vim /etc/dnsmasq.d/local.conf
address=/master.example.com/10.10.31.161 address=/www.ivops-rabbitmq.com/10.10.31.164 address=/registry-console-default.router.default.svc.cluster.local/10.10.31.164 address=/agtweb.mas.ivops/10.10.31.164 address=/agtweb2.mas.ivops/10.10.31.164
./media/image7.png
systemctl restart dnsmasq.service
systemctl status dnsmasq.service

配置iptables

sed -i ‘/.*–dport 22 -j ACCEPT.*/a\-A INPUT -p tcp -m state –state NEW -m tcp –dport 53 -j ACCEPT’ /etc/sysconfig/iptables
sed -i ‘/.*–dport 22 -j ACCEPT.*/a\-A INPUT -p udp -m state –state NEW -m udp –dport 53 -j ACCEPT’ /etc/sysconfig/iptables
systemctl restart iptables
systemctl status iptables

本地验证

./media/image8.png
ping master.example.com -c 2
ping agtweb.mas.ivops -c 2
./media/image9.png

持久化存储-NFS

使用NFS为后端存储

  • 创建NFS共享目录
mount /dev/sdc1 /mnt/nfs/
yum install nfs-utils rpcbind -y
chown nfsnobody:nfsnobody /mnt/nfs/ -R
echo “/mnt/nfs *(rw,sync,all_squash)” >> /etc/exports
systemctl start rpcbind && systemctl enable rpcbind
systemctl status rpcbind
exportfs -r
systemctl start nfs-server && systemctl enable nfs-server
systemctl status nfs-server
showmount -e 127.0.0.1
  • 测试挂载
mkdir /mnt/nfsmount
touch /mnt/nfs/test
mount 10.10.31.161:/mnt/nfs /mnt/nfsmount
ls /mnt/nfsmount/
rm -rf /mnt/nfsmount/test
df -h
umount /mnt/nfsmount/

创建Persistent Volume

  • 创建pv 的yaml文件
vi nfs-pv.yaml
apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv spec: capacity: storage: 1Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain nfs: path: /mnt/nfs server: 10.10.31.161 readOnly: false
  • 创建pv卷
oc create -f nfs-pv.yaml -n my-project
  • 查看pv卷状态
oc get pv

创建Persistent Volume Claim

  • 创建pvc的yaml文件
vim nfs-pvc.yaml
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: nfs-pvc spec: accessModes: - ReadWriteMany volumeName: nfs-pv resources: requests: storage: 1Gi
  • 创建pvc
oc create -f nfs-pvc.yaml -n my-project
  • 查看pvc状态
oc get pvc

配置SELinux权限

  • 开启NFS卷写入权限
setsebool -P virt_use_nfs on

创建应用

  • 创建pod的yaml文件
vi nfs-nginx.yaml
apiVersion: v1 kind: Pod metadata: name: nginx-nfs-pod labels: name: nginx-nfs-pod spec: containers: - name: nginx-nfs-pod image: fedora/nginx ports: - name: web containerPort: 80 volumeMounts: - name: nfsvol mountPath: /usr/share/nginx/html securityContext: supplementalGroups: [100003] privileged: false volumes: - name: nfsvol persistentVolumeClaim: claimName: nfs-pvc
  • 创建pod
oc create -f nfs-nginx.yaml -n my-project
  • 查看pod状态
oc get pod –n my-project
oc describe pod nginx-nfs-pod
  • 在Web Console上可以看到已经挂载
./media/image10.png
./media/image11.png
  • 查看底层docker状态
./media/image12.png
docker inspect 289c36f63273
./media/image13.png

持久化存储-GlusterFS

  1. 使用GlusterFS为后端存储-Static

    1. 部署GlusterFS集群
  • 环境准备
主机名 IP地址 操作系统 硬件配置
gluster1 10.10.31.166 7.4 mini 4C2G+50G
gluster2 10.10.31.167 7.4 mini 4C2G+50G
gluster3 10.10.31.168 7.4 mini 4C2G+50G
  • 准备工作

配置hostname

vi /etc/hosts
hostnamectl set-name glsuter1
hostnamectl set-name glsuter2
hostnamectl set-name glsuter3

关闭SELinux

  • 开始安装,所有机器相同操作

    • 安装软件仓库
yum install centos-release-gluster
  • 格式化数据盘
mkfs.xfs -i size=512 /dev/sdb
mkdir -p /bricks/brick1
vi /etc/fstab
/dev/sdb /bricks/brick1 xfs defaults 1 2
mount -a && mount
  • 安装GlusterFS
yum –enablerepo=centos-gluster*-test install glusterfs-server
systemctl start glusterd && systemctl enable glusterd
  • 配置trusted pool
gluster1执行
gluster peer probe gluster2
gluster peer probe gluster3
gluster peer status
./media/image14.png
  • 配置存储卷
mkdir /bricks/brick1/gv0
可以在任意一个节点执行:
gluster volume create gv0 replica 2 gluster1:/bricks/brick1/gv0 gluster2:/bricks/brick1/gv0
gluster volume start gv0
gluster volume info
  • 测试挂载
mount -t glusterfs gluster1:/gv0 /mnt
GlusterFS 五种卷: Distributed:分布式卷,文件通过 hash 算法随机分布到由 bricks 组成的卷上。 Replicated: 复制式卷,类似 RAID 1,replica 数必须等于 volume 中 brick 所包含的存储服务器数,可用性高。 Striped: 条带式卷,类似 RAID 0,stripe 数必须等于 volume 中 brick 所包含的存储服务器数,文件被分成数据块,以 Round Robin 的方式存储在 bricks 中,并发粒度是数据块,大文件性能好。 Distributed Striped: 分布式的条带卷,volume中 brick 所包含的存储服务器数必须是 stripe 的倍数(>=2倍),兼顾分布式和条带式的功能。 Distributed Replicated: 分布式的复制卷,volume 中 brick 所包含的存储服务器数必须是 replica 的倍数(>=2倍),兼顾分布式和复制式的功能。

GlusterFS持久化存储

  • 在OpenShift集群所有主机上安装
yum install glusterfs-fuse
  • OpenShift所有主机配置Hosts
vi /etc/hosts
10.10.31.166 gluster1 10.10.31.167 gluster2 10.10.31.168 gluster3
  • 创建Gluster Endpoints

    • 先创建Service
vi gluster-service.yaml
apiVersion: v1 kind: Service metadata: name: gluster-cluster spec: ports: - port: 1
oc create -f gluster-service.yaml -n s2i-project
oc get svc
  • 创建Endpoint
vi gluster-endpoints.yaml
apiVersion: v1 kind: Endpoints metadata: name: gluster-cluster subsets: - addresses: - ip: 10.10.31.166 ports: - port: 1 protocol: TCP - addresses: - ip: 10.10.31.167 ports: - port: 1 protocol: TCP - addresses: - ip: 10.10.31.168 ports: - port: 1 protocol: TCP
oc create -f gluster-endpoints.yaml -n s2i-project
oc get endpoint

创建Persistent Volume

vi gluster-pv.yaml
apiVersion: v1 kind: PersistentVolume metadata: name: gluster-pv spec: capacity: storage: 1Gi accessModes: - ReadWriteMany glusterfs: endpoints: gluster-cluster path: /gv0 readOnly: false persistentVolumeReclaimPolicy: Retain
oc create -f gluster-pv.yaml -n s2i-project
oc get pv

创建Persistent Volume Claim

vi gluster-claim.yaml
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: gluster-claim spec: accessModes: - ReadWriteMany resources: requests: storage: 1Gi
oc create -f gluster-claim.yaml -n s2i-project
oc get pvc

配置SELinux权限

setsebool -P virt_sandbox_use_fusefs on

创建应用

  • 由于使用的nginx镜像需要特殊权限运行,配置SCC
oc adm policy add-scc-to-user privileged myuser
  • 创建Pod
vim gluster-pod1.yaml
apiVersion: v1 kind: Pod metadata: name: gluster-pod1 labels: name: gluster-pod1 spec: containers: - name: gluster-pod1 image: nginx ports: - name: web containerPort: 80 securityContext: privileged: true volumeMounts: - name: gluster-vol1 mountPath: /usr/share/nginx/html readOnly: false volumes: - name: gluster-vol1 persistentVolumeClaim: claimName: gluster-claim
oc create -f gluster-pod1.yaml -n s2i-project
oc get pod
./media/image15.png
./media/image16.png
  1. 使用GlusterFS为后端存储-Dynamic

    1. 新部署GlusterFS,使用Heketi管理
  • 环境准备
主机名 IP地址 操作系统 硬件配置
gluster1 10.10.31.166 7.4 mini 4C2G+50G
gluster2 10.10.31.167 7.4 mini 4C2G+50G
gluster3 10.10.31.168 7.4 mini 4C2G+50G
  • 准备工作

配置hostname

vi /etc/hosts
10.10.31.166 gluster1 10.10.31.167 gluster2 10.10.31.168 gluster3
hostnamectl set-hostname glsuter1
hostnamectl set-hostname glsuter2
hostnamectl set-hostname glsuter3

关闭SELinux

  • 开始安装,所有机器相同操作

    • 安装软件仓库
yum install centos-release-gluster -y
  • 安装GlusterFS
yum install glusterfs-server -y
systemctl start glusterd && systemctl enable glusterd
systemctl status glusterd

安装Heketi

  • Heketi用于管理GlusterFS的REST API

  • 在GlusterFS其中一台虚拟机上安装,这里选择gluster3

yum install heketi heketi-client -y
  • Heketi使用SSH来配置GlusterFS的所有节点。创建SSH密钥对,将公钥拷贝到所有3个节点上
ssh-keygen -f /etc/heketi/heketi_key -t rsa -N ‘’
ssh-copy-id -i /etc/heketi/heketi_key.pub root\@gluster1 ssh-copy-id -i /etc/heketi/heketi_key.pub root\@gluster2 ssh-copy-id -i /etc/heketi/heketi_key.pub root\@gluster3
chown heketi:heketi /etc/heketi/heketi_key*
  • 配置heketi使用SSH
vim /etc/heketi/heketi.json
“executor”: “ssh”, “_sshexec_comment”: “SSH username and private key file information”, “sshexec”: { “keyfile”: “/etc/heketi/heketi_key”, “user”: “root”, “port”: “22”, “fstab”: “/etc/fstab” },
./media/image17.png
  • 启动服务
systemctl restart heketi
systemctl enable heketi
systemctl status heketi
  • 测试服务状态
curl http://gluster3:8080/hello
./media/image18.png

配置Topology

  • 配置环境变量
export HEKETI_CLI_SERVER=http://gluster3:8080
  • 准备json文件
vim topology.json
{ “clusters”: [ { “nodes”: [ { “node”: { “hostnames”: { “manage”: [ “gluster1” ], “storage”: [ “10.10.31.166” ] }, “zone”: 1 }, “devices”: [ “/dev/sdb” ] }, { “node”: { “hostnames”: { “manage”: [ “gluster2” ], “storage”: [ “10.10.31.167” ] }, “zone”: 1 }, “devices”: [ “/dev/sdb” ] }, { “node”: { “hostnames”: { “manage”: [ “gluster3” ], “storage”: [ “10.10.31.168” ] }, “zone”: 1 }, “devices”: [ “/dev/sdb” ] } ] } ] }
该文件格式,是告诉heketi要创建一个3节点的集群,其中每个节点包含的配置有FQDN,IP地址以及至少一个将用作GlusterFS块的备用块设备。
  • 运行
heketi-cli topology load –json=topology.json
  • 验证
gluster peer status
  • 创建一个数据卷
heketi-cli volume create –size=20
./media/image19.png
gluster volume info
./media/image20.png

将Gluster与OpenShift集成

集成OpenShift,需要一个动态的Kubernetes Storage Provisioner和一个StorageClass。
Provisioner在OpenShift中开箱即用。 实际上关键的是如何将存储挂载到容器上。
StorageClass是OpenShift中的用户可以用来实现的PersistentVolumeClaims的实体,它反过来能够触发一个Provisioner实现实际的配置,并将结果表示为Kubernetes
PersistentVolume(PV)。

先创建一个测试项目,在OpenShift Master上执行

oc new-project gluster-storage

创建StorageClass

vi glusterfs-storageclass1.yaml
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: gluster-dyn annotations: storageclass.kubernetes.io/is-default-class: “true” provisioner: kubernetes.io/glusterfs parameters: resturl: “http://gluster3:8080" restauthenabled: “false”
oc create -f glusterfs-storageclass1.yaml
oc get sc
./media/image21.png
我们的provisioner是kubernetes.io/glusterfs,将它指向我们的heketi实例。 我们将类命名为“gluster-dyn”, 同时使其成为所有没有显示指定StorageClass的PersistentVolumeClaim的默认StorageClass。

创建Persistent Volume Claim

#新建这个PVC只为测试
vi glusterfs-pvc-storageclass.yaml
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: gluster-dyn-pvc spec: accessModes: - ReadWriteMany resources: requests: storage: 10Gi storageClassName: gluster-dyn
oc create -f glusterfs-pvc-storageclass.yaml
oc get pvc
./media/image22.png

验证GlusterFS Volume

回到GlusterFS集群中,查看volume状态

gluster volume info
可以看到当前glusterfs里存在两个Volume, 第一个Volume是上面用heketi-cli volume create创建的测试Volume, 第二个Volume是StorageClass通过PVC创建的Volume
./media/image23.png
./media/image24.png

Web Console

./media/image25.png
./media/image26.png

创建应用

  • 创建pod的yaml文件
vi nginx-pod-gluster.yaml
apiVersion: v1 kind: Pod metadata: name: gluster-pod1-gluster labels: name: gluster-pod1-gluster spec: containers: - name: gluster-pod1-gluster image: nginx ports: - name: web containerPort: 80 securityContext: privileged: true volumeMounts: - name: gluster-vol1-gluster mountPath: /usr/share/nginx/html volumes: - name: gluster-vol1-gluster persistentVolumeClaim: claimName: gluster-dyn-pvc
oc create -f nginx-pod-gluster.yaml
oc get pod –o wide
./media/image27.png
./media/image28.png
  • 测试应用
./media/image29.png

深入了解Pod

Pod的定义

Pod是Kubernetes下的概念,pod的容器的载体,所有容器都是在pod中被管理,一个或多个容器放在pod里作为一个单元方便管理。

下面是一个完整的yaml格式定义的文件,注意格式,子集包含关系,不要有tab,要用空格。
apiVersion: v1 //版本 kind: pod //类型,pod metadata: //元数据 name: String //元数据,pod的名字 namespace: String //元数据,pod的命名空间 labels: //元数据,标签列表 - name: String //元数据,标签的名字 annotations: //元数据,自定义注解列表 - name: String //元数据,自定义注解名字 spec: //pod中容器的详细定义 containers: //pod中的容器列表,可以有多个容器 - name: String image: String //容器中的镜像 imagesPullPolicy: [Always\ Never\ IfNotPresent]//获取镜像的策略 command: [String] //容器的启动命令列表(不配置的话使用镜像内部的命令) args: [String] //启动参数列表 workingDir: String //容器的工作目录 volumeMounts: //挂载到到容器内部的存储卷设置 - name: String mountPath: String readOnly: boolean ports: //容器需要暴露的端口号列表 - name: String containerPort: int //容器要暴露的端口 hostPort: int //容器所在主机监听的端口(容器暴露端口映射到宿主机的端口) protocol: String env: //容器运行前要设置的环境列表 - name: String value: String resources: //资源限制 limits: cpu: Srting memory: String requeste: cpu: String memory: String livenessProbe: //pod内容器健康检查的设置 exec: command: [String] httpGet: //通过httpget检查健康 path: String port: number host: String scheme: Srtring httpHeaders: - name: Stirng value: String tcpSocket: //通过tcpSocket检查健康 port: number initialDelaySeconds: 0//首次检查时间 timeoutSeconds: 0 //检查超时时间 periodSeconds: 0 //检查间隔时间 successThreshold: 0 failureThreshold: 0 securityContext: //安全配置 privileged: falae restartPolicy: [Always\ Never\ OnFailure]//重启策略 nodeSelector: object //节点选择 imagePullSecrets: - name: String hostNetwork: false //是否使用主机网络模式,默认否 volumes: //在该pod上定义共享存储卷 - name: String meptyDir: {} hostPath: path: string secret: //类型为secret的存储卷 secretName: String item: - key: String path: String configMap: //类型为configMap的存储卷 name: String items: - key: String path: String

Pod的配置管理

  • 应用部署的最佳实践,就是将应用所需的配置信息与程序进行分离。

  • OpenShift提供一种集群配置管理方案:ConfigMap,就是将一些环境变量或者配置文件定义为configmap,放在OpenShift中,可以让其他pod调用。

  • ConfigMap有以下典型用法

    • 生成为容器内的环境变量

    • 设置容器启动命令的启动参数

    • 以volume的形式挂载为容器内部的文件或目录

使用示例:

定义一个ConfigMap配置文件
vi cm-appvars.yaml
apiVersion: v1 kind: ConfigMap metadata: name: cm-appvars data: apploglevel: info appdatadir: /var/date
oc create -f cm-appvars.yaml
使用ConfigMap
apiVersion: v1 kind: Pod metadata: name: cm-test-pod spec: containers: - name: cm-test image: busybux env: - name: APPLOGLEVEL vlaueFrom: configMapKeyRef: name: cm-appvars //要和之前创建的ConfigMap的name对应 key: apploglevel - name: APPDATADIR vlaueFrom: configMapKeyRef: name: cm-appvars //要和之前创建的ConfigMap的name对应 key: appdatadir

Pod生命周期和重启策略

  • Pod一共有四种状态
状态值 描述
Pending APIserver已经创建该server,但pod内有一个或多个容器的镜像还未创建,可能在下载中。
Running APIserver已经创建该server,但pod内有一个或多个容器的镜像还未创建,可能在下载中。
Failed Pod内所有容器都已退出,其中至少有一个容器退出失败
Unknown 由于某种原因无法获取Pod的状态比如网络不通。
  • Pod的重启策略应用于Pod内的所有容器,由Pod所在Node节点上的Kubelet进行判断和重启操作。重启策略有以下三种:
重启策略 描述
Always 容器失效时,即重启
OnFailure 容器终止运行,且退出码不为0 时重启
Never 永不重启

Pod调度机制

在OpenShift系统中,pod在大部分场景下都只是容器的载体而已,通常需要通过Deployment,DaemonSet,Job等对象来完成Pod的调度与自动控制功能。

  • RC,Deployment: 全自动调度

    • RC的主要功能之一就是自动部署一个容器应用的多份副本,以及持续监控,保持集群内有一定数量的副本数量(配置文件指定了副本数量)
  • DaemonSet: 特定场景调度

    • DaemonSet,用于管理在集群中每个Node上只运行一份Pod的副本实例,比如在每节点上都运行有且只有一个fluentd

Pod扩容和缩容

  • 通过scale来完成扩容或缩容

  • 动态扩容缩容(HPA)

深入了解Service

由于Pod的IP会变化,提供某些功能的POD如果IP发生变化,会导致其他Pod无法发现这些功能,因此
引入了Service的功能。

Service的定义

{ “kind”: “Service”, “apiVersion”: “v1”, “metadata”: { “name”: “my-service” }, “spec”: { “selector”: { “app”: “MyApp” }, “ports”: [ “protocol”: “TCP”, “port”: 80, “targetPort”: 9376 } ] } }
该Service 对应的Pod集合:带有label app=Myapp,对外暴露端口9376
Service 能将任意的流入Port 重定向到targetPort,默认情况下,targetPort和Port为相同值,不同的Pod 可以对应不同的端口号(例如,在你应用的下一个版本中会使用不同的端口号,但是并不应用之前版本的使用)
Service 支持UDP和TCP,默认是TCP

Service虚拟IP和服务代理

  • K8s集群内每个节点都会运行kube-proxy,负责实现服务的虚拟机IP(不是externalName)

  • Kube-proxy监控k8s
    master节点来发现Service、Endpointd的增加和删除,对于Service,在本地打开一个随机端口作为代理端口,任何访问改代理端口的连接都会被指向Service对象的Pod集合,最终指向哪个Pod取决于Service的SessionAffinity,最后,他会配置iptables,捕获流向Service 的Cluster
    IP 和Port的连接,并重定向到这个代理端口。

网络连通性

网络实现

  • 查看各节点分配到的子网,每个节点默认都会被分配到一个子网,在计算节点上运行的Pod的ip将来源于此网段
oc get hostsubnets
./media/image30.png
  • 通过配置文件可以修改默认子网段
vim /etc/origin/master/master-config.yaml
./media/image31.png

注意点

  • OpenShift Web Console 不支持 https 安全验证,在Deploy Image是使用Image
    Name部署是提示证书验证失败

    • 第一种方式:用命令行加参数
oc new-app –insecure-registry dtr.ivops.cn:5443/ivops/nginx-alpine:v1.1.x –name=nginx-alpine-test
  • 第二种方式:使用Image Stream方式
vi ivops-mariadb.json
{ “kind”: “ImageStream”, “apiVersion”: “v1”, “metadata”: { “name”: “ivops-mariadb”, “creationTimestamp”: null }, “spec”: { “dockerImageRepository”: “dtr.ivops.cn:5443/ivops/mariadb”, “tags”: [ { “name”: “v1.1.x”, “annotations”: null, “from”: { “kind”: “DockerImage”, “name”: “dtr.ivops.cn:5443/ivops/mariadb:v1.1.x” }, “generation”: 1, “importPolicy”: { “insecure”: true } } ] } }
oc create -f ivops-mariadb.json -n s2i-project
./media/image32.png
创建template,为以后快捷创建
oc export dc,svc,route -o json –as-template=ivops-mariadb > ivops-mariadb.template
把 “image”: “dtr.ivops.cn:5443/ivops/mariadb”, 改为 “image”: “” 这样做的目的是,根据 template 创建应用后,自动发布,不用再手工点击 Deploy。
oc create -f ivops-mariadb.template -n openshift
  • Deployer Image镜像需要以Root启动,导致启动失败
oadm policy add-scc-to-user anyuid -z default
参考链接:https://blog.openshift.com/getting-any-docker-image-running-in-your-own-openshift-cluster/
  • 若没有DNS Server解析Route的地址,需配置本地Host

    • 手动添加解析将“Route URL”指向Router服务所在的IP地址
./media/image33.png
./media/image34.png
  • 创建PVC的容量小于等于PV的容量

  • Registry-console控制台用户登陆,配置权限给用户dev

oc adm policy add-cluster-role-to-user cluster-admin dev
./media/image35.png
  • 修改资源预留配额
./media/image36.jpeg

~ ../../../../Library/Containers/com.tencent.xinWeChat/Data/Library/Application%20Support/com.tencent.xinWeChat/2.0b4.0.9/28af29c3fcfa1b71d38c69c1e52a17f1/Message/MessageTemp/9e20f478899dc29eb19741386f9343c8/Image/931514879804_.pic_hd.jp

OpenShift架构了解与实践

发表于 2018-04-25 | 分类于 OpenShift

=======================

OpenShift Origin 与OPENSHIFT CONTAINER PLATFORM对比

参考链接:http://t.cn/RlPRzS5
./media/image1.png

启动OpenShift Origin

准备工作

  • 虚拟机配置如下:
CPU 内存 磁盘 系统 安装模式
1核 2GB 20GB Centos7.2 Minimal
  • 操作系统配置:
#配置固定IP
#试验环境关闭防火墙
#配置主机名
hostnamectl set-hostname master.example.com
#修改hosts
Vi /etc/hosts
#添加主机名记录
172.16.142.132 master.example.com

安装docker

#Yum安装
yum install docker -y
#配置启动服务
systemctl enable docker && systemctl start docker
#修改docker镜像站
vim /etc/sysconfig/docker
OPTIONS=’–selinux-enabled –log-driver=journald –signature-verification=false –registry-mirror=https://docker.mirrors.ustc.edu.cn’
systemctl restart docker

下载OpenShift Origin安装包

#书中使用版本为1.3.0,目前最新为3.6,可在github release中下载,URL: https://github.com/OpenShift/origin/releases
cd /opt
wget https://github.com/OpenShift/origin/releases/download/v1.3.0/OpenShift-origin-server-v1.3.0-3ab7af3d097b57f933eccef684a714f2368804e7-linux-64bit.tar.gz
#解压
tar zxvf https://github.com/OpenShift/origin/releases/download/v1.3.0/OpenShift-origin-server-v1.3.0-3ab7af3d097b57f933eccef684a714f2368804e7-linux-64bit.tar.gz
#建软连接
ln -s OpenShift-origin-server-v1.3.0-3ab7af3d097b57f933eccef684a714f2368804e7-linux-64bit /opt/OpenShift
./media/image2.png
#添加环境变量
vim /etc/profile PATH=\$PATH:/opt/OpenShift/
source /etc/profile

验证启动

#查看版本
openshift version
./media/image3.png
#启动
cd /opt/openshift
openshift start &
#注: #“OpenShift start”命令启动是为了可以在控制台看到日志输出; #正式环境官方推荐使用“oc cluster up”方式启动。
#当日志停止输出表示启动完成
#浏览器访问https://master.example.com:8443
./media/image4.png
默认账号密码dev:dev

简单使用OpenShift

运行容器应用

  • 创建项目
#登陆后的初始页,点击“New Project”
./media/image5.png
#填入相应信息
./media/image6.png
  • 部署Docker镜像
#通过“Deploy Image”部署
./media/image7.png
./media/image8.png
./media/image9.png
#启动成功
./media/image10.png
  • 访问容器应用
#确认应用IP
./media/image11.png
#终端访问测试
curl 172.30.248.254:8080
./media/image12.png

使用命令行工具

#命令行登陆
oc login -u dev https://172.16.142.132:8443
./media/image13.png
#创建project
oc new-project hello-world-oc
./media/image14.png
#部署应用
oc new-app OpenShift/hello-world
#查看状态
oc get pod

集群管理员登陆

  • 配置证书
默认集群管理员是system:admin,没有密码,只能通过证书登陆
mkdir -p ~/.kube
cp /opt/OpenShift/OpenShift.local.config/master/admin.kubeconfig ~/.kube/config
#重复覆盖
./media/image15.png
  • 命令登陆
oc login -u system:admin
./media/image16.png oc whoami
./media/image17.png
oc get node
./media/image18.png

添加Router

#Router是OpenShift集群中的一个重要组件,它是外部访问集群内容器应用的入口。 #集群外部的请求都会到达Router,由Router分发到具体的容器中。
# Router组件需要读取集群的信息,所以它需要关联一个系统账号Service Account,并为这个账号授权。
oc login –u system:admin
oc project default
./media/image19.png
#配置权限策略
oadm policy add-scc-to-user privileged system:serviceaccount:default:router
#创建Router #在实际生产时,为了达到高可用的效果,可以通过设置–replicas创建多个Router实例防止单点失效。
oadm router router –replicas=1 –service-account=router
./media/image20.png
#查看Router状态
oc get pod –n default
ss -ltn\ egrep -w ‘80\ 443’
./media/image21.png
#Router就是一个运行在容器里的Haproxy #用户可以创建route对象,称为route规则,一个route规则会与一个service相关联,并且绑定一个域名。 #route规则会被Router加载。当用户通过指定的域名访问应用时,域名会被解析并指向Router所在的计算节点上。Router获取这个请求后,会根据route规则定义转发给与这个域名对应的service后端相关联的Pod容器实例。
#Router负责将集群外的请求转发到集群的容器。
#Service负责将集群内的请求转发到指定的容器。
#一个对外,一个对内。

添加Registry

  • 这里的Registry是部署集群内部的Docker镜像仓库。从功能上来说,它与其他诸如DockerHub没有本质上的区别,只是这个内部镜像仓库会存储由Source
    to
    Image(S2I)创建的镜像。S2I的工作是辅助将应用的源代码转换成可以部署的Docker镜像。
一个典型的S2I流程包括如下:
用户输入源代码仓库的地址。
  1. 用户选择S2I构建的基础镜像(Builder镜像)。OpenShift提供了多种编程语言的Builder镜像,用户也可以定制自己的Builder镜像,并发布到服务目录中。

  2. 系统或用户触发S2I构建。OpenShift将实例化S2I构建执行器。

  3. S2I构建执行器将从用户指定的代码仓库下载源代码。

  4. S2I构建执行器实例化Builder镜像,并将代码注入Builder镜像中。

  5. Builder镜像将根据预定义的逻辑执行源代码的编译、构建并完成部署。

  6. S2I构建执行器将完成操作的Builder镜像并生成新的Docker镜像。

  7. S2I构建执行器将新的镜像推送到OpenShift内部的镜像仓库中。

  8. S2I构建执行器更新该次构建相关的Image Stream信息。

S2I还可以接受Dockerfile以及二进制文件作为构建的输入。用户甚至可以完全自定义构建逻辑。

  • 开始添加
#以管理员登陆,并切换到default Project
oc login -u system:admin
oc project default
#部署Registry
oadm registry –config=/opt/OpenShift/OpenShift.local.config/master/admin.kubeconfig –service-account=registry
./media/image22.png
#查看状态
oc get pod -n default
./media/image23.png
  • 添加非HTTPS验证
#这里部署的Registry没有启用Https,所以需要修改主机上Docker的配置,让Docker能以非Https的方式连接到Registry。
vi /etc/sysconfig/docker
OPTIONS变量追加” –insecure-registry=172.30.0.0/16”
#172.30.0.0/16是在master-config.yaml里定义的服务网络的默认值,如果需要修改,则master-config.yaml和/etc/sysconfig/docker需要一致修改。
./media/image24.png
#重启Docker
systemctl restart docker

添加Image Stream

#Image Stream是一组镜像的集合,可以在一个Image Stream中定义一些名称及标签(tag),并定义这些名字及标签指向的具体镜像。 #使用Image Stream的目的是方便地将一组相关联的镜像进行整合管理和使用。 #OpenShift默认为用户定义了一系列开箱即用的Image Stream。
#以管理员登陆,并切换到OpenShift Project #OpenShift是一个特殊的项目,在这个项目下创建的所有Image Stream及Template对集群内所有的用户和项目可见。
oc login -u system:admin
oc project openshift
#导入Image Stream
curl -k https://raw.githubusercontent.com/OpenShift/origin/v1.3.0/examples/image-streams/image-streams-centos7.json\ oc create -f - -n OpenShift
./media/image25.png
#查看Image Stream对象
oc get is -n openshift
./media/image26.png
#web console验证
#登录web console,重新建立工程,可以在界面上看到导入Image Stream之后的可用镜像列表
./media/image27.png

添加Template

#为了满足用户对复杂应用部署的需求,提供应用部署的效率,OpenShift引入了应用部署模板(Template)的概念。 #通过Template,可以定义一个或多个需要部署的镜像,定义依赖的对象,定义可供用户输入的配置参数项。
#以管理员登录,并切换到OpenShift工程。
oc login -u system:admin
oc project openshift
#以cakephp-mysql模版为例
oc create -f https://raw.githubusercontent.com/OpenShift/origin/v1.3.0/examples/quickstarts/cakephp-mysql.json -n openshift
#https://github.com/OpenShift/origin/tree/release-1.3/examples/quickstarts下有官方提供的一系列模版可用 #最新3.6版本:https://github.com/OpenShift/origin/tree/release-3.6/examples/quickstarts
./media/image28.png
#查看模版信息
oc get template -n openshift
./media/image29.png
#查看模版json信息
oc get template cakephp-mysql-example -o json -n openshift
#web console验证
./media/image30.png

模版部署应用

#新建Project
./media/image31.png
#过滤cake,选中cakephp-mysql-example模版
./media/image32.png
#指定主机名
#本地修改hosts #172.16.142.132 php.apps.example.com
./media/image33.png
#创建
./media/image34.png
#部署完成页面
./media/image35.png
#单机”Continue to overview”
#跳转到项目的概览页面。Openshif会在后台创建相应的对象,并下载相关的镜像。 #由于CakePHP应用涉及一个镜像构建的过程,即Source to Image,所以构建速度较慢。
./media/image36.png
#由于网络原因,这里从github拉代码失败了
./media/image37.png
./media/image38.png

应用的构建与部署

JAVA应用容器化

  • 执行容器化的环境为Centos7.2

  • Github项目地址:https://github.com/nichochen/mybank-demo-maven

#安装git和maven
yum install git maven -y
#下载源码
cd /opt/
git clone https://github.com/nichochen/mybank-demo-maven.git
#编译及构建应用
cd mybank-demo-maven/
mvn package
./media/image39.png
#构建完毕。会在target目录下生成一个WAR包ROOT.war
./media/image40.png
#选择Tomcat7官方镜像pull到本地
docker pull tomcat:7.0.70-jre7-alpine
#编写Dockerfile,把构建好的应用部署包拷贝到发布目录
cat Docekrfile FROM tomcat:7.0.70-jre7-alpine ADD ./target/ROOT.war /usr/local/tomcat/webapps/mybank.war
./media/image41.png
#执行Docker Build构建镜像
docker build -t mybank-tomcat .
./media/image42.png
#查看生成的新镜像
docker images \ grep mybank-tomcat
./media/image43.png
#测试run镜像
docker run -it –rm -p 8080:8080 mybank-tomcat
#访问IP:8080即可看到访问页面
#推送镜像到私有仓库
#打tag
docker tag mybank-tomcat:latest registry.your-registry.com/mybank-tomcat:latest
#推送
docker push registry.your-registry.com/mybank-tomcat:latest

OpenShift的构建与部署

2.1. 快速构建部署一个应用

#web console创建一个应用
./media/image44.png
#选择“wildfly:10”的Builder镜像
./media/image45.png
#输入示例项目代码地址:https://github.com/nichochen/mybank-demo-maven
./media/image46.png
./media/image47.png
#如果构建日志报错,尝试手动先pull需要的镜像 #docker pull OpenShift/wildfly-100-centos7
#日中可以看到构建的过程
./media/image48.png
#构建到最后可以看到是将生成的镜像推送到内部的镜像仓库中(Registry)
./media/image49.png
#完成状态
./media/image50.png
#查看本地Docker镜像列表,可以看到mybank镜像
docker images \ grep mybank
./media/image51.png
#查看应用状态
oc get pod -n mybank
./media/image52.png

2.2. 镜像构建介绍

  • Build Config
#在上一个实例中,单击create后,OpenShift会创建名为“Build Config”的对象。
#查询创建的Build Config
oc get bc
./media/image53.png
#查询bc中的具体配置信息
oc get bc mybank -o yaml
./media/image54.png
#红框中标示出bc的重要内容 #定义构建输出到了一个mybank:latest的Image Stream #源代码仓库地址 #前面制定的Builder镜像信息,没有指向某个实际的镜像,而是指向了一个Image Stream(用Image Stream的概念来管理一组镜像的集合,定义多个镜像名称和Tag,再指向实际的Docker镜像),
#查看定义的刚生成名为mybank的Image Stream
oc get is mybank
./media/image55.png
#查看详细信息 #该Image Stream实际指向了OpenShift/wildfly-100-centos7\@sha256:968b2cb9f11c347fbaa6830d33386e5d31b283bdf0060b4cff865e14f5064848
oc describe is mybank
  • Build
#Build Config只是静态的配置信息,OpenShift根据这个配置信息可以触发多次实际构建实例,构建的实例称为Build。 #一个Build Config可以被多次触发,生成多个Build
#查看mybank的build构建记录
oc get build
./media/image56.png
#查看build构建详细信息,这里的信息与web console下看到的日志信息相同
oc log build/mybank-1
#可以通过之前的Build Config再执行一个新的Build构建
oc start-build mybank
oc get build
./media/image57.png
#查看新的构建状态
oc logs build/mybank-2

2.3. 镜像部署介绍

  • Deployment Config
#当前文的Build构建完成,就是S2I流程完成后,生成的应用镜像被推送到内部的镜像仓库,同时更新相关的Image Stream,之后OpenShift就会触发一次部署,部署也有配置定义对象:Deployment Config。DC描述了镜像部署的参数和要求
#查看Deployment Config列表
oc get dc
./media/image58.png
#查看dc详细定义
oc get dc mybank -o yaml
#在Deployment Config中,可以定义容器运行的细节配置 ,如容器的启动命令,容器可用的CPU和内存配置等等。
  • Deploy
#每个DC可以被多次触发,每一次触发称为一个Deploy #每一次Deploy都会生成一个Replication Controller,用以监控容器的状态,RC实际是kubernetes中的一个组件,其负责监控容器的实际数量
#查看Replication Controller
oc get rc
./media/image59.png

2.4. 服务的连通性介绍(Service & Route)

  • Service
#在部署应用时,OpenShift会自动生成DC对应的Service
oc get svc
oc describe svc mybank
./media/image60.png
  • Route
#基于Service,OpenShift同时也自动创建了对应的Route
oc get route
oc describe route mybank
./media/image61.png
#修改指定域名
oc edit route

弹性伸缩

  • Replication Controller
#正常情况下,每一个部署的应用的容器实例数量在其Deployment Config中定义,OpenShift会为每次的部署实例化一个RC(可以不定义RC)
#查看当前mybank应用活动实例数为1
oc get pod
./media/image62.png
  • 扩展容器实例
#通过RC,可以调整实例存着的数量
oc scale dc mybank –replicas=2
./media/image63.png
#可以看到pod变为2个,rc中的数量也已经被更新为2
  • 状态自服务
#删除运行中的pod,测试rc恢复pod
oc delete pod mybank-1-5ek1w
oc get pod
./media/image64.png
#可以看到其中一个pod被删除的瞬间,一个新的pod同时被创建了
#RC的作用就是监控容器状态,并始终保持正常运行的pod数量

应用更新发布

  • 触发更新构建
#Build Config信息中可以看到定义了两个WebHook触发器 #Generic WebHook #GitHub WebHook
oc get bc mybank -o yaml
./media/image65.png
#在web console中可以看到实际的调用地址
./media/image66.png
# Generic WebHook使用,只需向调用地址发送POST请求即可触发
curl -k -X POST https://172.16.142.132:8443/oapi/v1/namespaces/mybank/buildconfigs/mybank/webhooks/a62289d1f901ea32/generic
./media/image67.png
./media/image68.png
#post请求发送到OpenShift之后,一个新的build就产生并开始执行
#GitHub WebHook需要用户登陆到GitHub
  • 更新部署
#构建结束后,更新部署被触发,OpenShift有Rolling(滚动更新)和Recreate(重新创建)两种,默认是Rolling
#更新策略在Deployment Config中定义
oc get dc mybank -o yaml
./media/image69.png

持续集成与部署

部署Jenkins服务

  • OpenShift提供了集成OpenShift插件的Jenkins容器镜像和部署模版

  • 默认提供两个Jenkins部署模版:Jenkins-ephemeral(测试验证用)和jenkins-persistent(持久化支持)

#以dev用户登陆
oc login -u dev
#创建名为ci的新项目用来部署jenkins
oc new-project ci
./media/image70.png
#下载并导入Jenkins模版Jenkins-ephemeral
oc create -f https://raw.githubusercontent.com/openshift/origin/v1.3.0/examples/jenkins/jenkins-ephemeral-template.json
./media/image71.png
oc get template
./media/image72.png
#为默认的Service Account用户添加权限,使Jenkins容器有足够的权限操作项目的配置及执行部署
oc policy add-role-to-user edit -z default
#通过Jenkins模版部署Jenkins服务,指定默认管理员密码为123\@abcd
oc new-app –template=jenkins-ephemeral –param=JENKINS_PASSWORD=123\@abcd
./media/image73.png
#时间稍长,应为需要联网下载jenkins镜像 #查看服务状态
oc get pod
./media/image74.png
#Jenkins模版中定义了Route,通过指定的主机名(配好hosts,手动添加解析将jenkins-ci.router.default.svc.cluster.local指向Router服务所在的IP地址),便可以访问Jenkins服务
oc get route
./media/image75.png
#访问Jenkins服务 #https://jenkins-ci.router.default.svc.cluster.local/ #admin:123\@abcd
./media/image76.png
./media/image77.png

触发项目构建

  • Jenkins部署好了之后,就可以在jenkins上出发mybank的S2I构建
#为jenkins授权,可以在mybank项目中执行操作
oc policy add-role-to-user edit system:serviceaccount:ci:jenkins -n mybank
#创建Jenkins项目,Jenkins界面操作
./media/image78.png
./media/image79.png
./media/image80.png
./media/image81.png
  • 手动触发构建
#Jenkins控制台首页
./media/image82.png
#查看构建输出
./media/image83.png

应用数据持久化

持久化镜像仓库

  • 检查挂载点
oc login -u system:admin
oc project default
oc get pod
./media/image84.png
#通过oc volume查看Registry组件的DC关于Volume的定义,创建了一个Volume Mounts对象registry-storage,这个挂载点指向了/registry目录 #我们要做的就是给registry-storage这个挂载点挂上一个持久化后端
oc get dc
oc volumes dc/docker-registry –all
./media/image85.png
  • 备份数据
#当前Registry容器内的/registry目录下已有很多镜像相关的文件
oc get po
oc rsh docker-registry-1-akri7 ‘du’ ‘-sh’ /registry
./media/image86.png
#需要先备份这些文件,通过ocrsync命令同步到宿主机上
mkdir /root/backup cd /root/backup
oc rsync docker-registry-1-akri7:/registry .
./media/image87.png
  • 创建存储
#选用NFS作为后端存储,生产环境可使用GlusterFS,Ceph
#创建一个NFS共享目录
mkdir -p /exports/pv0001 yum -y install nfs-utils rpcbind chown nfsnobody:nfsnobody /exports/ -R echo “/exports/pv0001 *(rw,sync,all_squash)” >> /etc/exports systemctl start rpcbind exportfs -r systemctl start nfs-server showmount -e 127.0.0.1
setenforce 0
getenforce
#测试挂载
[root\@master ~]# mount 172.16.142.132:exports/pv0001 /mnt/ [root\@master ~]# [root\@master ~]# [root\@master ~]# touch /mnt/test [root\@master ~]# ls /mnt/ test [root\@master ~]# rm -rf /mnt/test [root\@master ~]# umount /mnt/
  • 创建持久化卷
#创建pv.json文件
[root\@master ~]# more pv.json { “apiVersion”: “v1”, “kind”: “PersistentVolume”, “metadata”: { “name”: “pv0001” }, “spec”: { “capacity”: { “storage”: “5Gi” }, “accessModes”: [ “ReadWriteOnce” ], “nfs”: { “path”: “/exports/pv0001”, “server”: “172.16.142.132” }, “persistentVolumeReclaimPolicy”: “Retain” } }
oc create -f pv.json
oc get pv
./media/image88.png
  • 创建持久化卷请求
#创建pvc.json文件
[root\@master ~]# more pvc.json { “apiVersion”: “v1”, “kind”: “PersistentVolumeClaim”, “metadata”: { “name”: “docker-registry-claim” }, “spec”: { “accessModes”: [ “ReadWriteOnce” ], “resources”: { “requests”: { “storage”: “3Gi” } } } }
oc create -f pvc.json
oc get pvc
oc get pv
./media/image89.png
  • 关联持久化卷请求
#将备份的文件恢复到创建的nfs目录中
mv /root/backup/registry/* /exports/pv0001/
chown nfsnobody:nfsnobody /exports/ -R
#测试删除Registry容器,RC将会重新创建它
oc get pod
oc delete pod docker-registry-1-akri7
./media/image90.png
#容器启动后,再次检查/registry目录,发现数据消失,应为之前并没有做持久化
oc rsh docker-registry-1-fqtfp ‘du’ ‘-sh’ /registry
./media/image91.png
#为Registry的容器添加持久化卷请求,docker-registry-claim,并与挂载点registry-storage关联
oc volume dc/docker-registry –add –name=registry-storage -t pvc –claim-name=docker-registry-claim –overwrite
#DC被修改后,Openshift会创建新的容器实例
#再次检查容器的/registry目录,发现目录数据恢复了
oc volume dc/docker-registry –add –name=registry-storage -t pvc –claim-name=docker-registry-claim –overwrite
oc get pod
oc rsh docker-registry-2-f36ot ‘du’ ‘-sh’ /registry
./media/image92.png

监控与日志管理

容器集群数据采集

容器集群日志管理

  • 使用开源方案EFK:Elasticsearch,Fluentd,Kibana

    • Fluentd:将以容器方式运行在集群的各个节点上。读取宿主机上的/var/log/message及/var/lib/docker目录下的系统及容器日志信息,并对信息进行格式化成JSON格式,最好发送给Elasticsearch

    • Elasticsearch:收到日志信息后,存储信息并建立索引

    • Kibana:提供图形界面用用户检索分析Elasticsearch中的日志

    • AuthProxy:为Kibana实现身份验证,与Openshift Web实现单点登陆

    • Curator:管理和优化Elasticsearch索引

  • 创建部署模版

#管理员身份登陆
oc login –u system:admin
#下载部署模版并解压
wget https://github.com/openshift/origin-aggregated-logging/archive/v1.3.0.tar.gz
tar zxvf v1.3.0.tar.gz
#导入日志部署模版
oc create -n openshift -f origin-aggregated-logging-1.3.0/deployer/deployer.yaml
  • 配置Service Account
#新建项目
oadm new-project logging –node-selector=””
oc project logging
#创建应用部署的Service Account账号
oc new-app logging-deployer-account-template
#配置服务授权
oadm policy add-cluster-role-to-user oauth-editor \ system:serviceaccount:logging:logging-deployer
oadm policy add-scc-to-user privileged \ system:serviceaccount:logging:aggregated-logging-fluentd
oadm policy add-cluster-role-to-user cluster-reader \ system:serviceaccount:logging:aggregated-logging-fluentd
  • 配置证书
#创建应用组件使用的证书,并创建Secret对象loging-deployer存储对应的证书。改Secret对象会被部署引用
oadm ca create-server-cert \ –signer-cert=/opt/openshift/openshift.local.config/master/ca.crt \ –signer-key=/opt/openshift/openshift.local.config/master/ca.key \ –signer-serial=/opt/openshift/openshift.local.config/master/ca.serial.txt \ –hostnames=’kibana.apps.example.com’ \ –cert=/etc/opt/openshift/openshift.local.config/master/kibana.crt \ –key=/etc//opt/openshift/openshift.local.config/master/kibana.key
oc create secret generic logging-deployer \ –from-file kibana.crt=/etc/opt/openshift/openshift.local.config/master/kibana.crt \ –from-file kibana.key=/etc/opt/openshift/openshift.local.config/master/kibana.key
./media/image93.png
./media/image94.png
  • 部署日志组件模版
#设置集群部署参数,创建一个Config Map对象logging-deployer为日志组件的部署设定参数 #参数指定Kinbana域名,Openshift集群Master地址,Elasticsearch的实例数及使用的内存大小
oc create configmap logging-deployer \ –from-literal kibana-hostname=kibana.apps.example.com \ –from-literal public-master-url=https://master.example.com:8443 \ –from-literal es-cluster-size=1 \ –from-literal es-instance-ram=1G
./media/image95.png
#通过模版部署日志组件
#网络原因,提前下好所需镜像
for i in openshift/origin-logging-curator:v1.3.0 \ openshift/origin-logging-fluentd:v1.3.0 \ openshift/origin-logging-auth-proxy:v1.3.0 \ openshift/origin-logging-deployment:v1.3.0 \ openshift/origin-logging-elasticsearch:v1.3.0 \ openshift/origin-logging-kibana:v1.3.0 ; do docker pull \$i; done
oc new-app logging-deployer-template \ –param IMAGE_VERSION=v1.3.0 \ –param IMAGE_PREFIX=openshift/origin- \ –param MODE=install
1…345…14

Chen Fei

把我的过程记录下来,以免以后忘了

68 日志
15 分类
40 标签
© 2019 Chen Fei
由 Hexo 强力驱动 v3.7.1
|
主题 – NexT.Mist v6.3.0