#首先在其中一个master上登录私有仓库$ docker login registry.linux.xyz#登录成功后会在/root/.docker目录下生产config.json文件,然后执行如下命令:$ cat / 阅读全文

#首先在其中一个master上登录私有仓库
$ docker login registry.linux.xyz
#登录成功后会在/root/.docker目录下生产config.json文件,然后执行如下命令:
$ cat /root/.docker/config.json | base64
该命令会将你的认证信息通过base64编码,生成一个编码之后的字符串,在linux中terminal中看到是两行,但是其实质是一行,所以之后要用到的这个字符串需要合并为一行。
 
#在kubernetes中的master节点中创建secret 元素
$ cat imagePullSecret.yaml
 
apiVersion: v1
kind: Secret
metadata:
name: sec-default
namespace: default
data:
.dockerconfigjson: ewoJImF1dGhzIjogewoJCSIxNzIuMjAuODguNiI6IHsKCQkJImF1dGgiOiAiWVdSdGFXNDZTR0Z5WW05eU1USXpORFU9IgoJCX0KCX0KfQ==
type: kubernetes.io/dockerconfigjson

其中name你可以随便取,namespaces也必须指定,此secret只作用于当前指定的namespace
 
#创建secret
$ kubectl create -f imagePullSecret.yaml
#添加serviceaccounts认证
kubectl patch serviceaccounts default -p '{"imagePullSecrets": [{"name": "sec-default"}]}' -n default
#在pod中测试,指定imagesPullSecrets即可
apiVersion: v1
kind: Pod
metadata:
name: nginx-img
labels:
app: nginx-img
spec:
containers:
- name: nginx-img
image: registry.linux.xyz/test1/nginx
ports:
- containerPort: 80
imagePullSecrets:
- name: sec-default


 
kim

发表了文章

  • 0个评论
  • 56次浏览
  • 2018-04-27 10:55

Kubernetes 集群中的垃圾回收 GC 机制由 Kubelet 完成。Kubelet 定期清理不再使用的容器和镜像,每分钟进行一次容器 GC 操作,每五分钟进行一次镜像 GC 操作。 一、容器的 GC 设置 能 阅读全文

Kubernetes 集群中的垃圾回收 GC 机制由 Kubelet 完成。Kubelet 定期清理不再使用的容器和镜像,每分钟进行一次容器 GC 操作,每五分钟进行一次镜像 GC 操作。

一、容器的 GC 设置

能够被 GC 清理的容器只能是仅由 Kubelet 管理的容器。在 Kubelet 所在的 Node 上直接通过 docker run 创建的容器将不能被 Kubelet 进行 GC 清理操作。
 
  • --minimum-container-ttl-duration:已停止的容器在被清理之前的最小存活时间,如:“300ms”,“10s”,“24h45m”,超过此存活时间的容器将被标记为可被 GC 清理,默认值为 1 分钟。
  • --maximum-dead-containers-per-container:以 Pod 为单位的可以保留的已停止的(属于同一 Pod 的)容器集的最大数量。有时,Pod 中容器运行失败或者健康检查失败后,会被 Kubelet 自动重启,这将产生一些停止的容器。默认值是2。
  • --maximum-dead-containers:在本 Node 上保留的已停止容器的最大数量,用于停止的容器也会消耗磁盘空间,所以超过该上线以后,Kubelet 会自动清理已停止的容器以释放磁盘空间,默认值240。


如果需要关闭针对容器的 GC 操作,则可以将 --minimum-container-ttl-duration 设置为 0 ,将 --maximum-dead-containers-per-container 和 --maximum-dead-containers 设置为负数。

 

二、镜像的 GC 设置

Kubernetes 系统中通过 imageContaroller 和 kubelet 中集成的 cAdvisor 共同管理镜像的生命周期,主要根据本 Node 的磁盘使用率来触发镜像的 GC 操作。
  • --minimum-image-ttl-duration:不再使用的镜像在被清理之前的最小存活时间,例如:“300ms”,“10s”,“24h””45m”,超过此存活时间的镜像被标记为可被 GC 清理,默认值为两分钟。
  • --image-gc-high-threshold:当磁盘使用率到达该值时,触发镜像的 GC 操作,默认值为 90%。
  • --image-gc-low-threshold:当磁盘使用率降到该值时,GC 操作结束,默认值为 80%。


删除镜像的机制为:当磁盘删除率到达 image-gc-high-threshold 时触发,GC 操作从最久未使用的镜像开始删除,直到磁盘使用率降为 image-gc-low-threshold 或没用镜像可删为止。
kim

发表了文章

  • 0个评论
  • 135次浏览
  • 2018-03-20 14:24

背景   Kubernetes中的调度策略可以大致分为两种,一种是全局的调度策略,要在启动调度器时配置,包括kubernetes调度器自带的各种predicates和priorities算法,具体可以参看文章《Kuber 阅读全文

背景
 
Kubernetes中的调度策略可以大致分为两种,一种是全局的调度策略,要在启动调度器时配置,包括kubernetes调度器自带的各种predicates和priorities算法,具体可以参看文章《Kubernetes调度详解》;另一种是运行时调度策略,包括nodeAffinity(主机亲和性),podAffinity(POD亲和性)以及podAntiAffinity(POD反亲和性)。

nodeAffinity主要解决POD要部署在哪些主机,以及POD不能部署在哪些主机上的问题,处理的是POD和主机之间的关系。

podAffinity主要解决POD可以和哪些POD部署在同一个拓扑域中的问题(拓扑域用主机标签实现,可以是单个主机,也可以是多个主机组成的cluster、zone等。),podAntiAffinity主要解决POD不能和哪些POD部署在同一个拓扑域中的问题。它们处理的是Kubernetes集群内部POD和POD之间的关系。

三种亲和性和反亲和性策略的比较如下表所示:

aaddddd.jpg

 
本文主要介绍如何使用亲和性和反亲和性做资源调度。
 
使用场景介绍
 
nodeAffinity使用场景:
  •   将S1服务的所有Pod部署到指定的符合标签规则的主机上。
  •   将S1服务的所有Pod部署到除部分主机外的其他主机上。


podAffinity使用场景:
  •   将某一特定服务的pod部署在同一拓扑域中,不用指定具体的拓扑域。
  •   如果S1服务使用S2服务,为了减少它们之间的网络延迟(或其它原因),把S1服务的POD和S2服务的pod部署在同一拓扑域中。


podAntiAffinity使用场景:
  •   将一个服务的POD分散在不同的主机或者拓扑域中,提高服务本身的稳定性。
  •   给POD对于一个节点的独占访问权限来保证资源隔离,保证不会有其它pod来分享节点资源。
  •   把可能会相互影响的服务的POD分散在不同的主机上。


对于亲和性和反亲和性,每种都有三种规则可以设置:

RequiredDuringSchedulingRequiredDuringExecution:在调度期间要求满足亲和性或者反亲和性规则,如果不能满足规则,则POD不能被调度到对应的主机上。在之后的运行过程中,如果因为某些原因(比如修改label)导致规则不能满足,系统会尝试把POD从主机上删除(现在版本还不支持)。

RequiredDuringSchedulingIgnoredDuringExecution:在调度期间要求满足亲和性或者反亲和性规则,如果不能满足规则,则POD不能被调度到对应的主机上。在之后的运行过程中,系统不会再检查这些规则是否满足。

PreferredDuringSchedulingIgnoredDuringExecution:在调度期间尽量满足亲和性或者反亲和性规则,如果不能满足规则,POD也有可能被调度到对应的主机上。在之后的运行过程中,系统不会再检查这些规则是否满足。

使用示例

使用POD亲和性调度时要先开启Kubernetes调度器的MatchInterPodAffinity筛选功能,具体的操作方式是修改调度器的配置文件,在predicates中增加如下内容:
{“name” : “MatchInterPodAffinity”}
测试环境的主机信息如下:

qinhe01.png

 
其中每个主机上都有beta.kubernetes.io/arch,beta.kubernetes.io/os,kubernetes.io/hostname这几个标签,在测试过程中把这些标签当做拓扑域使用。

nodeAffinity使用示例:

使用nodeAffinity把POD部署到主机mesos-slave1和mesos-slave2上,yaml定义如下:
          {
“nodeAffinity”: {
“requiredDuringSchedulingIgnoredDuringExecution”: {
“nodeSelectorTerms”: [{
“matchExpressions”: [{
“key”: “kubernetes.io/hostname”,
“operator”: “In”,
“values”: [“mesos-slave1″,”mesos-slave2”]
}]
}]
}
}
}
创建一个有6个POD的RC,结果如下:

qinhe02.png

 
从结果可以看出POD被部署到了mesos-slave1和mesos-slave2上,mesos-slave3上没有部署POD。

podAffinity使用示例:

使用kubernetes.io/hostname作为拓扑域,把pod创建在同一主机上。其中matchExpressions中填写内容对应到RC中POD自身的标签。可以通过修改需要匹配的标签内容来控制把一个服务中的POD和其它服务的POD部署在同一主机上。

yaml中的定义如下:
{
“podAffinity”: {
“requiredDuringSchedulingIgnoredDuringExecution”: [{
“labelSelector”:
{
“matchExpressions”: [
{
“key”: “name”,
“operator”: “In”,
“values”: [“node-rc”]
}
]
},
“topologyKey”: “kubernetes.io/hostname”
}]
}

}
创建一个有3个POD的RC,结果如下:

qinhe03.png

 
所有创建的POD集中在同一个主机上,具体的主机是哪个不需要指定。

podAntiAffinity使用示例:

使用kubernetes.io/hostname作为拓扑域,把pod创建在不同主机上,每个主机上最多只有一个同类型的POD(同类型用标签区分)。其中matchExpressions中填写内容对应到RC中POD自身的标签。可以通过修改需要匹配的标签内容来控制把一个服务中的POD和其它服务的POD部署在不同主机上。

yaml中的定义如下:
{
“podAntiAffinity”: {
“requiredDuringSchedulingIgnoredDuringExecution”: [{
“labelSelector”:
{
“matchExpressions”: [
{
“key”: “name”,
“operator”: “In”,
“values”: [“node-rc”]
}
]
},
“topologyKey”: “kubernetes.io/hostname”
}]
}

}
创建一个有4个POD的RC,结果如下:

qinhe04.png

 
三个主机上都有一个POD运行,因为每个主机上最多只能运行一个这种类型的POD,所以有一个POD一直处于Pending状态,不能调度到任何节点。

上边的例子中可以通过修改topologyKey来限制拓扑域的范围,实现把相关服务部署在不同的容灾域等其它功能。

总结

Kubernetes提供了丰富的调度策略,包括静态的全局调度策略,以及动态的运行时调度策略,用户可以根据需要自由组合使用这些策略来实现自己的需求。在调度过程中,使用nodeAffnity决定资源可以部署在哪些主机上,使用podAffinity和podAntiAffinity决定哪些资源需要部署在同一主机(拓扑域)或者不能部署在同一主机。
 
 
kim

发表了文章

  • 0个评论
  • 140次浏览
  • 2018-03-19 18:00

    1.查询现有标签(labels)$ kubectl get nodes --show-labels NAME STATUS AGE LABELS 192.168.1.1 阅读全文

 
 
1.查询现有标签(labels)
$ kubectl get nodes --show-labels
NAME STATUS AGE LABELS
192.168.1.1 Ready 4d beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=192.168.1.1
192.168.1.2 Ready 4d beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=192.168.1.2
192.168.1.3 Ready 4d beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=192.168.1.3



2.新增标签
$ kubectl label node <node name> <label>=<value>
$ kubectl label node 192.168.1.1 networkSpeed=high
$ kubectl label node 192.168.1.2 networkSpeed=high
$ kubectl label node 192.168.1.2 networkSpeed=low

确认labels是否更新上去
$ kubectl get nodes --show-labels
NAME STATUS AGE LABELS
192.168.1.1 Ready 4d beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=192.168.1.1,networkSpeed=high
192.168.1.2 Ready 4d beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=192.168.1.2,networkSpeed=high
192.168.1.3 Ready 4d beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=192.168.1.3,networkSpeed=low



移除标签 (使用“ - ”减号相连)
$ kubectl label node 192.168.1.1 networkSpeed-
kim

发表了文章

  • 0个评论
  • 130次浏览
  • 2018-03-16 18:46
kim

回复了问题

  • 1个回答
  • 147次浏览
  • 2018-03-08 11:28
kim

回复了问题

  • 1个回答
  • 168次浏览
  • 2018-02-27 11:25
kim

回复了问题

  • 1个回答
  • 163次浏览
  • 2018-02-27 11:04
lindask

回复了问题

  • 2个回答
  • 256次浏览
  • 2017-10-13 15:37

相当复杂的现代Web服务大多数都不是由单体应用提供。为了处理复制的操作,应用程序通常被分解成许多服务,分别处理业务逻辑或数据存储的不同部分。这些服务可能部署在不同的机器甚或是不同的数据中心。在CloudFlare,随着服 阅读全文

相当复杂的现代Web服务大多数都不是由单体应用提供。为了处理复制的操作,应用程序通常被分解成许多服务,分别处理业务逻辑或数据存储的不同部分。这些服务可能部署在不同的机器甚或是不同的数据中心。在CloudFlare,随着服务的增加,应用程序之间安全通信的需求也在增长。他们需要一种简单、可维护的方法来确保CloudFlare内部服务之间的所有通信都始终处于安全保护之下。因此,他们基于已知且可靠的协议构建了一个这样的系统。该系统基于一个“公钥基础设施(public key infrastructure,缩写为PKI)”,使用了内部托管的认证中心(CA)。近日,CloudFlare系统工程师Nick Sullivan介绍了私有PKI构建过程和内部使用方式。

他们的方法是所有的新服务都使用一种同加密协议——传输层安全(TLS)协议——保护服务间通信。这是一种很自然的选择:HTTPS中的“S”就是TLS,它是Web加密的基础。而且,现代Web服务和API均以TLS作为应用层加密事实上的标准。它可以与RESTful服务无缝集成,并获得了Kyoto Tycoon、PostgreSQL和Go标准库的支持。另外,Nick在先前发表的一篇文章中讨论过,未经身份验证的加密可能遭受中间人攻击。也就是说,加密但不做身份验证无法在传输中保护数据。为了连接安全,每个连接方都必须向另一方提供身份标识。公钥加密技术提供了许多种信任机制,包括PGP的“信任网络(web of trust)”和HTTPS的公钥基础设施模型。由于更易于使用和部署,他们选择了PKI,由它和TLS一起提供可信任的通信。

PKI借助数字证书和公钥加密技术提供可信任的网络身份。通常,证书就是一个包含如下身份信息的文件:
 
  • 证书所有组织的信息
  • 公钥
  • 证书颁发组织的信息
  • 证书颁发组织授予的权限,如证书有效期、适用的主机名、用途等
  • 使用证书颁发组织私钥创建的数字签名 

 

1.png

 
每个公钥都有一个对应的私钥,后者在证书所有者的管控之下,可以用于对数据进行数字签名,验证器可以使用证书中的公钥对数据进行验证。如果证书本身包含第三方认证中心的数字签名,那么只要验证器信任该第三方,就可以确保证书是合法的。有时候,证书是由中介认证中心签名,而中介认证中心的证书又是由不同的认证中心签名。在这种情况下,证书验证器会沿着这条链一直找到它信任的证书。对于认证中心而言,信任链模型非常有用,它允许我们将根证书的私钥离线存储,只为中介证书签名。中介认证中心的正式存在时间较短, 可以为端点证书签名。

2.png


这与Web上HTTPS使用的系统相同。但对于不需要通过浏览器访问的内部服务,就没有必要通过第三方认证中心。也就是说,受信任证书不必由Globalsign、Comodo、Verisign或其它认证中心颁发,它们可以由你自己的CA颁发。

创建自己的认证中心(CA)

为了创建一个可以轻松获取和操作证书的内部认证中心,他们使用了自己开源的PKI工具箱CFSSL。该工具具有运行一个认证中心所需的全部功能。虽然CFSSL是为运行内部CA而创建,但它足够健壮,可以用于公开的受信任CA。实际上,Let’s Encrypt项目就使用CFSSL作为CA基础设施的一个核心部件。

运行认证中心需要一个CA证书和相应的私钥。后者是极其敏感的数据。任何知道私钥的人都可以充当CA颁发证书。因此,私钥的保护至关重要。CFSSL支持以下三种私钥保护模式:
 
  • 硬件安全模块(Hardware Security Module,缩写为HSM)
  • Red October
  • 纯文本

 
接下来,我们将沿着Nick的思路看下如何使用纯文本私钥快速配置一个内部CA。

生成CA证书和私钥

创建一个包含如下组织基本信息的文件csr_ca.json:
{
"CN": "My Awesome CA",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "US",
"L": "San Francisco",
"O": "My Awesome Company",
"OU": "CA Services",
"ST": "California"
}
]
}
执行下面的命令:
$ cfssl gencert -initca csr_ca.json | cfssljson -bare ca
该命令会生成运行CA所必需的文件ca-key.pem(私钥)和ca.pem(证书),还会生成ca.csr(证书签名请求),用于交叉签名或重新签名。

配置证书生成策略,并启动CA服务

配置证书生成策略,让CA软件知道颁发什么样的证书。下面是一个简单的示例:
config_ca.json  
{
"signing": {
"default": {
"auth_key": "key1",
"expiry": "8760h",
"usages": [
"signing",
"key encipherment",
"server auth"
]
}
},
"auth_keys": {
"key1": {
"key": <16 byte hex API key here>,
"type": "standard"
}
}
}
该策略指定了证书有效期(1年)、用途(服务器验证等)以及一个随机生成的私有验证密钥。该密钥可以防止未经授权的机构请求证书。

执行下面的命令,启动CA服务:
$ cfssl serve -ca-key ca-key.pem -ca ca.pem -config config_ca.json
证书生成与签名

截止目前,基于CFSSL的CA已经配置完成,不妨假设它运行在服务器“ca1.mysite.com”上。该CA如何颁发证书呢?CFSSL提供了两个命令:gencert和sign。gencert将自动处理整个证书生成过程。该过程需要两个文件,一个告诉CFSSL本地客户端CA的位置以及如何验证请求,另一个为CSR配置信息,用于填充CSR。下面是为一个为数据库服务db1.mysite.com创建证书的例子:

config_client.json
{
"signing": {
"default": {
"auth_key": "key1",
"remote": "caserver"
}
},
"auth_keys": {
"key1": {
"key": <16 byte hex API key here>,
"type": "standard"
}
},
"remotes": {
"caserver": “ca1.mysite.com:8888"
}
}
csr_client.json
{
"hosts": [
"db1.mysite.com"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "US",
"L": "San Francisco",
"O": “My Awesome Company",
"OU": “Data Services",
"ST": "California"
}
]
}
有了这两个文件就可以使用下面的命令为数据库服务器db1.mysite.com创建证书了:
$ cfssl gencert -config config_client.json csr_client.json | cfssljson -bare db
前面已经提到过,该命令会生成三个文件,其中db-key.pem、db.pem和db.csr,其中db.csr可以再次提交给CA,使用sign命令重新签名:
$ cfssl sign -config config_client.json db.csr | cfssljson -bare db-new
该命令会生成新证书db-new.pem。这两个命令使私有PKI搭建变得非常容易和便利。
 
使用PKI

为应用程序生成证书和密钥有两种方式:集中式和分布式。前者是指预先配置好一台中央服务器,由它创建所有的证书并发送给每台应用程序服务器;后者是指由应用服务器创建自己的私钥,并向验证中心发送证书申请。按照Nick的说法,在第一种方式中,中央服务器管理复杂,而且向应用服务器传输私钥会引入不必要的风险。相比之下,第二种方式可以按需申请证书,非常易于扩展。

确立服务之间的信任关系

浏览器通过检查证书签名以及根据“主题备用名称(Subject Alternative Names,缩写为SAN)”列表检查主机名来验证网站证书。这种显式检查有用,但可能会出现不正常情况。另一种使服务相互信任的方式是基于单服务CA的隐式检查,其思想很简单:每组服务使用不同的CA。比如,由数据库CA颁发所有数据库的证书,由API服务器CA颁发所有API服务器的证书。

3.png

 
当这些服务彼此间使用相互TLS验证进行通信时,将信任关系配置为:
  • API服务器只信任DB CA
  • DB服务器只信任API CA


配置完成后,A类型的服务将只能和B类型的服务通信。下图描述了两个应用程序如何使用相互TLS验证确立相互信任关系:

4.png

 
如上图,API 服务器信任DB CA(红色)。因此,它只接受由DB CA(带红丝带)签名的证书。反之,数据库服务器只接受由API CA(带橙丝带)签名的证书。为了建立一个受信任连接,双方互相发送一个“密钥共享(key share)”,并用它们的私钥签名。密钥共享合并到一起创建一个会话密钥,会话双方用它加密数据。

将PKI用于远程服务

内部PKI非常灵活,可以用于向集成到PKI所在网络的第三方发放证书。例如,CloudFlare有一个名为Railgun的服务,可以用于优化CloudFlare与源服务器的连接。Railgun与CloudFlare之间的通信就是使用CloudFlare认证中心颁发的证书进行加密与身份验证。这可以确保数据传输安全。

5.png

 
小结

实现应用程序层数据安全是确保分布式系统架构安全的重要一步,但只有在有一个强大的PKI时才能实现真正有效的安全防护。
kim

发表了文章

  • 0个评论
  • 206次浏览
  • 2018-02-05 10:22

集群环境: sz-fc-cs-k8s-etcd-20-4  172.20.20.4sz-fc-cs-k8s-etcd-20-5  172.20.20.5sz-fc-cs-k8s-etcd-20-6  172.20.20. 阅读全文

集群环境:
  • sz-fc-cs-k8s-etcd-20-4  172.20.20.4
  • sz-fc-cs-k8s-etcd-20-5  172.20.20.5
  • sz-fc-cs-k8s-etcd-20-6  172.20.20.6

 
1.创建 CA 证书和秘钥


本文档使用 CloudFlare 的 PKI 工具集 cfssl 来生成 Certificate Authority (CA) 证书和秘钥文件,CA 是自签名的证书,用来签名后续创建的其它 TLS 证书。


 
1)安装cfssl
$ wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -P /opt/
$ chmod +x /opt/cfssl_linux-amd64
$ mv /opt/cfssl_linux-amd64 /usr/local/bin/cfssl

$ wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -P /opt/
$ chmod +x /opt/cfssljson_linux-amd64
$ mv /opt/cfssljson_linux-amd64 /usr/local/bin/cfssljson

$ wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -P /opt/
$ chmod +x /opt/cfssl-certinfo_linux-amd64
$ mv /opt/cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo

$ export PATH=/usr/local/bin:$PATH

2)生成ETCD的TLS 秘钥和证书


为了保证通信安全,客户端(如 etcdctl) 与 etcd 集群、etcd 集群之间的通信需要使用 TLS 加密,本节创建 etcd TLS 加密所需的证书和私钥。


 
3)创建 CA 配置文件:
$ mkdir /opt/ssl;cd /opt/ssl
$ cat >  ca-config.json <<EOF
{
"signing": {
"default": {
"expiry": "8760h"
},
"profiles": {
"kubernetes": {
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
],
"expiry": "8760h"
}
}
}
}
EOF

  • ca-config.json:可以定义多个 profiles,分别指定不同的过期时间、使用场景等参数;后续在签名证书时使用某个 profile;
  • signing:表示该证书可用于签名其它证书;生成的 ca.pem 证书中 CA=TRUE;
  • server auth:表示 client 可以用该 CA 对 server 提供的证书进行验证;
  • client auth:表示 server 可以用该 CA 对 client 提供的证书进行验证;

 
4)创建 CA 证书签名请求:
$ cat >  ca-csr.json <<EOF
{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "Shenzhen",
"L": "Shenzhen",
"O": "k8s",
"OU": "System"
}
]
}
EOF

  • "CN":Common Name,kube-apiserver 从证书中提取该字段作为请求的用户名 (User Name);浏览器使用该字段验证网站是否合法;
  • "O":Organization,kube-apiserver 从证书中提取该字段作为请求用户所属的组 (Group);

 
5)生成 CA 证书和私钥:
$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca
6)创建 etcd 证书签名请求:
$ cat > etcd-csr.json <<EOF
{
    "CN": "etcd",
    "hosts": [
    "127.0.0.1",
    "172.20.20.4",
    "172.20.20.5",
    "172.20.20.6"
     ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "ST": "Shenzhen",
            "L": "Shenzhen",
            "O": "k8s",
            "OU": "System"
        }
    ]
}
EOF

  • hosts 字段指定授权使用该证书的 etcd 节点 IP;

 
7)生成 etcd 证书和私钥:
$ cfssl gencert -ca=ca.pem \
-ca-key=ca-key.pem \
-config=ca-config.json \
-profile=kubernetes etcd-csr.json | cfssljson -bare etcd


将生成好的etcd.pem和etcd-key.pem以及ca.pem三个文件拷贝到目标主机的etc/kubernetes/ssl目录下。


$ mkdir -p /etc/kubernetes/ssl/
$ ssh 172.20.20.5 "mkdir -p /etc/kubernetes/ssl/"
$ ssh 172.20.20.6 "mkdir -p /etc/kubernetes/ssl/"


# 拷贝到etcd服务器
$ cp -f /opt/ssl/ca.pem /etc/kubernetes/ssl/
$ cp -f /opt/ssl/etcd*.pem /etc/kubernetes/ssl/
$ scp -r /opt/ssl/ca.pem 172.20.20.5:/etc/kubernetes/ssl/
$ scp -r /opt/ssl/etcd*.pem 172.20.20.5:/etc/kubernetes/ssl/
$ scp -r /opt/ssl/ca.pem 172.20.20.6:/etc/kubernetes/ssl/
$ scp -r /opt/ssl/etcd*.pem 172.20.20.6:/etc/kubernetes/ssl/

 
2.etcd安装
 
1)下载二进制文件
$ wget https://github.com/coreos/etcd/releases/download/v3.2.15/etcd-v3.2.15-linux-amd64.tar.gz -P /opt/
$ cd /opt
$ tar xf etcd-v3.2.15-linux-amd64.tar.gz
$ mv etcd-v3.2.15-linux-amd64/etcd* /usr/local/bin/

2)创建 etcd 的 systemd unit 文件
$ mkdir -p /var/lib/etcd  # 必须先创建工作目录
#etcd-1
$ cat >/lib/systemd/system/etcd.service  <<'HERE'
[Unit]
Description=Etcd Server
After=network.target
After=network-online.target
Wants=network-online.target
Documentation=https://github.com/coreos
[Service]
Type=notify
WorkingDirectory=/var/lib/etcd/
EnvironmentFile=-/etc/etcd/etcd.conf
ExecStart=/usr/local/bin/etcd \
--name=sz-fc-cs-k8s-etcd-20-4 \
--cert-file=/etc/kubernetes/ssl/etcd.pem \
--key-file=/etc/kubernetes/ssl/etcd-key.pem \
--peer-cert-file=/etc/kubernetes/ssl/etcd.pem \
--peer-key-file=/etc/kubernetes/ssl/etcd-key.pem \
--trusted-ca-file=/etc/kubernetes/ssl/ca.pem \
--peer-trusted-ca-file=/etc/kubernetes/ssl/ca.pem \
--initial-advertise-peer-urls=https://172.20.20.4:2380 \
--listen-peer-urls=https://172.20.20.4:2380 \
--listen-client-urls=https://172.20.20.4:2379,http://127.0.0.1:2379 \
--advertise-client-urls=https://172.20.20.4:2379 \
--initial-cluster-token=etcd-cluster-0 \
--initial-cluster=sz-fc-cs-k8s-etcd-20-4=https://172.20.20.4:2380,sz-fc-cs-k8s-etcd-20-5=https://172.20.20.5:2380,sz-fc-cs-k8s-etcd-20-6=https://172.20.20.6:2380 \
--initial-cluster-state=new \
--data-dir=/var/lib/etcd
Restart=on-failure
RestartSec=5
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
HERE




#etcd-2
$ cat >/lib/systemd/system/etcd.service <<'HERE'
[Unit]
Description=Etcd Server
After=network.target
After=network-online.target
Wants=network-online.target
Documentation=https://github.com/coreos
[Service]
Type=notify
WorkingDirectory=/var/lib/etcd/
EnvironmentFile=-/etc/etcd/etcd.conf
ExecStart=/usr/local/bin/etcd \
--name=sz-fc-cs-k8s-etcd-20-5 \
--cert-file=/etc/kubernetes/ssl/etcd.pem \
--key-file=/etc/kubernetes/ssl/etcd-key.pem \
--peer-cert-file=/etc/kubernetes/ssl/etcd.pem \
--peer-key-file=/etc/kubernetes/ssl/etcd-key.pem \
--trusted-ca-file=/etc/kubernetes/ssl/ca.pem \
--peer-trusted-ca-file=/etc/kubernetes/ssl/ca.pem \
--initial-advertise-peer-urls=https://172.20.20.5:2380 \
--listen-peer-urls=https://172.20.20.5:2380 \
--listen-client-urls=https://172.20.20.5:2379,http://127.0.0.1:2379 \
--advertise-client-urls=https://172.20.20.5:2379 \
--initial-cluster-token=etcd-cluster-0 \
--initial-cluster=sz-fc-cs-k8s-etcd-20-4=https://172.20.20.4:2380,sz-fc-cs-k8s-etcd-20-5=https://172.20.20.5:2380,sz-fc-cs-k8s-etcd-20-6=https://172.20.20.6:2380 \
--initial-cluster-state=new \
--data-dir=/var/lib/etcd
Restart=on-failure
RestartSec=5
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
HERE
#etcd-3
$ cat >/lib/systemd/system/etcd.service <<'HERE'
[Unit]
Description=Etcd Server
After=network.target
After=network-online.target
Wants=network-online.target
Documentation=https://github.com/coreos
[Service]
Type=notify
WorkingDirectory=/var/lib/etcd/
EnvironmentFile=-/etc/etcd/etcd.conf
ExecStart=/usr/local/bin/etcd \
--name=sz-fc-cs-k8s-etcd-20-6 \
--cert-file=/etc/kubernetes/ssl/etcd.pem \
--key-file=/etc/kubernetes/ssl/etcd-key.pem \
--peer-cert-file=/etc/kubernetes/ssl/etcd.pem \
--peer-key-file=/etc/kubernetes/ssl/etcd-key.pem \
--trusted-ca-file=/etc/kubernetes/ssl/ca.pem \
--peer-trusted-ca-file=/etc/kubernetes/ssl/ca.pem \
--initial-advertise-peer-urls=https://172.20.20.6:2380 \
--listen-peer-urls=https://172.20.20.6:2380 \
--listen-client-urls=https://172.20.20.6:2379,http://127.0.0.1:2379 \
--advertise-client-urls=https://172.20.20.6:2379 \
--initial-cluster-token=etcd-cluster-0 \
--initial-cluster=sz-fc-cs-k8s-etcd-20-4=https://172.20.20.4:2380,sz-fc-cs-k8s-etcd-20-5=https://172.20.20.5:2380,sz-fc-cs-k8s-etcd-20-6=https://172.20.20.6:2380 \
--initial-cluster-state=new \
--data-dir=/var/lib/etcd
Restart=on-failure
RestartSec=5
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
HERE
 
  • 指定 etcd 的工作目录和数据目录为 /var/lib/etcd,需在启动服务前创建这个目录;
  • 为了保证通信安全,需要指定 etcd 的公私钥(cert-file和key-file)、Peers 通信的公私钥和 CA 证书(peer-cert-file、peer-key-file、peer-trusted-ca-file)、客户端的CA证书(trusted-ca-file);
  • --initial-cluster-state 值为 new 时,--name 的参数值必须位于 --initial-cluster 列表中;

 

4)启动etcd
$ systemctl daemon-reload && systemctl start etcd && systemctl enable etcd
5)验证
#部署完 etcd 集群后,在任一 etcd 集群节点上执行如下命令:
#检查集群健康
$ etcdctl --endpoints=https://172.20.20.4:2379,https://172.20.20.5:2379,https://172.20.20.6:2379 \
--ca-file=/etc/kubernetes/ssl/ca.pem \
--cert-file=/etc/kubernetes/ssl/etcd.pem \
--key-file=/etc/kubernetes/ssl/etcd-key.pem \
cluster-health
#查看 etcd 集群成员
$ etcdctl --endpoints=https://172.20.20.4:2379,https://172.20.20.5:2379,https://172.20.20.6:2379 \
--ca-file=/etc/kubernetes/ssl/ca.pem \
--cert-file=/etc/kubernetes/ssl/etcd.pem \
--key-file=/etc/kubernetes/ssl/etcd-key.pem \
#设置集群网络范围
$ etcdctl --endpoints=https://172.20.20.4:2379,https://172.20.20.5:2379,https://172.20.20.6:2379 \
--ca-file=/etc/kubernetes/ssl/ca.pem \
--cert-file=/etc/kubernetes/ssl/etcd.pem \
--key-file=/etc/kubernetes/ssl/etcd-key.pem \
mkdir /kubernetes/network
 
# 配置 flannel 网段
$ etcdctl --endpoints=https://172.20.20.4:2379,https://172.20.20.5:2379,https://172.20.20.6:2379 \
--ca-file=/etc/kubernetes/ssl/ca.pem \
--cert-file=/etc/kubernetes/ssl/etcd.pem \
--key-file=/etc/kubernetes/ssl/etcd-key.pem \
mk /kubernetes/network/config '{ "Network": "10.8.0.0/16", "Backend": { "Type": "vxlan", "VNI": 1 }}'
 
#查看网络设置
$ etcdctl --endpoints=https://172.20.20.4:2379,https://172.20.20.5:2379,https://172.20.20.6:2379 \
--ca-file=/etc/kubernetes/ssl/ca.pem \
--cert-file=/etc/kubernetes/ssl/etcd.pem \
--key-file=/etc/kubernetes/ssl/etcd-key.pem \
get /kubernetes/network/config

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
kim

发表了文章

  • 0个评论
  • 262次浏览
  • 2018-01-30 18:35

apiVersion: v1 #指定api版本,此值必须在kubectl apiversion中 kind: Pod #指定创建资源的角色/类型 metadata: #资源的元数据/属性 name: web04-po 阅读全文

apiVersion: v1 #指定api版本,此值必须在kubectl apiversion中
kind: Pod #指定创建资源的角色/类型
metadata: #资源的元数据/属性
name: web04-pod #资源的名字,在同一个namespace中必须唯一
labels: #设定资源的标签
k8s-app: apache
version: v1
kubernetes.io/cluster-service: "true"
annotations: #自定义注解列表
- name: String #自定义注解名字
spec:#specification of the resource content 指定该资源的内容
restartPolicy: Always #表明该容器一直运行,默认k8s的策略,在此容器退出后,会立即创建一个相同的容器
nodeSelector: #节点选择,先给主机打标签kubectl label nodes kube-node1 zone=node1
zone: node1
containers:
- name: web04-pod #容器的名字
image: web:apache #容器使用的镜像地址
imagePullPolicy: Never #[Always|Never|IfNotPresent]获取镜像的策略
command: ['sh'] #覆盖容器中的Entrypoint,对应Dockefile中的ENTRYPOINT
args: ["$(str)"] #对应Dockerfile中CMD参数
env: #指定容器中的环境变量
- name: str #变量的名字
value: "/etc/run.sh" #变量的值
resources: #资源管理
requests: #最小资源需求
cpu: 0.1 #设置可以使用CPU个数,两种方式,浮点数或者是整数+m,0.1=100m
memory: 32Mi #内存使用量
limits: #资源限制
cpu: 0.5
memory: 32Mi
ports:
- containerPort: 80
name: httpd
protocol: TCP
livenessProbe: #pod内容器健康检查的设置
httpGet: #通过httpget检查健康,返回200-399之间,则认为容器正常
path: / #URI地址
port: 80
#host: 127.0.0.1 #主机地址
scheme: HTTP
initialDelaySeconds: 180 #表明第一次检测在容器启动后多长时间后开始
timeoutSeconds: 5 #检测的超时时间
periodSeconds: 15 #检查间隔时间
#也可以用这种方法
#exec: 执行命令的方法进行监测,如果其退出码不为0,则认为容器正常
# command:
# - cat
# - /tmp/health
#也可以用这种方法
#tcpSocket: //通过tcpSocket检查健康
# port: number
lifecycle: #生命周期管理
postStart: #容器运行之前运行的任务
exec:
command:
- 'sh'
- 'yum upgrade -y'
preStop:#容器关闭之前运行的任务
exec:
command: ['service httpd stop']
volumeMounts:
- name: volume #挂载设备的名字,与volumes[*].name 需要对应
mountPath: /data #挂载到容器的某个路径下
readOnly: True
volumes: #定义一组挂载设备
- name: volume #定义一个挂载设备的名字
#meptyDir: {}
hostPath:
path: /opt #挂载设备类型为hostPath,路径为宿主机下的/opt,这里设备类型支持很多种
kim

发表了文章

  • 0个评论
  • 183次浏览
  • 2018-01-24 14:28
xiaopei

发起了问题

  • 0个回答
  • 178次浏览
  • 2018-01-24 10:29

nginx常用的超时配置说明: client_header_timeout 语法 client_header_timeout time 默认值 60s 上下文 http server 说明 指定等待client发送一个 阅读全文

nginx常用的超时配置说明:

client_header_timeout
语法 client_header_timeout time
默认值 60s
上下文 http server
说明 指定等待client发送一个请求头的超时时间(例如:GET / HTTP/1.1).仅当在一次read中,没有收到请求头,才会算成超时。如果在超时时间内,client没发送任何东西,nginx返回HTTP状态码408(“Request timed out”)

client_body_timeout 
语法 client_body_timeout time
默认值 60s
上下文 http server location
说明 该指令设置请求体(request body)的读超时时间。仅当在一次readstep中,没有得到请求体,就会设为超时。超时后,nginx返回HTTP状态码408(“Request timed out”)

keepalive_timeout 
语法 keepalive_timeout timeout [ header_timeout ]
默认值 75s
上下文 http server location
说明 第一个参数指定了与client的keep-alive连接超时时间。服务器将会在这个时间后关闭连接。可选的第二个参数指定了在响应头Keep-Alive: timeout=time中的time值。这个头能够让一些浏览器主动关闭连接,这样服务器就不必要去关闭连接了。没有这个参数,nginx不会发送Keep-Alive响应头(尽管并不是由这个头来决定连接是否“keep-alive”)两个参数的值可并不相同
  • 注意不同浏览器怎么处理“keep-alive”头
  • MSIE和Opera忽略掉"Keep-Alive: timeout=<N>" header.
  • MSIE保持连接大约60-65秒,然后发送TCP RST
  • Opera永久保持长连接
  • Mozilla keeps the connection alive for N plus about 1-10 seconds.
  • Konqueror保持长连接N秒
  •  

lingering_timeout
语法 lingering_timeout time
默认值 5s
上下文 http server location
说明 lingering_close生效后,在关闭连接前,会检测是否有用户发送的数据到达服务器,如果超过lingering_timeout时间后还没有数据可读,就直接关闭连接;否则,必须在读取完连接缓冲区上的数据并丢弃掉后才会关闭连接。

resolver_timeout
语法 resolver_timeout time 
默认值 30s
上下文 http server location
说明 该指令设置DNS解析超时时间

proxy_connect_timeout
语法 proxy_connect_timeout time 
默认值 60s
上下文 http server location
说明 该指令设置与upstream server的连接超时时间,有必要记住,这个超时不能超过75秒。
这个不是等待后端返回页面的时间,那是由proxy_read_timeout声明的。如果你的upstream服务器起来了,但是hanging住了(例如,没有足够的线程处理请求,所以把你的请求放到请求池里稍后处理),那么这个声明是没有用的,由于与upstream服务器的连接已经建立了。

proxy_read_timeout
语法 proxy_read_timeout time 
默认值 60s
上下文 http server location
说明 该指令设置与代理服务器的读超时时间。它决定了nginx会等待多长时间来获得请求的响应。这个时间不是获得整个response的时间,而是两次reading操作的时间。

proxy_send_timeout
语法 proxy_send_timeout time 
默认值 60s
上下文 http server location
说明 这个指定设置了发送请求给upstream服务器的超时时间。超时设置不是为了整个发送期间,而是在两次write操作期间。如果超时后,upstream没有收到新的数据,nginx会关闭连接

proxy_upstream_fail_timeout(fail_timeout)
语法 server address [fail_timeout=30s]
默认值 10s
上下文 upstream
说明 Upstream模块下 server指令的参数,设置了某一个upstream后端失败了指定次数(max_fails)后,该后端不可操作的时间,默认为10秒
xiaopei

发表了文章

  • 0个评论
  • 222次浏览
  • 2017-12-05 11:04
kim

回复了问题

  • 1个回答
  • 244次浏览
  • 2017-11-13 10:04
test

回复了问题

  • 1个回答
  • 240次浏览
  • 2017-11-09 11:10

运维人员对公司互联网业务所依赖的基础设施、基础服务、线上业务进行稳定性加强,进行日常巡检发现服务可能存在的隐患,对整体架构进行优化以屏蔽常见的运行故障,多数据中接入提高业务的容灾能力,通过监控、日志分析等技术手段,及时发 阅读全文

运维人员对公司互联网业务所依赖的基础设施、基础服务、线上业务进行稳定性加强,进行日常巡检发现服务可能存在的隐患,对整体架构进行优化以屏蔽常见的运行故障,多数据中接入提高业务的容灾能力,通过监控、日志分析等技术手段,及时发现和响应服务故障,减少服务中断的时间,使公司的互联网业务符合预期的可用性要求,持续稳定地为用户提供服务。

1.jpg

 
运维工作分类
 
运维的工作方向比较多,随着业务规模的不断发展,越成熟的互联网公司,运维岗位会划分得越细。当前很多大型的互联网公司,在初创时期只有系统运维,随着 模、服务质量的 要求,也逐渐进行了工作细分。一般情况下运维团队的工作分类和职责如下。

2.jpg

 
系统运维
 
系统运维负责IDC、网络、CDN和基础服务的建设(LVS、NTP、DNS);负责资产管理,服务器选型、交付和维修。详细的工作职责如下:
 
IDC数据中心建设
 
收集业务需求,预估未来数据中心的发展规模,从骨干网的分布,数据中心建筑,以及Internet接入、网络攻击防御能力、扩容能力、空间预留、外接专线能力、现场服务支撑能力等方面评估选型数据中心。负责数据中心的建设、现场维护工作。
 
网络建设
 
设计及规划生产网络架构,这里面包括:数据中心网络架构、传输网架构、CDN网络架构等,以及网络调优等日常运维工作
 
LVS负载均衡和SNAT建设
 
LVS是整个站点架构中的流量入口,根据网络规模和业务需求,构建负载均衡集群;完成网络与业务服务器的衔接,提供高性能、高可用的负载调度能力,以及统一的网络层防攻击能力;SNAT集中提供数据中心的公网访问服务,通过集群化部署,保证出网服务的高性能与高可用。
 
CDN规划和建设
 
 
CDN工作划分为第三方和自建两部分。建立第三方CDN的选型和调度控制;根据业务发展趋势,规划CDN新节点建设布局;完善CDN业务及监控,保障CDN系统稳定、高效运行;分析业务加速频道的文件特性和数量,制定最优的加速策略和资源匹配;负责用户劫持等CDN日常故障排查工作。
 
服务器选型、交付和维护
 
负责服务器的测试选型,包含服务器整机、部件的基础性测试和业务测试,降低整机功率,提升机架部署密度等。结合对公司业务的了解,推广新硬件、新方案减少业务的服务器投入规模。负责服务器硬件故障的诊断定位,服务器硬件监控、健康检查工具的开发和维护。
 
OS、内核选型和OS相关维护工作
 
负责整体平台的OS选型、定制和内核优化,以及Patch的更新和内部版本发布;建立基础的YUM包管理和分发中心,提供常用包版本库;跟进日常各类OS相关故障;针对不同的业务类型,提供定向的优化支持。
 
资产管理
 
记录和管理运维相关的基础物理信息,包括数据中心、网络、机柜、服务器、ACL、IP等各种资源信息,制定有效的流程,确保信息的准确性;开放API接口,为自动化运维提供数据支持。
 
基础服务建设
 
 
业务对DNS、NTP、SYSLOG等基础服务的依赖非常高,需要设计高可用架构避免单点,提供稳定的基础服务。

应用运维

应用运维负责线上服务的变更、服务状态监控、服务容灾和数据备份等工作,对服务进行例行排查、故障应急处理等工作。详细的工作职责如下所述。

设计评审

在产品研发阶段,参与产品设计评审,从运维的角度提出评审意见,使服务满足运维准入的高可用要求。

服务管理

负责制定线上业务升级变更及回滚方案,并进行变更实施。掌握所负责的服务及服务间关联关系、服务依赖的各种资源。能够发现服务上的缺陷,及时通报并推进解决。制定服务稳定性指标及准入标准,同时不断完善和优化程序和系统的功能、效率,提高运行质量。完善监控内容,提高报警准确度。在线上服务出现故障时,第一时间响应,对已知线上故障能按流程进行通报并按预案执行,未知故障组织相关人员联合排障。

资源管理

对各服务的服务器资产进行管理,梳理服务器资源状况、数据中心分布情况、网络专线及带宽情况,能够合理使用服务器资源,根据不同服务的需求,分配不同配置的服务器,确保服务器资源的充分利用。

例行检查

制定服务例行排查点,并不断完善。根据制定的服务排查点,对服务进行定期检查。对排查过程中发现的问题,及时进行追查,排除可能存在的隐患。

预案管理

确定服务所需的各项监控、系统指标的阈值或临界点,以及出现该情况后的处理预案。建立和更新服务预案文档,并根据日常故障情况不断补充完善,提高预案完备性。能够制定和评审各类预案,周期性进行预案演练,确保预案的可执行性。

数据备份

制定数据备份策略,按规范进行数据备份工作。保证数据备份的可用性和完整性,定期开展数据恢复性测试。

数据库运维

数据库运维负责数据存储方案设计、数据库表设计、索引设计和SQL优化,对数据库进行变更、监控、备份、高可用设计等工作。详细的工作职责如下所述。

设计评审

在产品研发初始阶段,参与设计方案评审,从DBA的角度提出数据存储方案、库表设计方案、SQL开发标准、索引设计方案等,使服务满足数据库使用的高可用、高性能要求。

容量规划

掌握所负责服务的数据库的容量上限,清楚地了解当前瓶颈点,当服务还未到达容量上限时,及时进行优化、分拆或者扩容。

数据备份与灾备

制定数据备份与灾备策略,定期完成数据恢复性测试,保证数据备份的可用性和完整性。

数据库监控

完善数据库存活和性能监控,及时了解数据库运行状态及故障。

数据库安全

建设数据库账号体系,严格控制账号权限与开放范围,降低误操作和数据泄露的风险;加强离线备份数据的管理,降低数据泄露的风险。

数据库高可用和性能优化

对数据库单点风险和故障设计相应的切换方案,降低故障对数据库服务的影响;不断对数据库整体性能进行优化,包括新存储方案引进、硬件优化、文件系统优化、数据库优化、SQL优化等,在保障成本不增加或者少量增加的情况下,数据库可以支撑更多的业务请求。
 
自动化系统建设

设计开发数据库自动化运维系统,包括数据库部署、自动扩容、分库分表、权限管理、备份恢复、SQL审核和上线、故障切换等功能。

运维研发

运维研发负责通用的运维平台设计和研发工作,如:资产管理、监控系统、运维平台、数据权限管理系统等。提供各种API供运维或研发人员使用,封装更高层的自动化运维系统。详细的工作职责如下所述。

运维平台

记录和管理服务及其关联关系,协助运维人员自动化、流程化地完成日常运维操作,包括机器管理、重启、改名、初始化、域名管理、流量切换和故障预案实施等。

监控系统

负责监控系统的设计、开发工作,完成公司服务器和各种网络设备的资源指标、线上业务运行指标的收集、告警、存储、分析、展示和数据挖掘等工作,持续提高告警的及时性、准确性和智能性,促进公司服务器资源的合理化调配。

自动化部署系统

参与部署自动化系统的开发,负责自动化部署系统所需要的基础数据和信息,负责权限管理、API开发、Web端开发。结合云计算,研发和提供PaaS相关高可用平台,进一步提高服务的部署速度和用户体验,提升资源利用率。

运维安全

运维安全负责网络、系统和业务等方面的安全加固工作,进行常规的安全扫描、渗透测试,进行安全工具和系统研发以及安全事件应急处理。详细的工作职责如下所述。

安全制度建立

根据公司内部的具体流程,制定切实可行,且行之有效的安全制度。

安全培训

定期向员工提供具有针对性的安全培训和考核,在全公司内建立安全负责人制度。

风险评估

通过黑白盒测试和检查机制,定期产生对物理网络、服务器、业务应用、用户数据等方面的总体风险评估结果。

安全建设

根据风险评估结果,加固最薄弱的环节,包括设计安全防线、部署安全设备、及时更新补丁、防御病毒、源代码自动扫描和业务产品安全咨询等。为了降低可能泄露数据的价值,通过加密、匿名化、混淆数据,乃至定期删除等技术手段和流程来达到目的。

安全合规

为了满足例如支付牌照等合规性要求,安全团队承担着安全合规的对外接口人工作。

应急响应

建立安全报警系统,通过安全中心收集第三方发现的安全问题,组织各部门对已经发现的安全问题进行修复、影响面评估、事后安全原因追查。
 
运维工作发展过程

早期的运维团队在人员较少的情况下,主要是进行数据中心建设、基础网络建设、服务器采购和服务器安装交付工作。几乎很少涉及线上服务的变更、监控、管理等工作。这个时候的运维团队更多的属于基础建设的角色,提供一个简单、可用的网络环境和系统环境即可。

随着业务产品的逐渐成熟,对于服务质量方面就有了更高的要求。这个时候的运维团队还会承担一些服务器监控的工作,同时会负责LVS、Nginx等与业务逻辑无关的4/7层运维工作。这个时候服务变更更多的是逐台的手工操作,或者有一些简单批量脚本的出现。监控的焦点更多的在服务器状态和资源使用情况上,对服务应用状态的监控几乎很少,监控更多的使用各种开源系统如Nagios、Cacti等。

由于业务规模和复杂度的持续增加,运维团队会逐渐划分为应用运维和系统运维两大块。应用运维开始接手线上业务,逐步开展服务监控梳理、数据备份以及服务变更的工作。随着对服务的深入,应用运维工程师有能力开始对服务进行一些简单的优化。同时,为了应对每天大量的服务变更,我们也开始编写各类运维工具,针对某些特定的服务能够很方便的批量变更。随着业务规模的增大,基础设施由于容量规划不足或抵御风险能力较弱导致的故障也越来越多,迫使运维人员开始将更多的精力投入到多数据中心容灾、预案管理的方向上。

业务规模达到一定程度后,开源的监控系统在性能和功能方面,已经无法满足业务需求;大量的服务变更、复杂的服务关系,以前靠人工记录、工具变更的方式不管在效率还是准确性方面也都无法满足业务需求;在安全方面也出现了各种大大小小的事件,迫使我们投入更多的精力在安全防御上。逐渐的,运维团队形成之前提到的5个大的工作分类,每个分类都需要有专精的人才。这个时候系统运维更专注于基础设施的建设和运维,提供稳定、高效的网络环境,交付服务器等资源给应用运维工程师。应用运维更专注于服务运行状态和效率。数据库运维属于应用运维工作的细化,更专注于数据库领域的自动化、性能优化和安全防御。运维研发和运维安全提供各类平台、工具,进一步提升运维工程师的工作效率,使业务服务运行得更加稳定、高效和安全。

我们将运维发展过程划分为4个阶段,如图所示。

3.jpg

 
手工管理阶段

业务流量不大,服务器数量相对较少,系统复杂度不高。对于日常的业务管理操作,大家更多的是逐台登录服务器进行手工操作,属于各自为战,每个人都有自己的操作方式,缺少必要的操作标准、流程机制,比如业务目录环境都是各式各样的。

工具批量操作阶段

随着服务器规模、系统复杂度的增加,全人工的操作方式已经不能满足业务的快速发展需要。因此,运维人员逐渐开始使用批量化的操作工具,针对不同操作类型出现了不同的脚本程序。但各团队都有自己的工具,每次操作需求发生变化时都需要调整工具。这主要是因为对于环境、操作的规范不够,导致可程序化处理能力较弱。此时,虽然效率提升了一部分,但很快又遇到了瓶颈。操作的质量并没有太多的提升,甚至可能因为批量执行而导致更大规模的问题出现。我们开始建立大量的流程规范,比如复查机制,先上线一台服务器观察10分钟后再继续后面的操作,一次升级完成后至少要观察20分钟等。这些主要还是靠人来监督和执行,但在实际过程中执行往往不到位,反而降低了工作效率。

平台管理阶段

在这个阶段,对于运维效率和误操作率有了更高的要求,我们决定开始建设运维平台,通过平台承载标准、流程,进而解放人力和提高质量。这个时候对服务的变更动作进行了抽象,形成了操作方法、服务目录环境、服务运行方式等统一的标准,如程序的启停接口必须包括启动、停止、重载等。通过平台来约束操作流程,如上面提到的上线一台服务器观察10分钟。在平台中强制设定暂停检查点,在第一台服务器操作完成后,需要运维人员填写相应的检查项,然后才可以继续执行后续的部署动作。

系统自调度阶段

更大规模的服务数量、更复杂的服务关联关系、各个运维平台的林立,原有的将批量操作转化成平台操作的方式已经不再适合,需要对服务变更进行更高一层的抽象。将每一台服务器抽象成一个容器,由调度系统根据资源使用情况,将服务调度、部署到合适的服务器上,自动化完成与周边各个运维系统的联动,比如监控系统、日志系统、备份系统等。通过自调度系统,根据服务运行情况动态伸缩容量,能够自动化处理常见的服务故障。运维人员的工作也会前置到产品设计阶段,协助研发人员改造服务使其可以接入到自调度系统中。

在整个运维的发展过程中,希望所有的工作都自动化起来,减少人的重复工作,降低知识传递的成本,使我们的运维交付更高效、更安全,使产品运行更稳定。对于故障的处理,也希望由事后处理变成提前发现,由人工处理变成系统自动容灾。
 

原文链接:http://os.51cto.com/art/201711/556212.htm
test

发表了文章

  • 0个评论
  • 275次浏览
  • 2017-11-08 15:12
xiaopei

发起了问题

  • 0个回答
  • 224次浏览
  • 2017-11-03 17:19
xiaopei

发起了问题

  • 0个回答
  • 217次浏览
  • 2017-10-31 23:16

1. yum安装 # rdhat 5的epel源$ rpm -ivh http://mirrors.sohu.com/fedora-epel/5/x86_64/epel-release-5-4.noarch.rpm 阅读全文


1. yum安装
# rdhat 5的epel源
$  rpm -ivh  http://mirrors.sohu.com/fedora-epel/5/x86_64/epel-release-5-4.noarch.rpm

# rhat 6的epel源
$  rpm -ivh  http://mirrors.sohu.com/fedora-epel/6/x86_64/epel-release-6-8.noarch.rpm

# rhat 7的epel源
$  rpm -ivh  http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

 yum安装,查看repo库里各个版本软件包yum list|grep ansible ,然后可以安装指定的版本,如 : yum -y install ansible1.9.noarch
$  yum -y install ansible  

注:如果远程主机上开启了SELinux,则需要安装libselinux-python,否则Ansible中的copy/file/template模块不能正常使用
$ yum -y install libselinux-python 

 
kim

发表了文章

  • 0个评论
  • 214次浏览
  • 2017-10-27 17:26
kim

回复了问题

  • 1个回答
  • 224次浏览
  • 2017-10-26 11:47