Heteki no space error - kubernetes

I'm trying to setup a glusterfs cluster with kubernetes.
I managed to start the glusterd pods on all the nodes (3 nodes)
I also managed to load the topology successfully, however when I run
heketi-cli setup-openshift-heketi-storage
I get the following error:
Error: No space
This is the output of
heketi-cli topology load --json=gluster-kubernetes/deploy/topology.json
Found node vps01 on cluster 1a36667e4275773fc353f2caaaaaaa
Adding device /dev/loop0 ... OK
Found node vps02 on cluster 1a36667e4275773fc353faaaaaaaa
Found device /dev/loop0
Found node vps04 on cluster 1a36667e4275773fc353faaaaaaa
Adding device /dev/loop0 ... OK
Output of
heketi-cli topology info
Cluster Id: 1a36667e4275773fc353f2caaaaaa
File: true
Block: true
Volumes:
Nodes:
Node Id: 1752dcf447c8eb6eaad45aaaa
State: online
Cluster Id: 1a36667e4275773fc353f2caaa
Zone: 1
Management Hostnames: vps01
Storage Hostnames: XX.XX.XX.219
Devices:
Id:50396d72293c4723504810108bd75d41 Name:/dev/loop0 State:online Size (GiB):12 Used (GiB):0 Free (GiB):12
Bricks:
Node Id: 56b8c1942b347a863ee73a005758cc27
State: online
Cluster Id: 1a36667e4275773fc353f2c8eb2dd2a3
Zone: 1
Management Hostnames: vps04
Storage Hostnames: XX.XX.XX.227
Devices:
Id:dc75ad8154234ebcf9174b018d0bc30a Name:/dev/loop0 State:online Size (GiB):9 Used (GiB):4 Free (GiB):5
Bricks:
Node Id: f82cb81a026884764d3d953c7c9b6a9f
State: online
Cluster Id: 1a36667e4275773fc353f2c8eb2dd2a3
Zone: 1
Management Hostnames: vps02
Storage Hostnames: XX.XX.XX.157
Devices:
Id:1914102b7ae395f12797981a0e3cf5a4 Name:/dev/loop0 State:online Size (GiB):4 Used (GiB):4 Free (GiB):0
Bricks:
There is no more space on device 1914102b7ae395f12797981a0e3cf5a4, however I didn't not store anything yet on the device.
For info here is the topology.json file:
{
"clusters": [
{
"nodes": [
{
"node": {
"hostnames": {
"manage": [
"vps01"
],
"storage": [
"XX.XX.XX.219"
]
},
"zone": 1
},
"devices": [
"/dev/loop0"
]
},
{
"node": {
"hostnames": {
"manage": [
"vps02"
],
"storage": [
"XX.XX.XX.157"
]
},
"zone": 1
},
"devices": [
"/dev/loop0"
]
},
{
"node": {
"hostnames": {
"manage": [
"vps04"
],
"storage": [
"XX.XX.XX.227"
]
},
"zone": 1
},
"devices": [
"/dev/loop0"
]
}
]
}
]
}

You can try this:
# ./gk-deploy -g --abort
# dmsetup remove_all # In each server.
# dmsetup ls
# rm -fr /var/lib/glusterd/vols/* # In each server.
# rm -fr /var/lib/heketi/* # In each server.
# wipefs -a /dev/<device> # In each server.
source: https://github.com/gluster/gluster-kubernetes/issues/369#issuecomment-383247722

Related

RabbitMQ Kubernetes RabbitmqCluster Operator not adding members to Quorum Queues

I am using the rabbitmq cluster operator to deploy a RabbitMQ HA cluster on kubernetes.
I am importing the defintions by referring to [this example](https://github.com/rabbitmq/cluster-operator/blob/main/docs/examples/import-definitions/rabbitmq.yaml Import Definitions Example).
I have provided configuration as below (3 replicas)
After the cluster is up and i access the management console using port-forward on the service, i see that the queue is declared with type set to "quorum" but it only shows the 1st node of the cluster under leader, online and members.
The cluster is set up with 3 replicas and the default value for quorum initial group size is 3 if i dont specify any.(although i am specifying it explicitly in the defintions file).
It should show other members of cluster under online and members section but it shows only the first node (rabbitmq-ha-0)
Am i missing any configuration ?
apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
name: import-definitions
spec:
replicas: 3
override:
statefulSet:
spec:
template:
spec:
containers:
- name: rabbitmq
volumeMounts:
- mountPath: /path/to/exported/ # filename left out intentionally
name: definitions
volumes:
- name: definitions
configMap:
name: definitions # Name of the ConfigMap which contains definitions you wish to import
rabbitmq:
additionalConfig: |
load_definitions = /path/to/exported/definitions.json # Path to the mounted definitions file
and my definitions file is something like this:
{
"users": [
{
"name": "my-vhost",
"password": "my-vhost",
"tags": "",
"limits": {}
}
],
"vhosts": [
{
"name": "/"
},
{
"name": "my-vhost"
}
],
"permissions": [
{
"user": "my-vhost",
"vhost": "my-vhost",
"configure": ".*",
"write": ".*",
"read": ".*"
}
],
"topic_permissions": [
{
"user": "my-vhost",
"vhost": "my-vhost",
"exchange": "",
"write": ".*",
"read": ".*"
}
],
"parameters":[
{
"value":{
"max-connections":100,
"max-queues":15
},
"vhost":"my-vhost",
"component":"vhost-limits",
"name":"limits"
}
],
"policies":[
{
"vhost":"my-vhost",
"name":"Queue-Policy",
"pattern":"my-*",
"apply-to":"queues",
"definition":{
"delivery-limit":3
},
"priority":0
}
],
"queues":[
{
"name":"my-record-q",
"vhost": "my-vhost",
"durable":true,
"auto_delete":false,
"arguments":{
"x-queue-type":"quorum",
"x-quorum-initial-group-size":3
}
}
],
"exchanges":[
{
"name":"my.records.topic",
"vhost": "my-vhost",
"type":"topic",
"durable":true,
"auto_delete":false,
"internal":false,
"arguments":{
}
}
],
"bindings":[
{
"source":"my.records-changed.topic",
"vhost": "my-vhost",
"destination":"my-record-q",
"destination_type":"queue",
"routing_key":"#.record.#",
"arguments":{
}
}
]
}

why does hashicorp vault json config fail with "Error initializing listener of type listener"?

When using hashicorp vault version 1.0.2 and the following JSON configuration file in config.json:
{
"listener": [
{
"tcp": [
{
"address": "0.0.0.0:8300",
"tls_disable": 1
}
]
}
],
"storage": {
"file": {
"path": "/tmp/foobar"
}
}
}
vault server -config config.json fails with Error initializing listener of type listener: unknown listener type: "listener".
However, with the same configuration in config.hcl
listener tcp {
address = "0.0.0.0:8300"
tls_disable = 1
}
storage file {
path = "/tmp/foobar"
}
vault server -config config.hcl works as expected:
==> Vault server configuration:
Cgo: disabled
Listener 1: tcp (addr: "0.0.0.0:8300", cluster address: "0.0.0.0:8301", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
Log Level: (not set)
Mlock: supported: true, enabled: true
Storage: file
Version: Vault v1.0.2
Version Sha: 37a1dc9c477c1c68c022d2084550f25bf20cac33
==> Vault server started! Log data will stream in below:
...
What am I missing?
The JSON seems to be correct, try removing the square brakets:
{
"listener":
{
"tcp":
{
"address": "0.0.0.0:8300",
"tls_disable": 1
}
},
"storage": {
"file": {
"path": "/tmp/foobar"
}
}
}

Can't register ecs task with docker hub private repository image

I want to run an ECS task with a docker image from private docker hub repository.
I followed all instructions in this doc https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html .
Then I created a task definition json:
{
"containerDefinitions": [
{
"name": "signage-next-graphql",
"image": "docker.io/private/next-graphql:latest",
"repositoryCredentials": {
"credentialsParameter": "arn:aws:secretsmanager:us-east-2: 385945872227:secret:dockerhub-personal-pTsU9e"
},
"memory": 500,
"essential": true,
"portMappings": [
{
"hostPort": 5000,
"containerPort": 5000
}
]
}
],
"volumes": [],
"memory": "900",
"cpu": "128",
"placementConstraints": [],
"family": "next-graphql",
"executionRoleArn": "arn:aws:iam::385945872227:role/ecsTaskExecutionRole",
"taskRoleArn": ""
}
when I run aws ecs register-task-definition --family "${ECS_TASK_FAMILY}" --cli-input-json "file://./ecsTaskDefinition.json" --region "${AWS_TARGET_REGION}" , i'm getting the error;
Unknown parameter in containerDefinitions[0]: "repositoryCredentials",
must be one of: name, image, cpu, memory, memoryReservation, links,
portMappings, essential, entryPoint, command, environment,
mountPoints, volumesFrom, linuxParameters, hostname, user,
workingDirectory, disableNetworking, privileged,
readonlyRootFilesystem, dnsServers, dnsSearchDomains, extraHosts,
dockerSecurityOptions, dockerLabels, ulimits, logConfiguration,
healthCheck
Is aws documentation not updated? I'd expect it to be up to date.

Error when setting up glusterfs on Kubernetes: volume create: heketidbstorage: failed: Host not connected

I'm following this instruction to setup glusterfs on my kubernetes cluster. At heketi-client/bin/heketi-cli setup-openshift-heketi-storage part, heketi-cli tells me :
Error: volume create: heketidbstorage: failed: Host 192.168.99.25 not connected
or sometimes:
Error: volume create: heketidbstorage: failed: Staging failed on 192.168.99.26. Error: Host 192.168.99.25 not connected
heketi.json is
{
"_port_comment": "Heketi Server Port Number",
"port": "8080",
"_use_auth": "Enable JWT authorization. Please enable for deployment",
"use_auth": false,
"_jwt": "Private keys for access",
"jwt": {
"_admin": "Admin has access to all APIs",
"admin": {
"key": "7319"
},
"_user": "User only has access to /volumes endpoint",
"user": {
"key": "7319"
}
},
"_glusterfs_comment": "GlusterFS Configuration",
"glusterfs": {
"_executor_comment": "Execute plugin. Possible choices: mock, kubernetes, ssh",
"executor": "kubernetes",
"_db_comment": "Database file name",
"db": "/var/lib/heketi/heketi.db",
"kubeexec": {
"rebalance_on_expansion": true
},
"sshexec": {
"rebalance_on_expansion": true,
"keyfile": "/etc/heketi/private_key",
"fstab": "/etc/fstab",
"port": "22",
"user": "root",
"sudo": false
}
},
"_backup_db_to_kube_secret": "Backup the heketi database to a Kubernetes secret when running in Kubernetes. Default is off.",
"backup_db_to_kube_secret": false
}
topology-sample.json is
{
"clusters": [
{
"nodes": [
{
"node": {
"hostnames": {
"manage": [
"redis-test25"
],
"storage": [
"192.168.99.25"
]
},
"zone": 1
},
"devices": [
{
"name": "/dev/sda7",
"destroydata": true
}
]
},
{
"node": {
"hostnames": {
"manage": [
"redis-test26"
],
"storage": [
"192.168.99.26"
]
},
"zone": 1
},
"devices": [
{
"name": "/dev/sda7",
"destroydata": true
}
]
},
{
"node": {
"hostnames": {
"manage": [
"redis-test01"
],
"storage": [
"192.168.99.113"
]
},
"zone": 1
},
"devices": [
{
"name": "/dev/sda7",
"destroydata": true
}
]
}
]
}
]
}
The heketi-cli is v8.0.0 and kubernetes is v1.12.3
How do I fix this problem?
Update: Just found that I missed the iptables part, but now the message becomes
Error: volume create: heketidbstorage: failed: Host 192.168.99.25 is not in 'Peer in Cluster' state
seems that one of the glusterfs pod cannot connect to others, I tried kubectl exec -i glusterfs-59ftx -- gluster peer status:
Number of Peers: 2
Hostname: 192.168.99.26
Uuid: 6950db9a-3d60-4625-b642-da5882396bee
State: Peer Rejected (Disconnected)
Hostname: 192.168.99.113
Uuid: 78983466-4499-48d2-8411-2c3e8c70f89f
State: Peer Rejected (Disconnected)
while the other one said:
Number of Peers: 1
Hostname: 192.168.99.26
Uuid: 23a0114d-65b8-42d6-8067-7efa014af68d
State: Peer in Cluster (Connected)
I solved these problems by myself.
For first part, the reason is that I didn't setup iptables in every nodes according to Infrastructure Requirements.
For second part according to this article, delete all file in /var/lib/glusterd except glusterd.info and then start over from Kubernete Deploy.

Kubernetes - How to change tokens for hyperkube apiserver

We are using hyperkube's apiserver and configuring it via a manifest file:
"containers":[
{
"name": "apiserver",
"image": "gcr.io/google_containers/hyperkube-amd64:v1.2.1",
"command": [
"/hyperkube",
"apiserver",
"--service-cluster-ip-range=192.168.0.0/23",
"--service-node-port-range=9000-9999",
"--bind-address=127.0.0.1",
"--etcd-servers=http://127.0.0.1:4001",
"--admission-control=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota",
"--client-ca-file=/srv/kubernetes/ca.crt",
"--basic-auth-file=/srv/kubernetes/basic_auth.csv",
"--min-request-timeout=300",
"--tls-cert-file=/srv/kubernetes/server.cert",
"--tls-private-key-file=/srv/kubernetes/server.key",
"--token-auth-file=/srv/kubernetes/known_tokens.csv",
"--allow-privileged=true",
"--v=4"
],
"volumeMounts": [
{
"name": "data",
"mountPath": "/srv/kubernetes"
}
]
}
I'm trying to figure out how to set up a different set of tokens than in /srv/kubernetes/known_tokens.csv to have users "superuser" and "reader", instead of admin, kubelet, and kube_proxy. How can I do this?
Your manifest is using the exposed volume path /srv/kubernetes, so should be able to map that to another persistent volume (http://kubernetes.io/docs/user-guide/volumes/) and setup the new files there.
You can do that by specifying a volume:
"volumes": [
{
"name": "data",
"hostPath": {
"path": "/foo"
}
}
]