Archive for the ‘Linux’ category

K8s核心概念

August 29th, 2021

Pod

  • Pod是K8s中最小的单元
  • 一组容器的集合
  • 共享网络【一个Pod中的所有容器共享同一网络】
  • 生命周期是短暂的(服务器重启后,就找不到了)

Volume

  • 声明在Pod容器中可访问的文件目录
  • 可以被挂载到Pod中一个或多个容器指定路径下
  • 支持多种后端存储抽象【本地存储、分布式存储、云存储】

Controller

  • 确保预期的pod副本数量【ReplicaSet】
  • 无状态应用部署【Deployment】
    • 无状态就是指,不需要依赖于网络或者ip
  • 有状态应用部署【StatefulSet】
    • 有状态需要特定的条件
  • 确保所有的node运行同一个pod 【DaemonSet】
  • 一次性任务和定时任务【Job和CronJob】

Deployment

  • 定义一组Pod副本数目,版本等
  • 通过控制器【Controller】维持Pod数目【自动回复失败的Pod】
  • 通过控制器以指定的策略控制版本【滚动升级、回滚等】

Service

  • 定义一组pod的访问规则
  • Pod的负载均衡,提供一个或多个Pod的稳定访问地址
  • 支持多种方式【ClusterIP、NodePort、LoadBalancer】

Label

label:标签,用于对象资源查询,筛选

Namespace

命名空间,逻辑隔离

  • 一个集群内部的逻辑隔离机制【鉴权、资源】
  • 每个资源都属于一个namespace
  • 同一个namespace所有资源不能重复
  • 不同namespace可以资源名重复

API

我们通过Kubernetes的API来操作整个集群

同时我们可以通过 kubectl 、ui、curl 最终发送 http + json/yaml 方式的请求给API Server,然后控制整个K8S集群,K8S中所有的资源对象都可以采用 yaml 或 json 格式的文件定义或描述

如下:使用yaml部署一个nginx的pod

完整流程

  • 通过Kubectl提交一个创建RC(Replication Controller)的请求,该请求通过APlserver写入etcd
  • 此时Controller Manager通过API Server的监听资源变化的接口监听到此RC事件
  • 分析之后,发现当前集群中还没有它所对应的Pod实例
  • 于是根据RC里的Pod模板定义一个生成Pod对象,通过APIServer写入etcd
  • 此事件被Scheduler发现,它立即执行执行一个复杂的调度流程,为这个新的Pod选定一个落户的Node,然后通过API Server讲这一结果写入etcd中
  • 目标Node上运行的Kubelet进程通过APiserver监测到这个”新生的Pod.并按照它的定义,启动该Pod并任劳任怨地负责它的下半生,直到Pod的生命结束
  • 随后,我们通过Kubectl提交一个新的映射到该Pod的Service的创建请求
  • ControllerManager通过Label标签查询到关联的Pod实例,然后生成Service的Endpoints信息,并通过APIServer写入到etod中,
  • 接下来,所有Node上运行的Proxy进程通过APIServer查询并监听Service对象与其对应的Endponts信息,建立一个软件方式的负载均衡器来实现Service访问到后端Pod的流量转发功能

 

 

理解 Linux backlog/somaxconn 内核参数

November 21st, 2019

引言

之前线上TcpExt.ListenOverflows,然后通过ss -tlnp 查看Send-Q偏小导致后端服务器 Socket accept 队列满,系统的 somaxconn 内核参数默认太小。

TCP SYN_REVD, ESTABELLISHED 状态对应的队列

TCP 建立连接时要经过 3 次握手,在客户端向服务器发起连接时,
对于服务器而言,一个完整的连接建立过程,服务器会经历 2 种 TCP 状态:SYN_REVD, ESTABELLISHED。

对应也会维护两个队列:
1. 一个存放 SYN 的队列(半连接队列)
2. 一个存放已经完成连接的队列(全连接队列)

当一个连接的状态是 SYN RECEIVED 时,它会被放在 SYN 队列中。
当它的状态变为 ESTABLISHED 时,它会被转移到另一个队列。
所以后端的应用程序只从已完成的连接的队列中获取请求。

如果一个服务器要处理大量网络连接,且并发性比较高,那么这两个队列长度就非常重要了。
因为,即使服务器的硬件配置非常高,服务器端程序性能很好,
但是这两个队列非常小,那么经常会出现客户端连接不上的现象,
因为这两个队列一旦满了后,很容易丢包,或者连接被复位。
所以,如果服务器并发访问量非常高,那么这两个队列的设置就非常重要了。

Linux backlog 参数意义

对于 Linux 而言,基本上任意语言实现的通信框架或服务器程序在构造 socket server 时,都提供了 backlog 这个参数,
因为在监听端口时,都会调用系统底层 API: int listen(int sockfd, int backlog);

listen 函数中 backlog 参数的定义如下:

Now it specifies the queue length for completely established sockets waiting to be accepted,
instead of the number of incomplete connection requests.
The maximum length of the queue for incomplete sockets can be set using the tcp_max_syn_backlog sysctl.
When syncookies are enabled there is no logical maximum length and this sysctl setting is ignored.
If the socket is of type AF_INET, and the backlog argument is greater than the constant SOMAXCONN(128 default),
it is silently truncated to SOMAXCONN.

backlog 参数描述的是服务器端 TCP ESTABELLISHED 状态对应的全连接队列长度。

全连接队列长度如何计算?
如果 backlog 大于内核参数 net.core.somaxconn,则以 net.core.somaxconn 为准,
即全连接队列长度 = min(backlog, 内核参数 net.core.somaxconn),net.core.somaxconn 默认为 128。
这个很好理解,net.core.somaxconn 定义了系统级别的全连接队列最大长度,
backlog 只是应用层传入的参数,不可能超过内核参数,所以 backlog 必须小于等于 net.core.somaxconn。

半连接队列长度如何计算?
半连接队列长度由内核参数 tcp_max_syn_backlog 决定,
当使用 SYN Cookie 时(就是内核参数 net.ipv4.tcp_syncookies = 1),这个参数无效,
半连接队列的最大长度为 backlog、内核参数 net.core.somaxconn、内核参数 tcp_max_syn_backlog 的最小值。
即半连接队列长度 = min(backlog, 内核参数 net.core.somaxconn,内核参数 tcp_max_syn_backlog)。
这个公式实际上规定半连接队列长度不能超过全连接队列长度。

其实,对于 Nginx/Tomcat 等这种 Web 服务器,都提供了 backlog 参数设置入口,
当然它们都会有默认值,通常这个默认值都不会太大(包括内核默认的半连接队列和全连接队列长度)。
如果应用并发访问非常高,只增大应用层 backlog 是没有意义的,因为可能内核参数关于连接队列设置的都很小,
一定要综合应用层 backlog 和内核参数一起看,通过公式很容易调整出正确的设置。

 

docker 常用操作

November 4th, 2019

sudo docker ps

sudo docker images

sudo docker run –name mysql -p 3306:3306 -v ~/mysql/data:/var/lib/mysql -e MYSQL_DATABASE=spider -e MYSQL_USER=admin -e MYSQL_PASSWORD=admin -e MYSQL_ROOT_PASSWORD=admin -d mysql

sudo docker run –name redis -p 6379:6379 -d redis

sudo docker run –name mongo -p 27017:27017 -v ~/mongo/db:/data/db -e MONGO_INITDB_ROOT_USERNAME=admin -e MONGO_INITDB_ROOT_PASSWORD=admin -d mongo

sudo docker exec -it mysql bash

sudo docker exec -it redis bash

 

docker run -it –name openjdk -d lzz5235/openjdk-8u202 /bin/bash 这样可以保证容器不被杀死

docker exec -it [name] /bin/bash 进入终端

 

 

 

Docker 编排工具简述

March 28th, 2017

编排是一个新的词汇,经过阅读才明白编排指的是容器的集群化和调度。另一类含义指的是容器管理,负责管理容器化应用和组件任务。

典型的编排工具有:Docker swarm mode、Kuberbetes和Mesosphere DCOS,这三个工具都提供相同的特性,但同时三个工具所处于的地位又不尽相同。

  1. 这些工具在容器集群中提供或者调度容器,还可以启动容器。会根据需求,例如资源和部署位置,在最佳VM中启动容器。

       2. 脚本保证你把指定的配置加载到容器中。

       3. 容器管理工具跟踪和监控容器的健康,将容器维持在集群中。正常情况下,监视工具会在容器崩溃时启动一个新实例。如果服务器故障,工具会在另一台服务器上重启容器。这些工具还会运行系统健康检查、报告容器不规律行为以及VM或服务器的不正常情况。

       4.需要部署新版本的容器或者升级容器中应用时,容器管理工具自动在集群中更新你的容器或应用。如果出现问题,它们允许你回滚到正确配置的版本。

       5.容器使用服务发现来找到它们的资源。

       6.你希望容器运行在哪里?你希望每个容器分配多少CPU?所有这些需求都可以通过设置正确的容器部署策略实现。

        7.容器要能够和已有的IT管理工具兼容。

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

Docker Swarm mode 和 Docker Swarm 

这是两款独立的编排工具,Docker Swarm是一种较旧的独立产品,曾经用于管理Docker集群。而Swarm mode是Docker内置的集群管理器。Docker 1.12后,Swarm mode引入Docker ,成为Docker Engine的一部分。

Docker swarm mode 支持滚动更新、节点间传输层安全加密、负载均衡和简单的服务抽象。可以在多个主机之间传播容器负载,它允许你在多个主机平台上设置swarm(即群集)。

Kubernetes

Kubernetes最初由有谷歌开发的开源容器管理工具。这个工具提供高度的互操作性,以及自我修复、自动升级回滚以及存储编排。目前负载均衡做的还不是很好,但是我们仍然需要在Kubernets基础上加入监控日志系统。

Marathon

Marathon是为Mesosphere DC/OS和Apache Mesos设计的容器编排平台。Marathon有很多特性,包括高可用、服务发现、负载均衡。

综上所述Mesos和Kubernetes主要用于运行集群应用程序。Mesos专注于通用调度,以插件的方式提供多个不同的调度器。而Kubernetes者用来构建容器的分布式环境。对于可以结合三个工具的优缺点,来构建容器云达到更好的管理效果。

 

https://docs.docker.com/engine/swarm/

https://kubernetes.io/

https://github.com/mesosphere/marathon

docker 初体验

February 21st, 2017

Docker话说已经活了好几年了,业界开始逐步从热议到逐步落地使用,之前硕士搞过一年的LXC,虽然Docker这个技术新瓶装旧酒,但是由于加入了特有的hub机制,使其易于传播,易用性比LXC更具优势。

今天抽空使用了一下docker,准备将自己的 VPS 容器化,方便以后在不同主机中迁移。

Docker由三部分组成:一个运行docker命令的client, 一个包含images并以容器(container)形式运行image的主机,一个docker的images仓库。client与docker host上面的docker daemon通信。当然docker client和host可以运行于一台机器(我们做实验的时候是一台),默认的docker仓库是Docker Hub。

docker使用流程就是client pull 从hub上把image拉到docker host,然后通过run命令指挥image到host上面弄一个container来跑这个image。

或者就是client 通过build命令在host上面创建一个自己的image,然后通过push命令把image推到仓库。然后别人就可以使用自己构建的镜像。

刚开始使用对image容易搞混乱,按照我的理解:image就是一个文件系统镜像,用户无法直接修改这个镜像,类似于一种二进制文件形式(其实是一种特殊的文件系统)里面运行时所需的程序、库、资源、配置等文件外,还包含了一些为运行时准备的一些配置参数(如匿名卷、环境变量、用户等)。

我们使用docker run就可以将这个image运行起来,运行起来的image就是container。运行起来的container我们可以对其进行各种修改,每产生一个修改,就产生一个commition ID。后一个构建依赖前一个构建,因此和git版本管理很像!

image和container之间的关系类似程序与进程之间的关系!

Docker命令实例

  1. docker pull的格式是:
docker pull[选项] [Docker Registry地址] <仓库名>:<标签名>

2.docker images命令下载的images:

$docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu ml 14.04 b969ab9f929b 1 weeksago 210 MB

3.最最重要的就是docker run

$docker run -p 8080:80 -p 111:22 -i -t -name [docker-name] -d COMMAND

其中的-p指的是端口映射,-d 设置该容器以daemon模式运行,具体实例:

$ sudo docker run -i -t ubuntu:14.04 /bin/bash

docker run – 运行一个容器
-t – 分配一个(伪)tty (link is external)
-i – 交互模式 (so we can interact with it)
ubuntu:14.04 – 使用 ubuntu 基础镜像 14.04
/bin/bash – 运行命令 bash shell

4. docker start 其实就是docker run的缩写,创建好container之后就不用再输入很长的命令,而是由一个docker start代替。

$docker start [docker-name]

5. docker ps 可以显示出运行的所有容器

$ docker ps
CONTAINER ID       IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
e3a913872698       ubuntu:14.04       "bash"              11seconds ago      Up 10 seconds                           wizardly_elion
db1c25753e97       ubuntu:14.04       "bash"              21seconds ago      Up 21 seconds                           adoring_shannon

这几个命令在使用中使用频率最高。

Dockerfile是构建image的文件,类似于脚本命令。

# ubuntu 14.04 with vim and gcc
FROM ubuntu:14.04
MAINTAINER lzz<[email protected]>
RUN apt-get update && apt-getinstall –y vim gcc

其中FROM指定构建镜像的基础源镜像,如果本地没有指定的镜像,则会自动从 Docker 的公共库 pull 镜像下来。
FROM必须是 Dockerfile 中非注释行的第一个指令,即一个 Dockerfile 从FROM语句开始。FROM可以在一个 Dockerfile 中出现多次,如果有需求在一个 Dockerfile 中创建多个镜像。如果FROM语句没有指定镜像标签,则默认使用latest标签。
MAINTAINER <name> 指定创建镜像的用户

RUN 有两种使用方式
RUN “executable”, “param1”, “param2”
每条RUN指令将在当前镜像基础上执行指定命令,并提交为新的镜像,后续的RUN都在之前RUN提交后的镜像为基础,镜像是分层的,可以通过一个镜像的任何一个历史提交点来创建,类似源码的版本控制。

exec 方式会被解析为一个 JSON 数组,所以必须使用双引号而不是单引号。exec 方式不会调用一个命令 shell,所以也就不会继承相应的变量,如:

RUN [ “echo”, “$HOME” ]
这种方式是不会达到输出 HOME 变量的,正确的方式应该是这样的

RUN [ “sh”, “-c”, “echo”, “$HOME” ]
RUN产生的缓存在下一次构建的时候是不会失效的,会被重用,可以使用–no-cache选项,即docker build –no-cache,如此便不会缓存。

 

http://www.cnblogs.com/hustcat/p/3980244.html

http://blog.csdn.net/u011537073/article/details/52719363