7,540
edits
Changes
→Openshift specific object
Indítsuk el a minishift-et.
<pre>
# minishfit minishift start
-- Starting profile 'minishift'
-- Check if deprecated options are used ... OK
<br>
===Törlés===
A '''minishift delete''' paranccsal az aktuális VM-et töröljük csak le, nem a minishift programot. A törlés után egy minishift start új VM-et fog készíteni.
<pre>
# minishift delete
You are deleting the Minishift VM: 'minishift'. Do you want to continue [y/N]?: y
Removing entries from kubeconfig for cluster: 192-168-42-64:8443
Deleting the Minishift VM...
Minishift VM deleted.
</pre>
<br>
}}
<br>
===Új névtér hozzáadása===
Hozzuk létre az új névteret.
<pre>
# kubectl create namespace mynamespace
</pre>
<br>
Rendeljük hozzá az admin clusterrole-t a developer user-hez a mynamespace névtérben. Ezzel teljhatalmat kap a developer a mynamesapce-ben.
<pre>
# kubectl create rolebinding developer-admin --namespace=mynamespace --clusterrole=admin --user=developer
rolebinding.rbac.authorization.k8s.io/developer-admin created
</pre>
<br>
Ezzel létrejött a developer-admin rolebindig a mynamespace-ben, listázzuk ki:
<pre>
# kubectl get rolebinding developer-admin -n mynamespace -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
creationTimestamp: "2019-09-22T10:51:01Z"
name: developer-admin
namespace: mynamespace
resourceVersion: "35751"
selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/mynamespace/rolebindings/developer-admin
uid: de318108-dd26-11e9-bc53-52540074f436
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: developer
</pre>
<br>
Most lépjünk be a developer-el, láthatjuk, hogy megjelent a névtér listában a mynamespace is:
<pre>
# oc login
Authentication required for https://192.168.42.214:8443 (openshift)
Username: developer
Password:
Login successful.
You have access to the following projects and can switch between them with 'oc project <projectname>':
mynamespace
* myproject
Using project "myproject".
</pre>
<br>
<br>
=Openshift specific object=
==DeploymentConfig== <br> =DeploymentConfig=Service with ssl encryption== Az egésznek a mozgató rugója, hogy a service objektumban szerepeltetjük a '''service.alpha.openshift.io/serving-cert-secret-name''' annotációt. Az itt megadott értékkel (a példában '''my-app-internal-cert''') létre fog jönni automatikusan egy TLS típusú secret mikor kiadjuk a svc-re az apply parancsot. service.yaml<source lang="C++">apiVersion: v1kind: Servicemetadata: annotations: service.alpha.openshift.io/serving-cert-secret-name: my-app-internal-cert labels: app: my-app configurable: "true" name: my-app namespace: mynamespace...</source> Ezt a kulcsot fogja a service titkosításra használni. <pre># kubectl get secret pod-monitor-internal-cert -o yaml------------------------------------------------------apiVersion: v1data: tls.crt: SDGSDFGsda... tls.key: AFGGSDGcs....kind: Secretmetadata: name: my-app-internal-cert namespace: mynamespace ownerReferences: - apiVersion: v1 kind: Service name: my-apptype: kubernetes.io/tls</pre> A '''my-app-internal-cert''' secret-et bele kell tenni a Deployment-hez tartozó service-account-ba is, hogy mount-olni tudjuk majd a pod-ba: <br>service-account.yaml<source lang="C++">apiVersion: v1kind: ServiceAccountmetadata: labels: app: my-app name: my-appsecrets:...- name: my-app-internal-cert</source> deployment.yaml<source lang="C++"> - mountPath: /var/run/secrets/https-internal-cert name: https-internal-cert readOnly: true... volumes: - name: https-internal-cert secret: defaultMode: 420 secretName: my-app-internal-cert</source>
<br>
<br> ==RouteRouter==http://people.redhat.com/jrivera/openshift-docs_preview/openshift-origin/glusterfs-review/install_config/router/index.html<br>http://people.redhat.com/jrivera/openshift-docs_preview/openshift-origin/glusterfs-review/architecture/networking/routes.html<br>
https://docs.openshift.com/container-platform/3.11/architecture/networking/routes.html#route-types<br>
Default: HAProxy
The controller and HAProxy are housed inside a pod, which is managed by a deployment configuration. The process of setting up the router is automated by the oc adm router command.
The controller watches the routes and endpoints for changes, as well as HAProxy’s health. When a change is detected, it builds a new haproxy-config file and restarts HAProxy. The haproxy-config file is constructed based on the router’s template file and information from OpenShift Origin.
Ez az Ingress megfelelője az OpenShfit-ben. Az alapértelmezett implementációja a HAProxy. A load-balancing-ot OpenShift-ben a szabványos Kubernetes-el szemben a router végzi, nem a service. Alapértelmezetten a router-ek a node-on a 80-as ill a 443-as portokra fognak kapcsolódni.
<br>
==SecurityContextConstraints== https://medium.com/bitnami-perspectives/running-containers-in-openshift-629af79945b5 Névtér független<pre># kubectl get SecurityContextConstraints anyuid -o yaml</pre> <source lang="C++">allowHostDirVolumePlugin: falseallowHostIPC: falseallowHostNetwork: falseallowHostPID: falseallowHostPorts: falseallowPrivilegeEscalation: trueallowPrivilegedContainer: falseallowedCapabilities: nullapiVersion: security.openshift.io/v1defaultAddCapabilities: nullfsGroup: type: RunAsAnygroups:- system:cluster-adminskind: SecurityContextConstraintsmetadata: annotations: kubernetes.io/description: anyuid provides all features of the restricted SCC but allows users to run with any UID and any GID. name: anyuidpriority: 10readOnlyRootFilesystem: falserequiredDropCapabilities:- MKNODrunAsUser: type: RunAsAnyseLinuxContext: type: MustRunAssupplementalGroups: type: RunAsAnyusers: - system:serviceaccount:mynamespace:defaultvolumes:- configMap- downwardAPI- emptyDir- persistentVolumeClaim- projected- secret</source> '''Run container as root'''<br>Azt hogy melyik pod futtathat root nevében konténert a '''SecurityContextConstraints''' objektumok írják le. Itt meg lehet határozni, hogy milyen user-nek és group-nak engedjük meg a konténer futtatását a konténeren belül. A HAProxy szolgáltat magáról metrikákat '''SecurityContextConstraints''' definícióban a routeruser szekcióban meg lehet adni service account-hez okat, és akkor az adott serviceAccount-hoz rendelt deploymenthez tartozó Kubernetes pod-oknak meg lehet engedni hogy a nekik tetsző user-el futtassanak process-eket. Ha nincs megengedi a root futtatás egy pod-nak, akkor egy nem privilegizált user-el fog futni. <pre># oc edit scc anyuidsecuritycontextconstraints.security.openshift.io/anyuid edited</pre> A '''mynamespace''' névtérben lévő '''default''' nevű serviceaccount-en keresztülal futtatott pod-oknak megengedjük a tetszőleges user választást. Az alapértelmezett metrika URL az alábbi:
<pre>
</pre>
Ha egy deployment-nek külön nem adjuk meg, akkor az adott névtér default serviceAccount-jával fog futni.
<br>
<br>
==Template==
https://docs.openshift.com/container-platform/3.11/dev_guide/templates.html
<pre>
# kubectl oc get svc template -n defaultmynamespaceNAME TYPE CLUSTER-IP EXTERNAL-IP PORT DESCRIPTION PARAMETERS OBJECTS 4 (S3 blank) AGE 2router ClusterIP 172mytemplate-1 This template contains the DeploymentConfig, Service, Route and ServiceAccoun.30.130.191 <none> 80/TCP,443/TCP,1936/TCP 11 (5 blank) 4d5
</pre>
<pre>
# kubectl oc get svc router template mytemplate-1 -n default mynamespace -o yamlapiVersion: template.openshift.io/v1kind: ServiceTemplate
metadata:
</pre>
<pre>
</pre>
Pl:
kubectl cp mynamespace/example-pod:/tmp/example.txt /home/adam/
{{note|Fontos, hogy a konténerben legyen rsync vagy tar telepítve, ezek valamelyikével fogja a Kubernetes végrehajtani a másolást}}
A cp OpenShfit megfelelője a oc rsync :
oc rsync mynamespace/example-pod:/tmp/example.txt /home/adam/
<br>
<br>
=Minishfit docker registry=
https://torstenwalter.de/minishift/openshift/docker/registry/2017/07/25/build-docker-image-and-upload-to-openshift-registry.html<br>
http://test-app-service-mynamespace.192.168.42.185.nip.io/test/slowresponse/2000
:[[File:ClipCapIt-190727-203903.PNG]]