Changes

Openshift basics

3,950 bytes added, 12:46, 27 November 2019
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>
 
==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>
<br>
=HAproxy metrikák gyűjtése=
https://docs.openshift.com/container-platform/3.10/install_config/router/default_haproxy_router.html<br>
https://docs.openshift.com/container-platform/3.10/admin_guide/router.html<br>
A HAProxy szolgáltat magáról prometheus szabványú metrikákat a router==SecurityContextConstraints== https://medium.com/bitnami-perspectives/running-containers-in-openshift-hez tartozó Kubernetes service629af79945b5 Névtér független<pre># kubectl get SecurityContextConstraints anyuid -en keresztülo yaml</pre> <source lang="C++">allowHostDirVolumePlugin: falseallowHostIPC: falseallowHostNetwork: falseallowHostPID: falseallowHostPorts: falseallowPrivilegeEscalation: trueallowPrivilegedContainer: falseallowedCapabilities: nullapiVersion: security.openshift. A metrikákat lekérdező végpont (metrics) alapból be van kapcsolvaio/v1defaultAddCapabilities: nullfsGroup: type: RunAsAnygroups:- system:cluster-adminskind: SecurityContextConstraintsmetadata: annotations: kubernetes. Ezt ki lehet kapcsolni, de attól még gyűjteni fogja a metrikákat a HAProxyio/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>
<br>
==Metrikák lekérdezése==
A metrikák lekérdezésére két lehetőség van.
# felhasználó név + jelszó használata
# RBAC szabályok definiálása a megfelelő serviceAccount -hoz
<br>
===User + jelszó alapú lekérdezés ===
Felhasználó név alapú lekérdezés esetén '''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 alapértelmezett metrika URL az alábbi: 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>
http:# oc edit scc anyuidsecuritycontextconstraints.security.openshift.io//<user>:<password>@<router_IP>:<STATS_PORT>/metricsanyuid edited
</pre>
 A metrika user, jelszó és port a router-hez tartozó '''mynamespace''' névtérben lévő '''default''' nevű service definíciójában van. Ehhez elsőként meg kell keresni a routeraccount-hez tartozó serviceal futtatott pod-t:oknak megengedjük a tetszőleges user választást.
<pre>
# kubectl get svc -n system:serviceaccount:mynamespace:defaultNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGErouter ClusterIP 172.30.130.191 <none> 80/TCP,443/TCP,1936/TCP 4d
</pre>
LáthatjukHa egy deployment-nek külön nem adjuk meg, hogy akkor az '''1936'''adott névtér default serviceAccount-os porton is hallgatózik, ez a metrika végpontjának a portjajával fog futni.   <br><br>==Template==https://docs.openshift.com/container-platform/3.11/dev_guide/templates. html
Most nézzünk bele a service definíciójába, hogy megkapjuk a user és pass-t is:
<pre>
# kubectl oc get svc router template -n default -o yamlmynamespaceapiVersion: v1NAME DESCRIPTION PARAMETERS OBJECTS 4 (3 blank) 2kind: mytemplate-1 This template contains the DeploymentConfig, Servicemetadata: annotations: prometheus.openshift, Route and ServiceAccoun.io/password: 4v9a7ucfMi prometheus.openshift.io/username: admin ...11 (5 blank) 5
</pre>
Ennek függvényében, a node IP címét felhasználva, (minishfit IP) a metrika URL az alábbi: http://admin:4v9a7ucfMi@192.168.42.64:1936/metrics 
<pre>
# curl adminoc get template mytemplate-1 -n mynamespace -o yamlapiVersion:4v9a7ucfMi@192template.168openshift.42.64:1936io/metricsv1# HELP apiserver_audit_event_total Counter of audit events generated and sent to the audit backend.kind: Template# TYPE apiserver_audit_event_total countermetadata:apiserver_audit_event_total 0# HELP apiserver_client_certificate_expiration_seconds Distribution of the remaining lifetime on the certificate used to authenticate a request.# TYPE apiserver_client_certificate_expiration_seconds histogramapiserver_client_certificate_expiration_seconds_bucket{le="0"} 0apiserver_client_certificate_expiration_seconds_bucket{le="21600"} 0apiserver_client_certificate_expiration_seconds_bucket{le="43200"} 0apiserver_client_certificate_expiration_seconds_bucket{le="86400"} 0apiserver_client_certificate_expiration_seconds_bucket{le="172800"} 0apiserver_client_certificate_expiration_seconds_bucket{le="345600"} 0apiserver_client_certificate_expiration_seconds_bucket{le="604800"} 0...
</pre>
 
<br>
<br>
==Fájl másolása konténerekből==
<pre>
kubectl cp <névtér>/<pod-név>:<fájl elérési út> <cél-mappa-neve>
</pre>
===ServiceAccount alapú lekérdezés===Pl: kubectl cp mynamespace/example-pod:/tmp/example.txt /home/adam/
<br>{{note|Fontos, hogy a konténerben legyen rsync vagy tar telepítve, ezek valamelyikével fogja a Kubernetes végrehajtani a másolást}}==Metrika fajták==http://people.redhat.com/jrivera/openshift-docs_preview/openshift-origin/glusterfs-review/architecture/networking/haproxy-router.html<br>
A cp OpenShfit megfelelője a oc rsync :
oc rsync mynamespace/example-pod:/tmp/example.txt /home/adam/
<br>