点对点配置

• RA配置:

  1 2 3 4 5 6 7

  [RA]int s0/0 [RA-s0/0]encap frame-relay 封装帧中继协议 [RA-s0/0] frame-relay intf dte [RA-s0/0]frame-relay interface-dlci 102 设置本接口对应的INTERFACE-DLCI号 [RA-s0/0]frame-relay map ip 172.16.1.2 102 建立对端协议地址与本地INTERFACE-DLCI号的映射关系 [RA-s0/0]ip add 172.16.1.1 255.255.255.0 配置本接口IP地址 [RA-s0/0]no sh 打开此物理接口

• RB配置:

  1 2 3 4 5 6 7

  [RB]int s0/0 [RB-s0/0]encap frame-relay 封装帧中继协议 [RA-s0/0] frame-relay intf dte [RB-s0/0]frame-relay interface-dlci 201 设置本接口对应的INTERFACE-DLCI号 [RB-s0/0]frame-relay map ip 172.16.1.1 201 建立对端协议地址与本地INTERFACE-DLCI号的映射关系 [RB-s0/0]ip add 172.16.1.2 255.255.255.0 配置本接口IP地址 [RB-s0/0]no sh 打开此物理接口

基于jenkins的CI/CD安装

        jenkins一个流行的持续集成/发布工具，在Kubernetes使用,持续构建与发布是我们日常工作中必不可少的一个步骤，目前大多公司都采用 Jenkins 集群来搭建符合需求的 CI/CD 流程，然而传统的 Jenkins Slave 一主多从方式会存在一些痛点，比如：主 Master 发生单点故障时，整个流程都不可用了；每个 Slave 的配置环境不一样，来完成不同语言的编译打包等操作，但是这些差异化的配置导致管理起来非常不方便，维护起来也是比较费劲；资源分配不均衡，有的 Slave 要运行的 job 出现排队等待，而有的 Slave 处于空闲状态；最后资源有浪费，每台 Slave 可能是实体机或者 VM，当 Slave 处于空闲状态时，也不会完全释放掉资源。

        提到基于Kubernete的CI/CD，可以使用的工具有很多，比如Jenkins、Gitlab CI已经新兴的drone之类的，我们这里会使用大家最为熟悉的Jenins来做CI/CD的工具。

• 优点:
  • Jenkins 安装完成了，接下来我们不用急着就去使用，我们要了解下在 Kubernetes 环境下面使用 Jenkins 有什么好处。都知道持续构建与发布是我们日常工作中必不可少的一个步骤，目前大多公司都采用 Jenkins 集群来搭建符合需求的 CI/CD 流程，然而传统的 Jenkins Slave 一主多从方式会存在一些痛点，比如:
    • E 主 Master 发生单点故障时，整个流程都不可用了。
    • E 每个 Slave 的配置环境不一样，来完成不同语言的编译打包等操作，但是这些差异化的配置导致管理起来非常不方便，维护起来也是比较费劲。
    • E 资源分配不均衡，有的 Slave 要运行的 job 出现排队等待，而有的 Slave 处于空闲状态。
    • E 资源有浪费，每台 Slave 可能是物理机或者虚拟机，当 Slave 处于空闲状态时，也不会完全释放掉资源。
  • 正因为这些种种痛点，我们渴望一种更高效更可靠的方式来完成这个 CI/CD 流程，而 Docker 虚拟化容器技术能很好的解决这个痛点，又特别是在 Kubernetes 集群环境下面能够更好来解决上面的问题，下图是基于 Kubernetes 搭建 Jenkins 集群的简单示意图
    

        可以看到 Jenkins Master 和 Jenkins Slave 以 Pod 形式运行在 Kubernetes 集群的 Node 上，Master 运行在其中一个节点，并且将其配置数据存储到一个 Volume 上去，Slave 运行在各个节点上，并且它不是一直处于运行状态，它会按照需求动态的创建并自动删除。

    nfs-client-provisioner是一个automatic provisioner，使用NFS作为存储，自动创建PV和对应的PVC，本身不提供NFS存储，需要外部先有一套NFS存储服务。

• PV以 ${namespace}-${pvcName}-${pvName}的命名格式提供（在NFS服务器上）
• PV回收的时候以 archieved-${namespace}-${pvcName}-${pvName} 的命名格式（在NFS服务器上）

官方访问地址

1、权限体系构建

1.1、创建serviceaccount

ServiceAccount也是一种账号, 供运行在pod中的进程使用, 为pod中的进程提供必要的身份证明.

1
2
3
4
5
6

# cat serviceaccount.yaml 
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  namespace: kube-test

1、介绍

    PersistentVolume（pv）和PersistentVolumeClaim（pvc）是k8s提供的两种API资源，用于抽象存储细节。管理员关注于如何通过pv提供存储功能而无需关注用户如何使用，同样的用户只需要挂载pvc到容器中而不需要关注存储卷采用何种技术实现。
    pvc和pv的关系与pod和node关系类似，前者消耗后者的资源。pvc可以向pv申请指定大小的存储资源并设置访问模式,这就可以通过Provision -> Claim 的方式，来对存储资源进行控制。

2、生命周期

pv和pvc遵循以下生命周期：

• 供应准备。通过集群外的存储系统或者云平台来提供存储持久化支持。

• 静态提供：管理员手动创建多个PV，供PVC使用。

• 动态提供：动态创建PVC特定的PV，并绑定。

  • 绑定。用户创建pvc并指定需要的资源和访问模式。在找到可用pv之前，pvc会保持未绑定状态。
  • 使用。用户可在pod中像volume一样使用pvc。
  • 释放。用户删除pvc来回收存储资源，pv将变成“released”状态。由于还保留着之前的数据，这些数据需要根据不同的策略来处理，否则这些存储资源无法被其他pvc使用。
  • 回收(Reclaiming)。pv可以设置三种回收策略：保留（Retain），回收（Recycle）和删除（Delete）。

• 保留策略：允许人工处理保留的数据。

• 删除策略：将删除pv和外部关联的存储资源，需要插件支持。

• 回收策略：将执行清除操作，之后可以被新的pvc使用，需要插件支持。

目前只有NFS和HostPath类型卷支持回收策略，AWS EBS,GCE PD,Azure Disk和Cinder支持删除(Delete)策略。

2.1、Provisioning

两种方式提供的PV资源供给

1.环境准备

一个master节点，四个node节点
master节点ip

• 172.21.16.244
  node节点ip
• 172.21.16.24
• 172.21.16.231
• 172.21.16.202
• 172.21.16.55

• 以下是每一个节点上均进行操作

2、服务器添加阿里云yum源

1
2
3
4
5
6
7
8
9
10

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=http://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg
  http://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF

3、重新建立yum缓存

1

# yum -y install epel-release &&yum clean all &&yum makecach

• 记得同步系统的时间

3、配置转发请求

Centos5.5 32bit安装DRBD

• 安装前准备

在主节点安装DRBD

1

[root@node2 ~]# yum -y install kmod-drbd83 drbd83

安装成功之后/sbin目录下面有drbdadm，drbdmeta，drbdsetup命令，以及/etc /init.d/drbd启动脚本。

• 备用节点安装DRBD

1

[root@node1 ~]# yum -y install kmod-drbd83 drbd83

安装完成后。默认配置文件/etc/drbd.conf，以下是两台的主机配置实例:

oracle ORA-12519错误解决
今天遇到做系统压力测试的时候，系统报了一个错误
OERR: ORA-12519 TNS:no appropriate service handler found

在网上搜索了一下oralc的错误信息ORA-12519，解决办法挺多的，这里记录一下

登陆oracle的服务器，在登陆oracle数据库

1

sqlplus "/as sysdba"

首先检查process和session的使用情况

nginx http 强制跳转到https

方法一

1
2
3

if ($scheme = http ) {
    return 301 https://$host$request_uri;
}

• 列子

1
2
3
4
5
6
7
8
9

server {
    listen 80;
    listen 443;
    server_name xxx.test.com;
    index index.html index.php index.htm;
    if ($scheme = http ) {
        return 301 https://$host$request_uri;
    }
}

方法二

1
2
3

if ($server_port = 80 ) {
    return 301 https://$host$request_uri;
}

• 列子

本文主要是代理kubernetes master的高可用。

安装haproxy和keepalived

1
2

# yum -y install keepalived
# yum -y install haproxy

Prometheus是一个集数据收集存储、数据查询和数据图表显示于一身的开源监控组件。本文主要讲解如何搭建Prometheus，并使用它监控Kubernetes集群。

1、下载相关yaml

1
2
3
4
5
6
7
8
9
10
11

# https://github.com/xxlaila/kubernetes-yaml/tree/master/prometheus-grafana
# ls -l
configmap.yaml
grafana-deploy.yaml
grafana-ingress.yaml
grafana-svc.yaml
node-exporter.yaml
prometheus-deploy.yaml
prometheus-svc.yaml
rbac-setup.yaml
prometheus-ingress.yaml

2、开始部署

2.1、采用daemonset方式部署node-exporter组件

1

# kubectl create -f  node-exporter.yaml