nginx

关注公众号 前端开发博客 ，回复“ 加群 ” 加入我们一起学习，天天进步 文章来源：https://www.javadoop.com/post/https 本文聊聊 HTTPS 的一些东西，和大家扯扯 SSL 证书的整个工作流程。希望大家有一些基本的常识： https 使用了非对称加密和对称加密，为什么要使用对称和非对称加密？非对称加密的原理是什么？这种简单的问题默认读者已经了解了。 非对称加密涉及到一对公钥和私钥组合，它们是一一对应的关系，不存在一个私钥对应多个公钥这种情况。 CA 是 Certification Authority 的缩写，它代表世界上那些权威的证书颁发机构。 CA 需要做什么 我们在申请一个 https 证书的时候，要在市场上选择一家 CA 来给你签发证书，那么 CA 的工作是什么呢？ CA 要验证这个域名真的是你的：通常就是通过 DNS 记录或者就是你在指定 URI 下放置一个特殊文件，让 CA 可以在外网环境下访问到它。 CA 是一个非常关键的角色，因为它签出来的任何证书都是被信任的，所以这要求每个 CA 都不能胡来。 ❝ 试想一下，如果某个 CA 私自给某个黑客签发了 *.taobao.com 的证书，那么黑客就能利用这个证书实现中间人攻击了。 有没有发生过 CA 瞎搞的事情呢？有一个典型的案例就是赛门铁克，由于它签发了大量的不合规的证书，导致了

(1).实验环境 youxi1　　192.168.5.101　　负载均衡器 youxi2　　192.168.5.102　　主机1 youxi3　　192.168.5.103　　主机2 (2).Nginx负载均衡策略 　　nginx的负载均衡用于upstream模板定义的后端服务器列表中选取一台服务器接收用户的请求。一个基本的upstream模块如下： upstream [服务器组名称]{ 　　server [IP地址]:[端口号]; 　　server [IP地址]:[端口号]; 　　.... } 　　在upstream模块配置完成后，要让指定的访问反向代理到服务器列表，格式如下： location ~ .*$ { 　　index index.jsp index.html; 　　proxy_pass http://[服务器组名称]; } 　　扩展：nginx的location配置规则： http://outofmemory.cn/code-snippet/742/nginx-location-configuration-xiangxi-explain 　　这样就完成了最基本的负载均衡，但是这并不能满足实际需求。目前Nginx的upstream模块支持6种方式的负载均衡策略（算法）：轮询（默认方式）、weight（权重方式）、ip_hash（依据ip分配方式）、least_conn

原理 nginx 可以实现负载均衡，但 nginx 自身存在单点故障的问题，这时候最先想到的就是 keepalived，可以解决单点故障的问题 由于没有使用 lvs，所以这里 nginx 之间不存在负载均衡 同时，如果 keepalived 的 master 节点 nginx 服务宕了以后，如果 keepalived 还在运行，则用户就访问不到 nginx 服务了，所以需要添加监控脚本，当 nginx 宕机时，杀死本机的 keepalived 服务 这样，keepalived 的 master 就会切换，同时用户访问的 nginx 服务也会切换到原来的 backup 节点 测试节点 RIP VIP MASTER 192.168.132.136 192.168.132.200 SLAVE 192.168.132.140 192.168.132.200 配置nginx 安装 nginx 不是重点，这里就是用 yum 简单安装 yum -y install nginx systemctl start nginx 配置keepalived 安装 keepalived 使用 yum 安装即可 keepalived 配置如下： global_defs { notification_email { chen@test.com } notification_email_from chen@test

[ubuntu][deepin]系统增加自定义开机启动项 进行配置 cd /etc/init.d/ ls vim myScript nginx实例 #! /bin/ sh # chkconfig: 2345 55 25 # Description: Startup script for nginx webserver on Debian. Place in /etc/ init.d and # run ' update-rc.d -f nginx defaults ' , or use the appropriate command on your # distro. For CentOS /Redhat run: ' chkconfig --add nginx ' ### BEGIN INIT INFO # Provides: nginx # Required - Start: $all # Required - Stop: $all # Default -Start: 2 3 4 5 # Default -Stop: 0 1 6 # Short - Description: starts the nginx web server # Description: starts nginx using start-stop- daemon ### END INIT INFO #

pod是kubernetes的最小单元，自主式创建的pod删除就没有了，但是通过资源控制器创建的pod如果删除还会重建。pod控制器就是用于实现代替我们去管理pod的中间层，并帮我们确保每一个pod资源处于我们所定义或者所期望的目标状态，pod资源出现故障首先要重启容器，如果一直重启有问题的话会基于某种策略重新编排。自动适应期望pod数量 pod控制器类型简介： 　　1.ReplicaSet: 　　　　代用户创建指定数量的pod副本数量，确保pod副本数量符合用户期望的数量状态，如果少了多退少补，并且支持滚动式自动扩容和缩容机制。 　　　　ReplicaSet主要三个组件组成：　　 　　　　　　（1）用户期望的pod副本数量 　　 　　　　　　（2）标签选择器，判断哪个pod归自己管理 　　 　　　　　　（3）pod资源模板（当现存的pod数量不足，会根据pod资源模板进行新建帮助用户管理无状态的pod资源，精确反应用户定义的目标数量。不直接使用） 　　Deployment： （无状态，守护进程类，只关注群体不关注个体） 　　　　工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。（pod数量和node没有精确的配比，没有一对一的关系） 　　DaemonSet：（无状态，守护进程类，只关注群体不关注个体） 　　　

转载于网络 pod是kubernetes的最小单元，自主式创建的pod删除就没有了，但是通过资源控制器创建的pod如果删除还会重建。pod控制器就是用于实现代替我们去管理pod的中间层，并帮我们确保每一个pod资源处于我们所定义或者所期望的目标状态，pod资源出现故障首先要重启容器，如果一直重启有问题的话会基于某种策略重新编排。自动适应期望pod数量 pod控制器类型简介： 　　1.ReplicaSet: 　　　　代用户创建指定数量的pod副本数量，确保pod副本数量符合用户期望的数量状态，如果少了多退少补，并且支持滚动式自动扩容和缩容机制。 　　　　ReplicaSet主要三个组件组成：　　 　　　　　　（1）用户期望的pod副本数量 　　 　　　　　　（2）标签选择器，判断哪个pod归自己管理 　　 　　　　　　（3）pod资源模板（当现存的pod数量不足，会根据pod资源模板进行新建帮助用户管理无状态的pod资源，精确反应用户定义的目标数量。不直接使用） 　　Deployment： （无状态，守护进程类，只关注群体不关注个体） 　　　　工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。（pod数量和node没有精确的配比，没有一对一的关系） 　　DaemonSet：（无状态，守护进程类，只关注群体不关注个体）

什么是Pod Pod 是 kubernetes 中你可以创建和部署的最小也是最简的单位。 Pod 代表着集群中运行的进程。 Pod 中封装着应用的容器（有的情况下是好几个容器），存储、独立的网络 IP ，管理容器如何运行的策略选项。 Pod 代表着部署的一个单位： kubernetes 中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。 Docker 是 kubernetes 中最常用的容器运行时，但是 Pod 也支持其他容器运行时。 在 Kubernetes 集群中 Pod 有如下两种方式： 一个Pod中运行一个容器 。“每个 Pod 中一个容器”的模式是最常见的用法；在这种使用方式中，你可以把 Pod 想象成单个容器的封装， Kubernetes 管理的是 Pod 而不是直接管理容器。 在一个Pod中同时运行多个容器 。一个 Pod 也可以同时封装几个需要紧密耦合互相协作的容器，它们之间共享资源。这些在同一个 Pod 中的容器可以互相协作成为一个 service 单位——一个容器共享文件，另一个 “sidecar” 容器来更新这些文件。 Pod 将这些容器的存储资源作为一个实体来管理。 Pod 中共享的环境包括 Linux 的 namespace 、 cgroup 和其他可能的隔绝环境，这一点跟 Docker 容器一致。在 Pod 的环境中

[toc] Kubernetes之（八）Pod的生命周期 理解Pod Pod是kubernetes中你可以创建和部署的最⼩也是最简的单位。 ⼀个Pod代表着集群中运⾏的⼀个进程。 Pod中封装着应⽤的容器（有的情况下是好⼏个容器） ， 存储、 独⽴的⽹络IP， 管理容器如何运⾏的策略选项。 Pod代 表着部署的⼀个单位： kubernetes中应⽤的⼀个实例， 可能由⼀个或者多个容器组合在⼀起共享资源。 在Kubrenetes集群中Pod有如下两种使⽤⽅式： ⼀个Pod中运⾏⼀个容器。 “每个Pod中⼀个容器”的模式是最常⻅的⽤法； 在这种使⽤⽅式中， 你可以把Pod想象成是单个容器的封装， kuberentes管理的是Pod⽽不是直接管理容器。 在⼀个Pod中同时运⾏多个容器。 ⼀个Pod中也可以同时封装⼏个需要紧密耦合互相协作的容器， 它们之间共享资源。 这些在同⼀个Pod中的容器可以互相协作成为⼀个service单位——⼀个容器共享⽂件， 另⼀个“sidecar”容器来更新这些⽂件。 Pod将这些容器的存储资源作为⼀个实体来管理。 每个Pod都是应⽤的⼀个实例。 如果你想平⾏扩展应⽤的话（运⾏多个实例） ， 你应该运⾏多个Pod， 每个Pod都是⼀个应⽤实例。 在Kubernetes中， 这通常被称为replication。 Pod内如何管理多个容器

Pod 生命周期 Pod 的 status 定义在 PodStatus 对象中，其中有一个 phase 字段。它简单描述了 Pod 在其生命周期的阶段。熟悉Pod的各种状态对我们理解如何设置Pod的调度策略、重启策略是很有必要的。 下面是 phase 可能的值： 阶段 描述 Pending Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间，这可能需要花点时间。 Running 该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。 Succeeded Pod 中的所有容器都被成功终止，并且不会再重启。 Failed Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。 Unknown 因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。 Pod 状态 Pod 有一个 PodStatus 对象，其中包含一个 PodCondition 数组，代表 Condition 是否通过。 PodCondition 属性描述： 字段 描述 lastProbeTime 最后一次探测 Pod Condition 的时间戳。 lastTransitionTime 上次

这篇文章主要介绍了nginx优化的六点方法,有对nginx优化不太熟悉的同学可以参考下 一.优化Nginx并发量 [root@proxy ~]# ab -n 2000 -c 2000 http://192.168.4.5/ Benchmarking 192.168.4.5 (be patient) socket: Too many open files (24) //提示打开文件数量过多 修改Nginx配置文件，增加并发量 [root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf .. .. worker_processes 2; //与CPU核心数量一致 events { worker_connections 65535; //每个worker最大并发连接数 use epoll; } .. .. [root@proxy ~]# nginx -s reload 二.优化 Linux 内核参数（最大文件数量） [root@proxy ~]# ulimit -a //查看所有属性值 [root@proxy ~]# ulimit -Hn 100000 //设置硬限制（临时规则） [root@proxy ~]# ulimit -Sn 100000 //设置软限制（临时规则） [root@proxy ~]# vim /etc/security