@@ -23,135 +23,144 @@ Services, Deployments, and Builds for delivering changes.
23
23
24
24
.PP
25
25
Concepts:
26
+ .IP
26
27
28
+ .IP
29
+ \(bu
27
30
.PP
28
- .RS
29
-
30
- .nf
31
31
Containers:
32
-
33
32
A definition of how to run one or more processes inside of a portable Linux
34
33
environment. Containers are started from an Image and are usually isolated
35
34
from other containers on the same machine.
36
-
35
+ .IP
36
+ \(bu
37
+ .PP
37
38
Image:
38
-
39
39
A layered Linux filesystem that contains application code, dependencies,
40
40
and any supporting operating system libraries. An image is identified by
41
41
a name that can be local to the current cluster or point to a remote Docker
42
42
registry (a storage server for images).
43
-
43
+ .IP
44
+ \(bu
45
+ .PP
44
46
Pods [pod]:
45
-
46
47
A set of one or more containers that are deployed onto a Node together and
47
48
share a unique IP and Volumes (persistent storage). Pods also define the
48
49
security and runtime policy for each container.
49
-
50
+ .IP
51
+ \(bu
52
+ .PP
50
53
Labels:
51
-
52
54
Labels are key value pairs that can be assigned to any resource in the
53
55
system for grouping and selection. Many resources use labels to identify
54
56
sets of other resources.
55
-
57
+ .IP
58
+ \(bu
59
+ .PP
56
60
Volumes:
57
-
58
61
Containers are not persistent by default \- on restart their contents are
59
62
cleared. Volumes are mounted filesystems available to Pods and their
60
63
containers which may be backed by a number of host\- local or network
61
64
attached storage endpoints. The simplest volume type is EmptyDir, which
62
65
is a temporary directory on a single machine. Administrators may also
63
66
allow you to request a Persistent Volume that is automatically attached
64
67
to your pods.
65
-
68
+ .IP
69
+ \(bu
70
+ .PP
66
71
Nodes [node]:
67
-
68
72
Machines set up in the cluster to run containers. Usually managed
69
73
by administrators and not by end users.
70
-
74
+ .IP
75
+ \(bu
76
+ .PP
71
77
Services [svc]:
72
-
73
78
A name representing a set of pods (or external servers) that are
74
79
accessed by other pods. The service gets an IP and a DNS name, and can be
75
80
exposed externally to the cluster via a port or a Route. It's also easy
76
81
to consume services from pods because an environment variable with the
77
82
name <SERVICE>\_ HOST is automatically injected into other pods.
78
-
83
+ .IP
84
+ \(bu
85
+ .PP
79
86
Routes [route]:
80
-
81
87
A route is an external DNS entry (either a top level domain or a
82
88
dynamically allocated name) that is created to point to a service so that
83
89
it can be accessed outside the cluster. The administrator may configure
84
90
one or more Routers to handle those routes, typically through an Apache
85
91
or HAProxy load balancer / proxy.
86
-
92
+ .IP
93
+ \(bu
94
+ .PP
87
95
Replication Controllers [rc]:
88
-
89
96
A replication controller maintains a specific number of pods based on a
90
97
template that match a set of labels. If pods are deleted (because the
91
98
node they run on is taken out of service) the controller creates a new
92
99
copy of that pod. A replication controller is most commonly used to
93
100
represent a single deployment of part of an application based on a
94
101
built image.
95
-
102
+ .IP
103
+ \(bu
104
+ .PP
96
105
Deployment Configuration [dc]:
97
-
98
106
Defines the template for a pod and manages deploying new images or
99
107
configuration changes whenever those change. A single deployment
100
108
configuration is usually analogous to a single micro\- service. Can support
101
109
many different deployment patterns, including full restart, customizable
102
110
rolling updates, and fully custom behaviors, as well as pre\- and post\-
103
111
hooks. Each deployment is represented as a replication controller.
104
-
112
+ .IP
113
+ \(bu
114
+ .PP
105
115
Build Configuration [bc]:
106
-
107
116
Contains a description of how to build source code and a base image into a
108
117
new image \- the primary method for delivering changes to your application.
109
118
Builds can be source based and use builder images for common languages like
110
119
Java, PHP, Ruby, or Python, or be Docker based and create builds from a
111
120
Dockerfile. Each build configuration has web\- hooks and can be triggered
112
121
automatically by changes to their base images.
113
-
122
+ .IP
123
+ \(bu
124
+ .PP
114
125
Builds [build]:
115
-
116
126
Builds create a new image from source code, other images, Dockerfiles, or
117
127
binary input. A build is run inside of a container and has the same
118
128
restrictions normal pods have. A build usually results in an image pushed
119
129
to a Docker registry, but you can also choose to run a post\- build test that
120
130
does not push an image.
121
-
131
+ .IP
132
+ \(bu
133
+ .PP
122
134
Image Streams and Image Stream Tags [is,istag]:
123
-
124
135
An image stream groups sets of related images under tags \- analogous to a
125
136
branch in a source code repository. Each image stream may have one or
126
137
more tags (the default tag is called "latest") and those tags may point
127
138
at external Docker registries, at other tags in the same stream, or be
128
139
controlled to directly point at known images. In addition, images can be
129
140
pushed to an image stream tag directly via the integrated Docker
130
141
registry.
131
-
142
+ .IP
143
+ \(bu
144
+ .PP
132
145
Secrets [secret]:
133
-
134
146
The secret resource can hold text or binary secrets for delivery into
135
147
your pods. By default, every container is given a single secret which
136
148
contains a token for accessing the API (with limited privileges) at
137
149
/var/run/secrets/kubernetes.io/serviceaccount. You can create new
138
150
secrets and mount them in your own pods, as well as reference secrets
139
151
from builds (for connecting to remote servers) or use them to import
140
152
remote images into an image stream.
141
-
153
+ .IP
154
+ \(bu
155
+ .PP
142
156
Projects [project]:
143
-
144
157
All of the above resources (except Nodes) exist inside of a project.
145
158
Projects have a list of members and their roles, like viewer, editor,
146
159
or admin, as well as a set of security controls on the running pods, and
147
160
limits on how many resources the project can use. The names of each
148
161
resource are unique within a project. Developers may request projects
149
162
be created, but administrators control the resources allocated to
150
163
projects.
151
-
152
- .fi
153
- .RE
154
-
155
164
.PP
156
165
For more, see
157
166
\[la ] https://docs.openshift.com\[ra ]
0 commit comments