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>
==Router==
http://people.redhat.com/jrivera/openshift-docs_preview/openshift-origin/glusterfs-review/install_config/router/index.html<br>
https://medium.com/bitnami-perspectives/running-containers-in-openshift-629af79945b5
Névtér független
<pre>
# kubectl get SecurityContextConstraints anyuid -n default -o yaml
</pre>
'''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 '''SecurityContextConstraints''' definícióban a user szekcióban meg lehet adni service account-okat, és akkor az adott serviceAccount-hoz rendelt deploymenthez tartozó 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 anyuid
securitycontextconstraints.security.openshift.io/anyuid edited
</pre>
A '''mynamespace''' névtérben lévő '''default''' nevű service account-al futtatott pod-oknak megengedjük a tetszőleges user választást.
<pre>
- system:serviceaccount:mynamespace:default
</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>
==Metrikák lekérdezéseTemplate==A metrikák lekérdezésére két lehetőség vanhttps://docs. # felhasználó név + jelszó használata# RBAC szabályok definiálása a megfelelő serviceAccount openshift.com/container-hozplatform/3.11/dev_guide/templates.html
<pre>
</pre>
<pre>
# kubectl oc get svc router template mytemplate-1 -n default mynamespace -o yamlapiVersion: template.openshift.io/v1kind: ServiceTemplate
metadata:
</pre>
<pre>
</pre>
<br>