1OC(1) June 2016 OC(1)
2
3
4
6 oc types - An introduction to concepts and types
7
8
9
11 oc types [OPTIONS]
12
13
14
16 Concepts and Types
17
18
19 Kubernetes and OpenShift help developers and operators build, test, and
20 deploy applications in a containerized cloud environment. Applications
21 may be composed of all of the components below, although most develop‐
22 ers will be concerned with Services, Deployments, and Builds for deliv‐
23 ering changes.
24
25
26 Concepts:
27
28 ·
29
30 Containers: A definition of how to run one or more processes inside of
31 a portable Linux environment. Containers are started from an Image and
32 are usually isolated from other containers on the same machine.
33
34 ·
35
36 Image: A layered Linux filesystem that contains application code,
37 dependencies, and any supporting operating system libraries. An image
38 is identified by a name that can be local to the current cluster or
39 point to a remote Docker registry (a storage server for images).
40
41 ·
42
43 Pods [pod]: A set of one or more containers that are deployed onto a
44 Node together and share a unique IP and Volumes (persistent storage).
45 Pods also define the security and runtime policy for each container.
46
47 ·
48
49 Labels: Labels are key value pairs that can be assigned to any resource
50 in the system for grouping and selection. Many resources use labels to
51 identify sets of other resources.
52
53 ·
54
55 Volumes: Containers are not persistent by default - on restart their
56 contents are cleared. Volumes are mounted filesystems available to Pods
57 and their containers which may be backed by a number of host-local or
58 network attached storage endpoints. The simplest volume type is Empty‐
59 Dir, which is a temporary directory on a single machine. Administrators
60 may also allow you to request a Persistent Volume that is automatically
61 attached to your pods.
62
63 ·
64
65 Nodes [node]: Machines set up in the cluster to run containers. Usually
66 managed by administrators and not by end users.
67
68 ·
69
70 Services [svc]: A name representing a set of pods (or external servers)
71 that are accessed by other pods. The service gets an IP and a DNS name,
72 and can be exposed externally to the cluster via a port or a Route.
73 It's also easy to consume services from pods because an environment
74 variable with the name <SERVICE>_HOST is automatically injected into
75 other pods.
76
77 ·
78
79 Routes [route]: A route is an external DNS entry (either a top level
80 domain or a dynamically allocated name) that is created to point to a
81 service so that it can be accessed outside the cluster. The administra‐
82 tor may configure one or more Routers to handle those routes, typically
83 through an Apache or HAProxy load balancer / proxy.
84
85 ·
86
87 Replication Controllers [rc]: A replication controller maintains a spe‐
88 cific number of pods based on a template that match a set of labels. If
89 pods are deleted (because the node they run on is taken out of service)
90 the controller creates a new copy of that pod. A replication controller
91 is most commonly used to represent a single deployment of part of an
92 application based on a built image.
93
94 ·
95
96 Deployment Configuration [dc]: Defines the template for a pod and man‐
97 ages deploying new images or configuration changes whenever those
98 change. A single deployment configuration is usually analogous to a
99 single micro-service. Can support many different deployment patterns,
100 including full restart, customizable rolling updates, and fully custom
101 behaviors, as well as pre- and post- hooks. Each deployment is repre‐
102 sented as a replication controller.
103
104 ·
105
106 Build Configuration [bc]: Contains a description of how to build source
107 code and a base image into a new image - the primary method for deliv‐
108 ering changes to your application. Builds can be source based and use
109 builder images for common languages like Java, PHP, Ruby, or Python, or
110 be Docker based and create builds from a Dockerfile. Each build config‐
111 uration has web-hooks and can be triggered automatically by changes to
112 their base images.
113
114 ·
115
116 Builds [build]: Builds create a new image from source code, other
117 images, Dockerfiles, or binary input. A build is run inside of a con‐
118 tainer and has the same restrictions normal pods have. A build usually
119 results in an image pushed to a Docker registry, but you can also
120 choose to run a post-build test that does not push an image.
121
122 ·
123
124 Image Streams and Image Stream Tags [is,istag]: An image stream groups
125 sets of related images under tags - analogous to a branch in a source
126 code repository. Each image stream may have one or more tags (the
127 default tag is called "latest") and those tags may point at external
128 Docker registries, at other tags in the same stream, or be controlled
129 to directly point at known images. In addition, images can be pushed to
130 an image stream tag directly via the integrated Docker registry.
131
132 ·
133
134 Secrets [secret]: The secret resource can hold text or binary secrets
135 for delivery into your pods. By default, every container is given a
136 single secret which contains a token for accessing the API (with lim‐
137 ited privileges) at /var/run/secrets/kubernetes.io/serviceaccount. You
138 can create new secrets and mount them in your own pods, as well as ref‐
139 erence secrets from builds (for connecting to remote servers) or use
140 them to import remote images into an image stream.
141
142 ·
143
144 Projects [project]: All of the above resources (except Nodes) exist
145 inside of a project. Projects have a list of members and their roles,
146 like viewer, editor, or admin, as well as a set of security controls on
147 the running pods, and limits on how many resources the project can use.
148 The names of each resource are unique within a project. Developers may
149 request projects be created, but administrators control the resources
150 allocated to projects.
151
152 For more, see ⟨https://docs.openshift.com⟩
153
154
155
157 --allow_verification_with_non_compliant_keys=false
158 Allow a SignatureVerifier to use keys which are technically
159 non-compliant with RFC6962.
160
161
162 --alsologtostderr=false
163 log to standard error as well as files
164
165
166 --application_metrics_count_limit=100
167 Max number of application metrics to store (per container)
168
169
170 --as=""
171 Username to impersonate for the operation
172
173
174 --as-group=[]
175 Group to impersonate for the operation, this flag can be repeated
176 to specify multiple groups.
177
178
179 --azure-container-registry-config=""
180 Path to the file containing Azure container registry configuration
181 information.
182
183
184 --boot_id_file="/proc/sys/kernel/random/boot_id"
185 Comma-separated list of files to check for boot-id. Use the first
186 one that exists.
187
188
189 --cache-dir="/builddir/.kube/http-cache"
190 Default HTTP cache directory
191
192
193 --certificate-authority=""
194 Path to a cert file for the certificate authority
195
196
197 --client-certificate=""
198 Path to a client certificate file for TLS
199
200
201 --client-key=""
202 Path to a client key file for TLS
203
204
205 --cloud-provider-gce-lb-src-cidrs=130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16
206 CIDRs opened in GCE firewall for LB traffic proxy health checks
207
208
209 --cluster=""
210 The name of the kubeconfig cluster to use
211
212
213 --container_hints="/etc/cadvisor/container_hints.json"
214 location of the container hints file
215
216
217 --containerd="unix:///var/run/containerd.sock"
218 containerd endpoint
219
220
221 --context=""
222 The name of the kubeconfig context to use
223
224
225 --default-not-ready-toleration-seconds=300
226 Indicates the tolerationSeconds of the toleration for
227 notReady:NoExecute that is added by default to every pod that does not
228 already have such a toleration.
229
230
231 --default-unreachable-toleration-seconds=300
232 Indicates the tolerationSeconds of the toleration for unreach‐
233 able:NoExecute that is added by default to every pod that does not
234 already have such a toleration.
235
236
237 --docker="unix:///var/run/docker.sock"
238 docker endpoint
239
240
241 --docker-tls=false
242 use TLS to connect to docker
243
244
245 --docker-tls-ca="ca.pem"
246 path to trusted CA
247
248
249 --docker-tls-cert="cert.pem"
250 path to client certificate
251
252
253 --docker-tls-key="key.pem"
254 path to private key
255
256
257 --docker_env_metadata_whitelist=""
258 a comma-separated list of environment variable keys that needs to
259 be collected for docker containers
260
261
262 --docker_only=false
263 Only report docker containers in addition to root stats
264
265
266 --docker_root="/var/lib/docker"
267 DEPRECATED: docker root is read from docker info (this is a fall‐
268 back, default: /var/lib/docker)
269
270
271 --enable_load_reader=false
272 Whether to enable cpu load reader
273
274
275 --event_storage_age_limit="default=24h"
276 Max length of time for which to store events (per type). Value is a
277 comma separated list of key values, where the keys are event types
278 (e.g.: creation, oom) or "default" and the value is a duration. Default
279 is applied to all non-specified event types
280
281
282 --event_storage_event_limit="default=100000"
283 Max number of events to store (per type). Value is a comma sepa‐
284 rated list of key values, where the keys are event types (e.g.: cre‐
285 ation, oom) or "default" and the value is an integer. Default is
286 applied to all non-specified event types
287
288
289 --global_housekeeping_interval=0
290 Interval between global housekeepings
291
292
293 --housekeeping_interval=0
294 Interval between container housekeepings
295
296
297 --httptest.serve=""
298 if non-empty, httptest.NewServer serves on this address and blocks
299
300
301 --insecure-skip-tls-verify=false
302 If true, the server's certificate will not be checked for validity.
303 This will make your HTTPS connections insecure
304
305
306 --kubeconfig=""
307 Path to the kubeconfig file to use for CLI requests.
308
309
310 --log-flush-frequency=0
311 Maximum number of seconds between log flushes
312
313
314 --log_backtrace_at=:0
315 when logging hits line file:N, emit a stack trace
316
317
318 --log_cadvisor_usage=false
319 Whether to log the usage of the cAdvisor container
320
321
322 --log_dir=""
323 If non-empty, write log files in this directory
324
325
326 --logtostderr=true
327 log to standard error instead of files
328
329
330 --machine_id_file="/etc/machine-id,/var/lib/dbus/machine-id"
331 Comma-separated list of files to check for machine-id. Use the
332 first one that exists.
333
334
335 --match-server-version=false
336 Require server version to match client version
337
338
339 -n, --namespace=""
340 If present, the namespace scope for this CLI request
341
342
343 --request-timeout="0"
344 The length of time to wait before giving up on a single server
345 request. Non-zero values should contain a corresponding time unit (e.g.
346 1s, 2m, 3h). A value of zero means don't timeout requests.
347
348
349 -s, --server=""
350 The address and port of the Kubernetes API server
351
352
353 --stderrthreshold=2
354 logs at or above this threshold go to stderr
355
356
357 --storage_driver_buffer_duration=0
358 Writes in the storage driver will be buffered for this duration,
359 and committed to the non memory backends as a single transaction
360
361
362 --storage_driver_db="cadvisor"
363 database name
364
365
366 --storage_driver_host="localhost:8086"
367 database host:port
368
369
370 --storage_driver_password="root"
371 database password
372
373
374 --storage_driver_secure=false
375 use secure connection with database
376
377
378 --storage_driver_table="stats"
379 table name
380
381
382 --storage_driver_user="root"
383 database username
384
385
386 --token=""
387 Bearer token for authentication to the API server
388
389
390 --user=""
391 The name of the kubeconfig user to use
392
393
394 -v, --v=0
395 log level for V logs
396
397
398 --version=false
399 Print version information and quit
400
401
402 --vmodule=
403 comma-separated list of pattern=N settings for file-filtered log‐
404 ging
405
406
407
409 # View all projects you have access to
410 oc get projects
411
412 # See a list of all services in the current project
413 oc get svc
414
415 # Describe a deployment configuration in detail
416 oc describe dc mydeploymentconfig
417
418 # Show the images tagged into an image stream
419 oc describe is ruby-centos7
420
421
422
423
425 oc(1),
426
427
428
430 June 2016, Ported from the Kubernetes man-doc generator
431
432
433
434Openshift Openshift CLI User Manuals OC(1)