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=
<br>
==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: v1
kind: Service
metadata:
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: v1
data:
tls.crt: SDGSDFGsda...
tls.key: AFGGSDGcs....
kind: Secret
metadata:
name: my-app-internal-cert
namespace: mynamespace
ownerReferences:
- apiVersion: v1
kind: Service
name: my-app
type: 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: v1
kind: ServiceAccount
metadata:
labels:
app: my-app
name: my-app
secrets:
...
- 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 -o yaml
</pre>
<source lang="C++">
allowHostDirVolumePlugin: false
allowHostIPC: false
kubernetes.io/description: anyuid provides all features of the restricted SCC
but allows users to run with any UID and any GID.
name: anyuid
priority: 10
readOnlyRootFilesystem: false
supplementalGroups:
type: RunAsAny
users: []- system:serviceaccount:mynamespace:default
volumes:
- configMap
A HAProxy szolgáltat magáról prometheus szabványú metrikákat '''mynamespace''' névtérben lévő '''default''' nevű service account-al futtatott pod-oknak megengedjük a routertetszőleges user választást. <pre>-hez tartozó Kubernetes servicesystem:serviceaccount:mynamespace:default</pre>Ha egy deployment-en keresztül. A metrikákat lekérdező végpont (metrics) alapból be van kapcsolva. Ezt ki lehet kapcsolninek külön nem adjuk meg, de attól még gyűjteni fogja a metrikákat a HAProxyakkor 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>