我的站点

一个系统软件工程师的随手涂鸦

Date: 十二月 15, 2015

Kubernetes笔记(5)—— kubernetes layout

Capture

Node(也称之为minion)运行docker container,而master则负责调度管理这些container

Master运行下列服务:

  1. API Server—nearly all the components on the master and nodes accomplish their respective tasks by making API calls. These are handled by the API Server running on the master.
  2. Etcd—Etcd is a service whose job is to keep and replicate the current configuration and run state of the cluster. It is implemented as a lightweight distributed key-value store and was developed inside the CoreOS project.
  3. Scheduler and Controller Manager—These processes schedule containers (actually, pods—but more on them later) onto target nodes. They also make sure that the correct numbers of these things are running at all times.

Node运行下列进程:

  1. Kubelet—A special background process (daemon that runs on each node whose job is to respond to commands from the master to create, destroy, and monitor the containers on that host.
  2. Proxy—This is a simple network proxy that’s used to separate the IP address of a target container from the name of the service it provides.
  3. cAdvisor (optional)—http://bit.ly/1izYGLi[Container Advisor (cAdvisor)] is a special daemon that collects, aggregates, processes, and exports information about running containers. This information includes information about resource isolation, historical usage, and key network statistics.

 

 

Kubernetes笔记(4)—— application VS service

A service is a process that:
1. is designed to do a small number of things (often just one).
2. has no user interface and is invoked solely via some kind of API.
An application, on the other hand, is pretty much the opposite of that. It has a user interface (even if it’s just a command line) and often performs lots of different tasks. It can also expose an API, but that’s just bonus points.

个人理解,service一般专注做一件事,没有用户界面,并且通过APIapplication交互。而application会有用户界面,并且通常可以运行很多任务。举个例子,web browser就是application,而web server即为service

A Kubernetes cluster does not manage a fleet of applications. It manages a cluster of services.A service running in a container managed by Kubernetes is designed to do a very small number of discrete things.

If your services are small and of limited purpose, then they can more easily be scheduled and re-arranged as your load demands. Otherwise, the dependencies become too much to manage and either your scale or your stability suffers.

K8s即是用来管理service的。

 

《HTTP:The Definitive Guide》笔记(2)—— messages

HTTP messages are simple, line-oriented sequences of characters. Because they are plain text, not binary, they are easy for humans to read and write.

HTTP messages sent from web clients to web servers are called request messages. Messages from servers to clients are called response messages. There are no other kinds of HTTP messages. The formats of HTTP request and response messages are very similar.

HTTP messages consist of three parts:

Start line
The first line of the message is the start line, indicating what to do for a request or what happened for a response.

Header fields
Zero or more header fields follow the start line. Each header field consists of a name and a value, separated by a colon (:) for easy parsing. The headers end with a blank line. Adding a header field is as easy as adding another line.

Body
After the blank line is an optional message body containing any kind of data. Request bodies carry data to the web server; response bodies carry data back to the client. Unlike the start lines and headers, which are textual and structured, the body can contain arbitrary binary data (e.g., images, videos, audio tracks, software applications). Of course, the body can also contain text.

 

Capture

《HTTP:The Definitive Guide》笔记(1)—— URI和URL

The server resource name is called a uniform resource identifier, or URI. URIs are like the postal addresses of the Internet, uniquely identifying and locating information resources around the world. URIs come in two flavors, called URLs and URNs.

The uniform resource locator (URL) is the most common form of resource identifier, and URLs come in two flavors: absolute and relative.
Most URLs follow a standardized format of three main parts:
• The first part of the URL is called the scheme, and it describes the protocol used to access the resource. This is usually the HTTP protocol (http://).
• The second part gives the server Internet address (e.g., www.joes-hardware.com).
• The rest names a resource on the web server (e.g., /specials/saw-blade.gif).
Today, almost every URI is a URL.

The second flavor of URI is the uniform resource name, or URN. A URN serves as a unique name for a particular piece of content, independent of where the resource currently resides. These location-independent URNs allow resources to move from place to place. URNs also allow resources to be accessed by multiple network access protocols while maintaining the same name.

 

Capture

Powered by WordPress & Theme by Anders Norén