using openshift, and one pod keep pending, because nfs server cannot be mounted (nfs server is able to be mounted by mannually using command line, but cannot be mounted from the Pod)
I have installed nfs-common, so it's not the root cause. I trying to install nfs-utils, but I was failed, the error message is:
E: Unable to locate package: nfs-utils.
I also tried libnfs12 and libnfs-utils, they were the same as nfs-utils. I also used apt-get install upgade and update to solve the package locating problem, but they were useless.
I'm going to show the yaml file for connecting the nfs server
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-test01
lables:
disktype: baas
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteMany
nfs:
path: /baas
server: 9.111.140.47
readOnly: false
persistentVolumeReclaimPolicy: Recycle
after using "oc describe pod/mypod" for the pending Pod, below is the feedback:
Warning FailedMount 14s kubelet, localhost MountVolume.SetUp failed for volume "pv-test01" : mount failed: exit status 32
Mounting command: systemd-run
Mounting arguments: --description=Kubernetes transient mount for /var/lib/origin/cluster-up/root/openshift.local.clusterup/openshift.local.volumes/pods/267db6f2-d875-11e9-80ba-005056bc3ce0/volumes/kubernetes.io~nfs/pv-test01 --scope -- mount -t nfs 9.111.140.47:/baas /var/lib/origin/cluster-up/root/openshift.local.clusterup/openshift.local.volumes/pods/267db6f2-d875-11e9-80ba-005056bc3ce0/volumes/kubernetes.io~nfs/pv-test01
Output: Running scope as unit run-28094.scope.
mount: wrong fs type, bad option, bad superblock on 9.111.140.47:/baas,
missing codepage or helper program, or other error
(for several filesystems (e.g. nfs, cifs) you might
need a /sbin/mount.<type> helper program)
In some cases useful info is found in syslog - try
dmesg | tail or so.
so how can I mount to nfs server from the Pod? should I keep installing nfs-utils? If yes, how can I install it?
Related
Unable to run MYSQL :8.0 on AKS using PVC, below is my manifest files
[
I've just encountered a similar issue myself (when switching from mysql:5.5 to mysql:8).
The key to resolving it when using Azure Files appears to be setting the - nobrl setting on the StorageClass :
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: mysql-sc-azurefile
provisioner: file.csi.azure.com
allowVolumeExpansion: true
mountOptions:
- file_mode=0777
- mfsymlinks
- uid=999
- dir_mode=0777
- gid=999
- actimeo=30
- cache=strict
- nobrl
parameters:
skuName: Standard_LRS
Additionally, you may need to set the securityContext on the deployment to use 999 (to prevent mysql attempting to switch the user at startup) :
securityContext:
runAsUser: 999
runAsGroup: 999
fsGroup: 999
I went through the mysql operator documentation on github and i followed through but i kept getting this error
Patching failed with inconsistencies: (('remove', ('status', 'kopf'), {'dummy': '2022-07-14T15:51:30.145945'}, None),)
0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims.
Back-off restarting failed container
here are the kubernetes file used
kubectl apply -f https://raw.githubusercontent.com/mysql/mysql-operator/trunk/deploy/deploy-crds.yaml
kubectl apply -f https://raw.githubusercontent.com/mysql/mysql-operator/trunk/deploy/deploy-operator.yaml
apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
name: mycluster
spec:
secretName: mypwds
tlsUseSelfSigned: true
instances: 3
router:
instances: 1
I dont know what to do. Any help will be much appreciated
First time posting on StackOverflow so please be gentle!
I'm setting up a new RHEL8 server to run Podman. Previously, I've done this on a pretty vanilla server but this one is setup in line with our corporate image. This means a homedir that is mounted over NFS.
When I try a simple podman command such as podman run centos, I get a couple of errors (see below). According to https://github.com/containers/podman/blob/main/rootless.md, Podman non-root is known to have problems with NFS homedirs.
Output from podman run centos (and others):
❯ podman run centos
Resolved "centos" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull quay.io/centos/centos:latest...
Getting image source signatures
Copying blob 7a0437f04f83 done
Error: writing blob: adding layer with blob "sha256:7a0437f04f83f084b7ed68ad9c4a4947e12fc4e1b006b38129bac89114ec3621": Error processing tar file(exit status 1): Error setting up pivot dir: mkdir /home/me/.local/share/containers/storage/overlay/2653d992f4ef2bfd27f94db643815aa567240c37732cae1405ad1c1309ee9859/diff/.pivot_root926823499: permission denied
No, my username isn't really 'me'
Is there a way to use podman non-root in this setup? I'd prefer to avoid creating a local user account to run things under (this is my dev server and isn't where the application will actually be running but will involve me building, running, destroying regularly so I'd rather avoid having to do anything 'clever')
Output of podman info:
❯ podman info
host:
arch: amd64
buildahVersion: 1.23.1
cgroupControllers: []
cgroupManager: cgroupfs
cgroupVersion: v1
conmon:
package: conmon-2.0.32-1.module+el8.5.0+13852+150547f7.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.0.32, commit: 4b12bce835c3f8acc006a43620dd955a6a73bae0'
cpus: 1
distribution:
distribution: '"rhel"'
version: "8.5"
eventLogger: file
hostname: servername
idMappings:
gidmap:
- container_id: 0
host_id: 2000
size: 1
uidmap:
- container_id: 0
host_id: 10279927
size: 1
kernel: 4.18.0-348.12.2.el8_5.x86_64
linkmode: dynamic
logDriver: k8s-file
memFree: 1881419776
memTotal: 3918233600
ociRuntime:
name: runc
package: runc-1.0.3-1.module+el8.5.0+13556+7f055e70.x86_64
path: /usr/bin/runc
version: |-
runc version 1.0.3
spec: 1.0.2-dev
go: go1.16.7
libseccomp: 2.5.1
os: linux
remoteSocket:
path: /run/user/10279927/podman/podman.sock
security:
apparmorEnabled: false
capabilities: CAP_NET_RAW,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: true
seccompEnabled: true
seccompProfilePath: /usr/share/containers/seccomp.json
selinuxEnabled: true
serviceIsRemote: false
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns-1.1.8-1.module+el8.5.0+12582+56d94c81.x86_64
version: |-
slirp4netns version 1.1.8
commit: d361001f495417b880f20329121e3aa431a8f90f
libslirp: 4.4.0
SLIRP_CONFIG_VERSION_MAX: 3
libseccomp: 2.5.1
swapFree: 4294963200
swapTotal: 4294963200
uptime: 2h 45m 20.28s (Approximately 0.08 days)
plugins:
log:
- k8s-file
- none
- journald
network:
- bridge
- macvlan
volume:
- local
registries:
search:
- registry.fedoraproject.org
- registry.access.redhat.com
- registry.centos.org
- docker.io
store:
configFile: /home/me/.config/containers/storage.conf
containerStore:
number: 0
paused: 0
running: 0
stopped: 0
graphDriverName: overlay
graphOptions:
overlay.mount_program:
Executable: /usr/bin/fuse-overlayfs
Package: fuse-overlayfs-1.8-1.module+el8.5.0+13754+92ec836b.x86_64
Version: |-
fusermount3 version: 3.2.1
fuse-overlayfs: version 1.8
FUSE library version 3.2.1
using FUSE kernel interface version 7.26
graphRoot: /home/me/.local/share/containers/storage
graphStatus:
Backing Filesystem: nfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "false"
imageStore:
number: 0
runRoot: /run/user/10279927/containers
volumePath: /home/me/.local/share/containers/storage/volumes
version:
APIVersion: 3.4.2
Built: 1642068949
BuiltTime: Thu Jan 13 10:15:49 2022
GitCommit: ""
GoVersion: go1.16.7
OsArch: linux/amd64
Version: 3.4.2
Thank you!
Based on this article, https://www.redhat.com/sysadmin/rootless-podman-nfs, podman and nfs home directories don't mix well together.
This is worked around by changing the graphroot(which is described in the above article) to write to a local, non-nfs, location.
I reset my entire Docker Desktop from factory settings and enable kubernetes.
Then, I run kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.0.4/deploy/static/provider/cloud/deploy.yaml and wait for the ingress to be ready.
Then, I deploy my application, which includes several services and an ingress definition.
The ingress is as follows:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-ingress
annotations:
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/proxy-body-size: 100m
spec:
ingressClassName: nginx
rules:
- host: test.project.com
http:
paths:
- path: "/.*"
pathType: "Prefix"
backend:
service:
name: test-frontend
port:
number: 80
Checking on the service, I get:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
test-frontend ClusterIP 10.104.106.210 <none> 80/TCP 40m
kubectl get services -n ingress-nginx returns
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx-controller LoadBalancer 10.100.44.33 <pending> 80:30753/TCP,443:31632/TCP 51m
ingress-nginx-controller-admission ClusterIP 10.97.85.58 <none> 443/TCP 51m
kubectl get ingresses returns
NAME CLASS HOSTS ADDRESS PORTS AGE
test-ingress nginx test.project.com 80 31m
As you can see, Docker Desktop or the Ingress is not properly binding the ingress to localhost, as it usually does. What I've been doing for the last several weeks is constantly stopping, restarting, rebuilding and resetting my deployments, services, ingresses, nodes, my computer, and Docker desktop until it suddenly starts working. I have never been able to find out what actually fixes it, it seems almost random whether it works or not, and when it stops working.
The only interesting thing I can find involves the events of the test-ingress:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Sync 35m (x3 over 42m) nginx-ingress-controller Scheduled for sync
Normal Sync 27m (x2 over 28m) nginx-ingress-controller Scheduled for sync
Normal Sync 7m55s (x2 over 14m) nginx-ingress-controller Scheduled for sync
Edit: It started working again after a restart of my desktop. Leaving this up for any ideas as to how to prevent this or how to fix it faster next time, as this is the 5th or 6th time this has happened.
may be try
kubectl expose deployment test-ingress-deployment --type=NodePort --port=8080 --name=test-ingress-service -n demo --dry-run=1 -o yaml > mypod-service.yaml
to get the yaml template generate for the service
then start the service by apply that yaml file
then apply the ingress yaml file
on Window 10 and that will assign a random port 9999 that can be access from the "minikube ip":9999/* url
the host name is not really set but in the host file. Ingress can be access via the ip. Ingress is end point access to multiple services regardless of namespaces but the service have to be exposed directly.
if the host file is not update with the minikube ip and the host name then ingress is Scheduled for sync.
it should work with Hyper VM
https://local/hello
Using the rancher GUI, I'm trying to set up Nextcloud with MySQL database workloads on my AKS cluster. In the environment variables, I already have defined the admin user and password so why do I get this error on the create admin page?
Error while trying to create admin user: Failed to connect to the
database: An exception occurred in driver: SQLSTATE[HY000] [2054] The
server requested authentication method unknown to the client
I entered the Username and password correctly multiple times.
Below are my configurations for the database and nextcloud so far.
database workload:
Name: nextdb
Docker image: mysql
port: not set
I have the following variables:
MYSQL_ROOT_PASSWORD=rootpassX
MYSQL_DATABASE=nextDB
MYSQL_USER=nextcloud
MYSQL_PASSWORD=passX
volumes configuration:
Volume Type: Bind-Mount
Volume Name: nextdb
Path on the Node : /nextdb
The Path on the Node must be: a directory or create
Mount Point: /var/lib/mysql
nextcloud workload:
Name: nextcloud
Docker Image: nextcloud
Port Mapping:
Port Name : nextcloud80
Publish the container port: 80
Protocol: TCP
As a: Layer-4 load balancer
On listening port: 80
Environment variables:
MYSQL_DATABASE=nextDB
MYSQL_USER=nextcloud
MYSQL_PASSWORD=passX
MYSQL_HOST=nextdb
NEXTCLOUD_ADMIN_USER=admin
NEXTCLOUD_ADMIN_PASSWORD=adminPass
NEXTCLOUD_DATA_DIR=/var/www/html/nextcloud
Volumes:
Volume 1:
name: nextcloud
Volume Type: Bind-Mount
Path on the Node: /nextcloud
The Path on the Node must be: a directory or create.
Mount Point: /var/www/html
Volume 2
name: nextdb
Volume Type: Bind-Mount
Path on the Node: /nextdatabase
The Path on the Node must be: a directory or create.
Mount Point: /var/lib/mysql
What are the problems with my configurations?
Starting with version 8.02, MySQL updated the default authentication method for client connections. To revert to the older authentication method you need to explicitly specify the default authentication method.
If you are able to update your DB service in Rancher to pass the container argument --default-authentication-plugin=mysql_native_password that should revert MySQL to the older auth method.
Alternatively, depending on the MySQL image you are using, you can create a new Docker image from that base which replaces /etc/mysql/my.cnf inside the container. You should inspect /etc/mysql/my.cnf before you replace it, if there are any !includedir directives in the config file, you can place your supplemental configuration into an included folder using whatever filename you choose.
The supplemental configuration should look like this:
[mysqld]
default_authentication_plugin=mysql_native_password